Read-only flag of shared folders: not handled properly under Windows Host Linux Guest => Fixed in SVN

[Gang Liang]

It is a known issue for Windows that read-only bit for directory has special meanings: it does not really mean read-only. Please see below for the KB article on this subject: ​https://support.microsoft.com/en-gb/help/326549.

Basically, read-only for a directory under Windows is ignored by Windows, and only used by File Explorer as a flag such that desktop.ini file will be used for folder customization. For instance, user Documents directory is read-only by default, yet users have no problem to modify files in it. This applies to Windows 10 as well.

Currently, Virtualbox takes the face value of the read-only bit of shared folders under Windows Host, yet it is not the correct interpretation of read-only bit for Windows directories. A quick search will find many reports of VBox shared folder read-only issues. Many time, users would like to access Documents, Download under Linux Host. Yet, these special folders would have strange behaviors under the guest.

I believe OS X guest suffers from the same issue.

[Gang Liang]

I just checked out the WSL implementation, seems Microsoft mounted all Windows directories as rwx in the Linux subsystem for now. Of course, it is brutal, yet they won't suffer from the read-only problem.

[Socratis]

VirtualBox's Shared Folders present a very simplified file system implementation, just enough to read/write files from/to the guest. Many applications can error when using Shared Folders, because they expect advanced features, for example file locking, access controls, etc., which don't exist as a concept for Shared Folders.

Specifically for your case, there are no access controls for Shared Folders.

[Gang Liang]

@socratis Yes, your points are valid.

For the defect submitted, it is not to ask for advance access control, but to see whether the vbox shared folder implementation can ignore the read-only attribute for Windows directories. It is the right behavior for Windows hosts.

Consider a scenario:

   1. attrib -r Documents                 # under Windows Host
   2. mount shared folder Documents       # under Linux guest
   3. mkdir Documents/test                # under Linux guest
   4. A few seconds later, Documents/test will become read-only under Linux guest b/c
      Windows host puts read-only and system attribute on it.

[bird]

This is a known issue with our simple mapping of DOS attributes to unix ones. In the DOS world the read-only attribute prevents you from deleting the directory or file, whereas on unix this is controlled by access to the parent directory (i.e. you need write access to the directory of the file/subdir you wishes to remove).

I believe you can work around this by using the dmode=0777 mount option.

[bird]

In 6.0.8 the read-only attribute will be ignored on directories when calculating the unix permission mask. So, directories like "Documents" that have it set will be writable on linux and solaris shared folder mounts without further hacks needed.

[Daniel Pielmeier]

I think this issue is not completely resolved with VirtualBox 6.0.8.

In my example the user running VirtualBox has full control on the shared folder of the host (Windows 10 Enterprise, 1803). The user within the Linux guest (Ubuntu 18.04.02 LTS) is in the is in the vboxfs group. The shared folder is mounted with the following options: rw,nodev,relatime,iocharset=utf8,uid=0,gid=999,dmode=0770,fmode=0770,tag=VBoxAutomounter

On the guest within a shell the user is able to create and and delete files and directories:

~/shared$ mkdir test
~/shared$ rmdir test
~/shared$ touch file
~/shared$ rm file

Under some conditions however there are permission problems.

For instance when using sed changing the permissions of the temporary file fails while the string replacement itself works fine:

~/shared$ echo YYY > file
~/shared$ sed -i -e "s/YYY/ZZZ/g" file
sed: preserving permissions for ‘./sedQaTRG2’: Operation not permitted
~/shared$$ cat file 
ZZZ
~/shared$ 

Within the guest there also runs OpenFOAM. One application namely ​foamListTimes which should remove files and directories fails to remove directories. I think it executes the rmdir function from ​POSIX.C

The output I get from foamListTimes is:

bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water/U.gz"
bool Foam::rm(const Foam::fileName&) : Removing : "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning : 
    From function bool Foam::rmDir(const Foam::fileName&)
    in file POSIX.C at line 1103
    failed to remove directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4/fluid_water"
--> FOAM Warning : 
    From function bool Foam::rmDir(const Foam::fileName&)
    in file POSIX.C at line 1073
    failed to remove directory "fluid_water" while removing directory "/home/openfoam/OpenFOAM/projects/debug/transient/processor3/4"

So it successfully removes the files within the directory "U.gz" but then fails to remove the directory "fluid_water" itself.

I think it is unnecessary to mention that all this works fine with VirtualBox 5.2.30.

[Socratis]

Replying to Daniel Pielmeier:

I think this issue is not completely resolved with VirtualBox 6.0.8.

Just FYI, ​VirtualBox 6.0.10 is out, maybe try with that first? It includes the following in the Changelog:

• Windows hosts: fix problems copying files from shared folders (bug #18569)
• Windows guests: many shared folders fixes

[Daniel Pielmeier]

Thanks for the heads up. Will try the new version and report back here!

[Daniel Pielmeier]

Okay I tested the new version. The permission problem is gone but the directory removal issue is still present. I am not sure about reopening this issue again as bug #18569 already mentions the same problem. So probably this issue should be reopened.