The problem is that VirtualBox specifies a mode of 0600 when creating a file. This can be trivially fixed by using 0666 instead, which would then automatically be combined with the umask to yield 0644 (see the attached patch vbox-umask.patch).

However, I do not know the reason why 0600 has been used there in the first place.

This is a big one for me (OSX host, Linux guest). If I mount a group-writable directory, when users in that group create files they can't even read them!

I can understand it if the guest OS doesn't support the concept of a umask - perhaps then the solution would be to add a 'cmode' option to the mount command? But if OS does support umask wouldn't it make sense to honour it?

A simple fix will be contained in the upcoming release. The file permissions will be 0222 if the guest opened the file write-only, 0444 if the guest opened the file read-only and 0666 if the guest opened the file with read/write permissions.

I can confirm this regression with 3.2.4. Btw, the permissions are correct when the file is created via Right Click -> New -> ... in Windows Explorer; but in Office (2007 here) it sets 666 instead of 644.

This bug has nothing to do with #10534. And if you would take some time and actually read the above comments then you would observe that there is no simple test case to reproduce the problem of this ticket.

I used VBox 4.1.18 with Guest Additions 4.1.18. Keep in mind that the guest umask is also respected, i.e. if the guest creates a file with umask 022 then the file on the host cannot have the 'w' bit set for group and others.

It is supposed to be fixed in the past but somehow the patch attached to this ticket is NOT applied in VirtualBox 4.1.x series (I've downloaded the source files for VirtualBox 4.1.18 and witnessed that the old wrong code is actually there).

So far the only working workaround I've found is to schedule cron to reset the file permissions on the Linux host. Something like:

*/5 * * * * chmod -R 777 /Shared

(this should reset permissions on /Shared and subfolders every 5 min. Not nice, I know)

So, there's a problem. We've detected it. We've reported it. We've got a patch to solve it... and this ticket remains open (re-open) for so long!

The patch is wrong as it changes the umask to every file which is created by VirtualBox on the host. And no, we cannot rely on the user setting the umask variable correct. Oracle has a policy to not grant more permissions to a file than necessary.

We will try to reproduce your scenario when we find some time, other issues are waiting for a fix as well.

First of all, thank you for your answer and your effort. I'm sure there're many other things to attend to and I appreciate your feedback on this ticket.

On the other hand, respectfully and in my humble opinion, this issue remains open for too long now (4 years?) to just let it go with a "when we find some time for it". Is it possible to know a more specific time frame?

Finally, I agree the patch it's not the perfect solution. The perfect solution would be VirtualBox to respect the system umask. But since in VirtualBox one can choose which folders will be shared (security issues can be contained), I prefer to allow access to everyone (as the patch do) than not having the option to share any file with other users.

Just wanted to chime in on this issue. I think I am seeing similar. Windows XP guest, guest additions installed, mapped to vboxsvr\share. LInux host (Ubuntu 12.04) shows files created as root and 0644 when umask is 0002. I need group ownership to be rw in this system. As a workaround I will probably just map to samba, but I like the idea of using the Vbox share better and skipping that whole smb thing.

Would it be too hard, if you cannot by default trust a Unix user to use Unix as Unix was intended to behave, to add an option that could be changed by people who need Unix to actually be Unix? This is a show-stopper for me -- if I have to copy the files anyway to get the permissions I need, I might as well use a Real Box instead. The development tools I use don't work with this broken file system.

PS, on the security front, I think you guys are missing the forest for the trees. Look at the workaround people are using -- as a very first step, they are doing "chmod -R go+w ." on the entire shared directory. One guy up there has a cron job doing this. Your "enhanced security" is inducing user behavior that is far less secure than anything they would do by accident using VirtualBox.

The feature I think I'm after and that sounds like it would cause fewer problems for people like me is an option to map a subset of the host users directly into the virtual box OS, and to mirror shared files straight through. Not sure how hard this would be, but it's what I want, and I would no longer need to do wholesale permission changes in shared directories just so I could use them properly in VirtualBox. This has a minor incompatibility with what appears to be the current rule of mapping the VirtualBox process owner to root in the VM.

uid and gid are the ids of the user and group which will have ownership of the shared folder (in my case I've set these to be id and group of my apache2 process: www-data)
dmode and fmode are respectively new directory and new file permissions (decimal).

uid and gid are the ids of the user and group which will have ownership of the shared folder (in my case I've set these to be id and group of my apache2 process: www-data)
dmode and fmode are respectively new directory and new file permissions (decimal).