I have a problem. Before that, here's my history:

I have a dual boot system; Windows XP and Fedora Core 2. Windows XP uses both NTFS partitions and VFAT partitions (NOTE: VFAT partitioins are the partitions I need to work on). I use Transgaming Cedega (WineX remake) to use DirectX software on Linux. For both convience and to stop violating EULA, I decided to use the VFAT partitions as a place holder for installing my programs installed with Cedega. This way, I could edit the Windows Registry to allow usage of the program in Windows as well.

VFAT partitions:
/dev/hda2
/dev/hda3

The problem:
I can only do this in ROOT because VFAT does not carry over Linux rights and policies.

The goal (scope): To allow other users to use the VFAT partition as if it was there home directory (giving them rights and policies to read, write and execute). This in turn must be set in complience to allow Cedega to work with any other user other then ROOT.

The tools: I heard that SAMBA would be perfect to resolving this problem. But am very week on using Samba on command line and I never used it to mount a local partition before. The GUI client of SAMBA is not installed or does not seem to be installed, so I must use it in command line.

Can I please get help? Thank you.

Samba is for file and print sharing over a network. It seems like you just want local user access to a vfat partition. Try mounting it with the mount option "umask=000".

Umask 000 won't so much help, afaik, because if you are mounting the partition from /etc/fstab,

1) the mount is owned by root and the root group by default. So even though the default permissions are 666 for newly created directories, and 777 for files, most distributions change that default so that directories under 'root access' PATHs like /mnt are readable by everybody, but only writeable by the owner (who is in this case root, which is not helpful). And since umask=000 does nothing to change these permissions, the folder and files inside are still only going to be available to root, and only root will be able to create files in the folder.

2) unless the users option is enabled for that partition in /etc/fstab, the user won't be able to mount the partition anyway (only root is allowed to mount things, by default).

The correct solution (or at least the one that worked for me) to the issue of having local user access to a vfat partition, for the purposes you state (to be able to install a Windows game once and play it under both Linux and Windows) is to have a line in /etc/fstab such as the following:

dev/hd* /wherever/whatever vfat auto,users,rw,exec,uid=username_or_number,gid=groupname_or_number,umask=017 0 0

You need to create the mount point /wherever/whatever with read and write permissions for the user (root should create the folder, and then change the permissions so that the user owns it and has read and write permissions to it).

auto mounts the partition on startup, but you can use 'noauto' if you prefer.

users allows the user to mount the partition if you don't want it automatically mounted (or need to unmount it for some reason)

rw allows the mounting party to read and write to the mount

exec allows the mounting party to execute binary files (programs) from the mount

uid=username_or_number specifies that said username owns the files mounted by the partition within the mount point folder

gid=groupname_or_number specifies that said group owns the files mounted by the partition within the mount point folder (optional, but if you want to share the mount with another user who is a member of said group, to another box via Samba for example, this is useful to make sure that all users of group 'fileshare' can access the mount, but members of other groups cannot)

