Linux – How to set the owner of a mounted partition in Linux

You can set some mounting options while mounting your the shared folder on the guest OS - here are the available options:

http://manpages.ubuntu.com/manpages/maverick/man8/mount.vboxsf.8.html

There are many solutions to your problem:

• To make the files seen as owned by your VirtualBox user's uid and gid (using the uid and gid mounting options).

• To override the mode of all files/directories using dmode and fmode options.

• To change the umask on your host to a less restrictive mask.

I usually prefer the first option. In your case the entry to the /etc/fstab file should look like this:

dev /var/www vboxsf umask=0022,gid=33,uid=33

But I don't really get the concept of a group. From what I've gleaned a group is just a bunch of users. (But does that mean a user can belong to multiple groups?)

Yes, and yes.

A group as I understand is basically meant to make it easier to set/unset rwx permissions wholesale for a bunch of users (i.e. the group).

One way it makes setting permissions much easier is when group needs access to many files or folders scattered around the system.

For example, whenever a new user joins, you would otherwise need to find all those files one by one and try to guess things like "if users A,B,C have access, then user D should be added". But if those permissions simply list a group name, then you don't need to update them at all – instead you just add the user to a group, done.

(It's not limited to just file permissions – some system services may also be configured to grant access to a group instead of individual users, with the same advantages as here.)

Does that mean that in addition to a file having an owner (i.e. the userid of the person who created the file) there is also a "group owner" for that file? And is this group typically one of the groups the file-owner belongs to?

Yes. Each user has a "primary group", and newly created files belong to that group. However, even non-root users can use chown/chgrp to reassign their own files to any group that they currently belong to.

(There's an exception: If the directory has the 'setgid' bit set, then newly created files in it inherit the directory's group, not the creator's. This is closer to how Windows NTFS works by default.)

Of course, this "group owner" system is a bit limiting when files can only have one group at a time. See the next section about that.

What if I have three groups A,B,C on my system and want to set permissions rw-, -wx, r-x respectively on the system?

Then you use another feature called "ACLs" (access control lists), which – as the name implies – allows you to specify an arbitrary list of users and groups to give access to.

Linux supports the POSIX ACL format, which is mostly a straightforward extension of the existing model. That is, if you first rewrite the existing permissions as:

user::rwx, group::r-x, other::---

now you can use setfacl or chacl to add your three additional groups as:

group:Family:rw-, group:Friends:-wx, group:Coworkers:r-x

Note to avoid confusion: POSIX ACLs try to remain compatible as much as possible with traditional chmod, but this leads to a surprising feature. As soon as you add ACLs to a file, the "group" field in ls -l will instead start showing something called a 'mask', and a command like chmod g-w will deny write access to all ACL entries, not just to the "owner group".

Why does Linux, or even Unix, use the 'owner/group/other' categorization if it could just use ACLs instead? It does because this simple categorization predates ACL support by decades.

Unix originally went for the simple approach, as most other operating systems did at the time – either due to disk space constraints (permission bits fit in just two bytes), and/or deliberate design decision (Multics may have had elaborate ACLs at the time, but plenty of things in Unix were intentionally simplified).

Eventually the APIs became set in stone – new ones could be added, but the existing "chmod" could not be changed, because programs already expected it to work in a certain way. (OpenVMS too had to keep its similar permission-bit system even after adding ACLs.)

In addition to that, unfortunately it's the only system cross-compatible between all of the Unix-like operating systems. Some other Unixes (e.g. FreeBSD, Solaris) may use a quite different ACL format, and yet others (OpenBSD) have no ACL support at all. Compare also to Windows, where all file protections are ACL-based.