"Operation not permitted" on file in shared folder

[bompus]

• Host: Windows 7 x64
• Guest: Linux CentOS 6.7 x64 ( VirtualBox Guest Additions 5.0.26 r108824 )

If you look at ticket #4890, which is very likely the same underlying issue, the most recent comment is still reporting the issue on 5.1.12

In a vbox shared folder:

[user@server ~]$ mount | grep vboxsf
sv on /sv type vboxsf (uid=500,gid=500,rw)
[user@server ~]$ sudo touch /sv/a.txt
[user@server ~]$ sudo chmod a-w /sv/a.txt
[user@server ~]$ sudo rm -f /sv/a.txt
rm: cannot remove `/sv/a.txt': Operation not permitted
[user@server ~]$ sudo chmod a+w /sv/a.txt
[user@server ~]$ sudo rm -f /sv/a.txt
[user@server ~]$

Not in a vbox shared folder:

[user@server ~]$ sudo touch /a.txt
[user@server ~]$ sudo chmod a-w /a.txt
[user@server ~]$ sudo rm -f /a.txt
[user@server ~]$

Possible related tickets:

• https://www.virtualbox.org/ticket/4890
• https://www.virtualbox.org/ticket/5568
• https://www.virtualbox.org/ticket/15083

[mil0s]

fix

[mil0s]

Same here. But since there are several reports of the same issue (one of which dates 7 years back) I've fixed it myself. What this patch essentially does is that if sf_rename or sf_unlink fails with -EPERM it will set write bit and retries the operation once again. Similar fix went to open-vm-tools for hgfs some time ago.

[bompus]

I appreciate the patch. I'm not keen on recompiling and running my own special version of the tools, so hopefully the devs will see this and consider rolling something similar into core so this issue can be resolved once and for all.

[Frank Mehnert]

First, thanks mil0s for the patch. Unfortuantely the problem is more difficult than it seems: If you do the same command in a Linux host which runs on a Linux host, removing the file will succeed. The reaon is that Linux and Windows apparently have a different semantic of the WRITE access bit of a file: On Linux it does no matter if the file is writable or not -- it can be removed as long as the directory where the file lives can be modified by the user. On Windows it is not possible to remove a file which is not writable.

We need to discuss the correct stragegy internally. Of course it would be better if from the guest points of view there is no difference. Therefore it might make sense to change the host side and not the guest side.

[mil0s]

Frank, you are right. Linux indeed only cares about write permissions (and possibly sticky bits) on directory where the file is so Linux host/guest works however Windows seems to handle it differently. Strangely enough removing readonly file on win works as expected.

Having said that I was thinking about modifying host side however I do not have experience with windows drivers so I chose the guest side modification instead. I agree that if it is possible to have this fixed on host side would be likely better but as I've mentioned same guest side fix got accepted in open-vm-tools for hgfs filesystem that had exactly the same problem (​https://sourceforge.net/p/open-vm-tools/tracker/163/).

Please let me know if there is anything else I can help with. We are moving to virtualbox for our local development and this is one of the major pain points at the moment so if there is anything I can do to speed things up just let me know.

[bompus]

Has there been any movement on this issue by the developers?

[Socratis]

You linked to a 7-year old, still open ticket (#4890), which is essentially the same bug, and you expect "movement" in 3 weeks? I'd say you're too optimistic sir... ;)

[bompus]

I'd expect it to be moved into a roadmap for completion, now that the bug has been acknowledged. The linked ticket has for the most part been ignored, then marked as obsolete without anybody actually verifying if the problem still existed or not. There are several related tickets, and discussions I've found on the forums which I believe are all linked to the core issue, so it would be nice to see it get some attention. Based on what I can tell with this ticketing system, I have no way of receiving email notifications when tickets are assigned, commented, completed, and I don't see anywhere that signifies that it's been put into a plan for completion, so my question remains.

Replying to socratis:

You linked to a 7-year old, still open ticket (#4890), which is essentially the same bug, and you expect "movement" in 3 weeks? I'd say you're too optimistic sir... ;)

[Klaus Espenlaub]

bompus: You should get notification mails if your email is correctly set with "Preferences" (see top right of the page in the bug tracker).