umask=*** sets the permissions for the files mounted within the mount point. Umask removes permissions, based on the default. In the above example (umask=017), the result is that the owner has full permissions (the default for files is 777 and 0 has been removed from the owner's permission, leaving the default of 7, or full permissions, active), the group has read-write permission (1-- the value of execute permission-- has been removed from the default permission of 7, leaving 6. 6 is the total of read permission, which has a value of 4, and write permission, which has a value of 2), and "others" who are neither the owner nor members of the owning group cannot access the files contained within the mount at all (7 has been removed from the default of 7, which leaves 0, which is the value of "no permissions whatsoever, not even read").

If you would like to read more details of why I've said this the way I've said it, you can read man mount (which is where I learned to do this), and/or my extended tutorial which covers this as a necessary sub-chapter:

Multiple Linux distros on one drive (With or without Windows)

This was the sum of what I learned in trying to implement The Massive Multiboot (5 distributions of Linux, two versions of Windows) a couple of years ago. Due to a similar necessity (there was no way I was going to install Neverwinter Nights or all my Wine games multiple times, much less manage 7 mail folders in 7 versions of Thunderbird-- I don't have HDD space for that), I had to figure out how to make all "shared" mounts accessible to me no matter which distro or OS I was using.

Hope this helps.

Umask 000 would give all files effectively 777 permissions and owner root:root. I frequently mount vfat partitions in this manner and have no problems with it. umask will change the permissions of vfat filesystems.

Additionally, the owner of the mount point prior to mounting makes 0 difference. I can have a mount point with no write permissions for the user, owned root:root, and still mount to it. mount is a suid binary, after all.

The results seem to be pointing out that Motub is correct. Though any user can now access files within the VFAT partition, the user can not write to them. There are two ways to resolve this problem. First, now that group and other permisions are write enabled, I can set the user under the group ROOT to gain that access, which sorta defeats the cause for all of this. Or I can try his theory. I'm one step closer; let's see if I can get motub's theory working.

Thanks for the help as of yet Matir, if his theory does not work, I still have a way to get my goal working with yours, so you were very helpful.

Ok, now I have to go test this theory.

Let me just get it straight:

• Mountpoint owned by root
• Mount vfat partition with umask=000, mounted by root.
• Users can read, but only root can write?

Or am I missing some intricacy here?

It's restrictive by policies. Only members of the root group can write. Only members of the root other (internet) can write. All others can not. If a member is placed within the root group, he also gains access to all root files and directories. This poses a security risk.

Prior to this, it was set so only root (himself) can read, write and execute. Groups and others were not included. Your method changed this so the group and other policies could be added. But the user was still ROOT and in order for a user to have the same rights, he/she would have to be placed within the ROOT group.

Think of it as you are you, your house is your group and your yard is the other. If I am not on your yard, your house or you, I can can't do anything within it.

Motub, your an evil genious! It worked flawlessly! Users have full access. Users can write files to the vfat. Cedega worked with it flawlessly and even ran the program at the end. Thanks a bunch!

Well, clearly then my inability to add, delete or rename files on a mounted partition because I have no permissions to write to the mount point directory itself, as all these activities changes the contents of the folder (which I do not have permission as a user to do, unless I change the permissions of the mount point), is some kind of a fluke, then. Though it was a mildly humorous to try to change the ID3 tags of an mp3 on a vfat partition using a native Linux program and get an 'access denied error'.

The act of mounting does not affect the permissions of the mount point folder itself, but once the partition is mounted, the permissions of the mount point folder do affect your ability to manage the contents of the partition. Try an experiment. As root, change the permissions of a file on a mounted partition (where the user does not have write access to /mnt/whatever, i.e. the actual mount point folder) to rw-rw-rw. Then try to rename the file as a user. This will fail, because the user is allowed to change the file, but not the contents of the folder in which the file is contained (the mount point folder).

Don't forget, the issue here is being able to read and write to the interior of the mount point directory (i.e., install games to it as a user, and subsequently write save files to the installation directory), not mounting per se. If the user doesn't have permission to write to the mount point, the installer won't be able to create directories inside the mount point, nor delete them if one attempts to uninstall.

dolvmin, I understand the theory, but umask=000 allows ALL write, not just user and group. Examine:
The filesystem was mounted by root. And, thought it was in a subdir of one of my dirs, the mounted filesystem is owned by root. I was able to create a file as my normal user, though the file became owned by root.

While I am appreciative that motub's solution worked and am glad you have it working, I do feel there are other ways.

Glad it helped, dolvmin. Matir, I just don't understand why umask=000 works at all, much less for you. umask is, after all, a mask of existing permissions, afaik-- not the same as a chmod or chown, which would actively change permissions. But I don't know everything there is to know about umask, so maybe there's something I'm not getting.

I do see, however, that your user has write permissions to the mount point in any case, so no mask is strictly necessary, and the fact that file was created with full 777 permissions for everybody supports the fact that no permissions are being masked (which is what I would expect of umask=000; the permissions remain as default).

Although I don't have a vfat partition to test on atm, I notice that creating a new folder in /usr/local/games (which I do have group permissions to write to, though I am not the owner), creates a folder with the same permissions as the parent folder (noticeably missing some permissions from the default 777, in fact it's 771, and that is in fact an active change which I myself made from the other 'default' folders in /usr, which have permissions of 755 (all, rx, rx). That suggests that the default folder creation permissions in Gentoo are 755 (as it is with most other distributions, afaik), meaning a mask of 022. Turns out that the default umask is indeed 022 in Gentoo, set in /etc/login.defs.

So, fine, I get it, if you then export umask=000, that overrides the default umask of 022, reverting your permissions to the Linux defaults of 777/666?

If that's the case, I can accept it as a valid way to solve the problem (if my acceptance means anything, which it doesn't, and it does not solve the issue of the permissions of the mount point itself). It still seems less practical than setting everything explicitly in the first place, though, because you can't control specific permissions, which is important when dealing with Windows files that may be run at some point under Windows, and possibly even just generally, depending on how much you care about security and restricting access. Especially if you want to mount stuff to your /home directory rather than /mnt, and share it across the network, but only to specific users (given that /home is more convenient, but less secure, than folders mounted somewhere under /, and also, if you want to share directories, you 'normally' can only share them from $HOME).

After all, if you have to research and decide which umask=blahblahblah to specify instead of umask=000, in order to actively control permissions rather than just giving carte blanche, you might just as well do all of the setting up, not just some of it. But that's just my opinion.

Well, there are multiple ways to view any situation. And, of course, I'm only talking about vfat permissions here. As I understand it, the permission of the whole filesystem and all included files will be:
Ownership will be based on who mounted the partition. Note this: if a mountpoint is owned by root, but a filesystem marked as "user" is mounted, the mountpoint suddenly becomes owned by the user doing the mounting.

Anyway, the OPs problem is solved and I think we're just going in circles discussing two approaches to the problem.

Hello,
I've seen this same problem latelly with FC5 and after digging around newsgroups and checking these permissions I got still access denied.
I've found that what it was influencing the permissions at the diferent partitions ( I've tried with /boot which is ext3, and an external disk added) was controlled by SELINUX.

So if you want to share a new mounted partition ( whatever the system ) I suggest you read the man for samba_selinux. There it's well explained what you'll need to do :
All files/ directories that you need to share need to be flagged with samba_share_t with :

> chcon /<your folder here> samba_share_t

To put this change permanent you need to change a file in /etc/selinux - contexts_files ( I don't have the value here - check the man page I mention above...)
.
BUT not all is finished!!!!
!
After this I got almost my machine dead hanged because logwatch was checking the new folder that I flagged ( and since the mounted partition has 300 GB of data it was taking about 1/2 day to check all !!!!)
So I for the moment I've removed logwatch script that is on the anacron.daily folder... I still need to fix this- that Logwatch doesn't verify my 300 gb mount.... Any Ideas on this ???.
Hope it helps.

man i'm glad i found this post. I've return to Linux after a couple of years with FC5. I was fighting to mount my Windows partition and get write access to it as user. Motub solution works fine for me.

Boy, why make that so complicated for home users. Pretty over the top i think.

Thanks for solving "one" of my problems though...

I am working with Suse 10.
I am trying to mount at /net/localhost/vfat
I have tried with every config I have found for my /etc/fstab

but not working... after mounting the /net/localhost/vfat gets "root root" (as user and group)

??????

how could I change group to users?