VirtualBox – Why Can’t I Chown a Shared Folder?

Some quick experimentation has confirmed my initial suspicion that Backup Operators is treated in the same way as Administrators, i.e., a user in the Backup Operators group is considered an administrator and given a split token. This means you need to elevate to take advantage of being a member of the Backup Operators group, in exactly the same way you need to elevate to take advantage of being a member of the Administrators group.

This makes sense, because malicious code running with backup operator privilege can easily leverage that privilege to give itself unlimited access.

Addendum: if I remember correctly, when this answer was first written Windows did not cope well with this scenario. This has since been fixed. If you attempt to elevate, e.g., using "run as administrator", you will be prompted for an administrative username and password. However, you can now provide your own username and password rather than an administrative one. The new process won't have administrator privilege, of course, but it will have whatever privileges and group memberships your account has been given, even if they would normally be filtered out.

The MSDN article "Teach Your Apps To Play Nicely With Windows Vista User Account Control" includes a list of all the groups and privileges that will cause a split token to be created.

Groups:

• Built-In Administrators
• Power Users
• Account Operators
• Server Operators
• Printer Operators
• Backup Operators
• RAS Servers Group
• Windows NT 4.0 App Compat Group
• Network Configuration Operators
• Domain Administrators
• Domain Controllers
• Certificate Publishers
• Schema Administrators
• Enterprise Administrators
• Group Policy Administrators

Privileges:

• SeCreateTokenPriv­i­lege
• SeTcbPrivilege
• Se­Take­Owner­ship­Priv­ilege
• Se­Back­up­Priv­i­lege
• Se­Re­store­Privilege
• Se­De­bug­Priv­ilege
• Se­Im­personatePrivilege
• SeRelabelPrivilege

Note: that list was written for Windows Vista. I do not know whether there have been any changes in later versions of Windows.

It seems to me that permissions are not correctly set.

1. you are user g and can read a file = OK

2. but you can't create a file in a destination because the directory media is not writeable by you, only root can do that

So either copy as root or change the permissions on target so that you have a write permission on media directory.

As pointed out it's not possible to change permissions nor ownership on mounted NTFS filesystem. In that case there is a possibility to use proper mount options. Bellow excerpt from man mount

uid=value, gid=value and umask=value

Set the file permission on the filesystem. The umask value is given in octal. By default, the files are owned by root and not readable by somebody else.

Example: (for /dev/sdc1 with FAT32 filesystem)

Check that the device is not mounted (following should return without output)

$ mount | grep sdc1

Mount the device with uid and gid option set

$ sudo mount /dev/sdc1 -o uid=1000,gid=1000 /mnt

Verify the mountpoint

$ mount | grep sdc1

/dev/sdc1 on /mnt type vfat (rw,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)