VirtualBox disrespects umask when creating files in shared folders => Fixed in SVN

[László Monda]

I want my WinXP guest to create files using shared folders on the filesystem of my Gutsy host with the permission 644. I set umask to 0022, but VirtualBox creates files with permission 600.

I've even modified the VirtualBox script right before

exec "/usr/lib/virtualbox/VirtualBox" "$@"

to include

umask 0022

but VirtualBox obviously disrespects umask by creating files with permission 600.

[Andrew]

I acknowledge this bug and propose it being fixed.

Is there a quickfix?

[Dimas Souza]

I acknowledge this bug also and propose it being fixed.

Is there a workaround?

[Dimas Souza]

btw: I am using VirtualBox 2.1.2r41885

[Dimas Souza]

More info: When creating directories, the permissions are bein correctly created.

[pt]

omg i am retarded

[P. Meiser]

I would also be interested in a solution.

[Marc Schütz]

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.

[Matt Kynx]

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?

[P. Meiser]

Issue is also present in 2.2.0 beta2.

[Frank Mehnert]

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.

[P. Meiser]

works perfectly in 2.2.0. From my POV, this ticket can be closed.

[P. Meiser]

Issue is there again with 3.0.0.

[umoeller]

Fixed in 3.0.2.

[pepijnve]

I'm getting this behavior again in 3.1.6. getfacl output of all existing directories is

# file: Snapshots/
# owner: root
# group: vboxusers
# flags: -s-
user::rwx
group::rwx
mask::rwx
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::r-x

However, newly created files get rw-------.

[P. Meiser]

Same for me with 3.1.6, although all files have permission 666 instead of 644 (as my umask is 0022).

[Marc Schütz]

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.

[Frank Mehnert]

To be sure: Which was the last working VBox release for you?

[Marc Schütz]

For me it was 3.1.4, but I did not test anything in between that version and the current one.

[Frank Mehnert]

Works fine here when creating a file manually or saving a page from the internet explorer. Linux host, WinXP guest. Do you have some simpler test? Don't have Office available here...

[Marc Schütz]

This bug is still there in version 3.2.6.

[Frank Mehnert]

Well, if you don't answer my question I cannot help you.

[Marc Schütz]

No, I don't have a simpler test. But as you don't have office, I guess you still cannot help me.

[Marc Schütz]

This bug is still present in 4.0.8.

[Jordi]

This bug is still present in 4.1.18 and there's a similar ticket ​#10534

I wonder how such an important and basic issue keeps unsolved after 4 years!

[Frank Mehnert]

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.

[Jordi]

Ok, from the begining:

• Host is Linux, guest is Windows.
  
• Host shares a folder with permissions: xrwxrwxrw (full access everyone)
  
• Guest accesses the shared folder like \\vboxsvr\shared and creates a brand new file there.
  
• From the Linux host this new file has permissions: -rw-r--r-- (only the owner can write).
  
• No matter how umask is set in the Linux host.
  

If this is not the ticket for this example I apologize and I would ask you to point me in the right direction.

[Frank Mehnert]

That's a better description and this sounds more like this ticket. Have to reproduce this.

[Frank Mehnert]

Cannot reproduce this. This is what I did on a Linux host:

1. On the host, do umask 0.
2. On the host, start a Linux guest.
3. In the guest, do cd /shared_folder and touch foo
4. On the host, the file foo has -rw-r--r--.
5. In the guest, do umask 0 and touch bar
6. On the host, the file bar has -rw-rw-rw-
7. On the host, start a Windows XP guest.
8. In the guest, do echo 123 > buzz in a cmd.exe window
9. On the host, buzz has -rw-rw-rw-

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.

So what does not work for you?

[Jordi]

This are the detailed steps:

• On Linux host:

$ umask
0002
$ echo host > /shared/host.txt
$ ls -l /shared/*.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt

• Start a Windows guest and open a cmd.exe box:

echo guest > \\vboxsvr\shared\guest1.txt
echo guest > \\sol\shared\guest2.txt

• From the Linux host again:

$ ls -l /shared/*.txt
-rw-r--r-- 1 jordi sambausers 8 Jun 28 15:54 /shared/guest1.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/guest2.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt

Notes:

• umask is 0002 and it works as expected on Linux.
• \\vboxsvr\shared and \\sol\shared are excatly the same place (the later is shared by samba).
• The final results show us that accessing via \\vboxsvr sets permissions as -rw-r--r-- and any other user from the same group can't edit the file.
• I need to access via \\vboxsvr as the samba share may not be avaliable all time (due to VPN restrictions on the Windows guest).
• I'm using VBox 4.1.18 with Guest Additions 4.1.18.

[Jordi]

Wait, that's funny:

• On the same Windows guest, on the cmd.exe box:

attrib -a \\vboxsvr\shared\guest1.txt

• and back to the Linux host again:

$ ls -l /shared/*.txt
-rw-rw-rw- 1 jordi sambausers 8 Jun 28 15:54 /shared/guest1.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/guest2.txt
-rw-rw-r-- 1 jordi sambausers 5 Jun 28 15:54 /shared/host.txt

Now permissions are -rw-rw-rw- ...I don't get it...

May be a workaround? May be a security issue too?

[Jordi]

Time goes by and there is no news about this annoying bug :(

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!

Please, just apply the patch to your next release!

Guys from VirtualBox/Oracle, how can we get this fixed???

[Frank Mehnert]

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.

[Jordi]

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.

Once again, thank you for your support.

[gregthegeek]

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.

[dr2chase]

4.2.6, I see the problem running Virtual Solaris on top of MacOS.

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.

In case you still need assistance in reproducing this problem, here:

xxx:/mnt/sf_mywork/jdk8tl$ cat > foo
foo
xxx:/mnt/sf_mywork/jdk8tl$ ls -l foo
-rw-r--r--   1 root     vboxsf         4 Feb 23 12:11 foo
xxx:/mnt/sf_mywork/jdk8tl$ umask
0000

[dr2chase]

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.

[JWrong]

Remedy for this problem which worked for me is to set proper permissions and umask when mounting the shared folder.

Example:

mount -t vboxsf -o uid=1000,gid=1000,dmode=777,fmode=666 sharedfolder /var/www/website

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).

[roadworrier]

Thanks JWrong. After reading the 39 posts before yours, yours fixed everything for me. I put similar in /etc/fstab in the CentOS vm and all is well with the mount point on vm boot.

sharedfolder /var/www/website vboxsf  rw,uid=502,gid=502,dmode=777,fmode=666 0 0

(As one would expect the user that starts the VM on the host machine is going to need write access to the directory shared, if the VM's user is going to be able to write to it.)

Replying to JWrong:

Remedy for this problem which worked for me is to set proper permissions and umask when mounting the shared folder.

Example:

mount -t vboxsf -o uid=1000,gid=1000,dmode=777,fmode=666 sharedfolder /var/www/website

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).