#18345 closed defect (fixed)
Read-only flag of shared folders: not handled properly under Windows Host Linux Guest => Fixed in SVN
Reported by: | Gang Liang | Owned by: | |
---|---|---|---|
Component: | shared folders | Version: | VirtualBox 6.0.2 |
Keywords: | read-only | Cc: | |
Guest type: | Linux | Host type: | Windows |
Description
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.
Change History (11)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
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.
comment:3 by , 6 years ago
@socratis Yes, your points are valid.
For the defect submitted, the request is not to ask for advance access control, but to ask vbox shared folder implementation to ignore the read-only attribute of Windows directories. It is right behavior for Windows hosts.
Consider the 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.
comment:4 by , 6 years ago
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.
comment:5 by , 6 years ago
Summary: | Read-only flag of shared folders: not handled properly under Windows Host Linux Guest → Read-only flag of shared folders: not handled properly under Windows Host Linux Guest => Fixed in SVN |
---|
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.
comment:6 by , 6 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
follow-up: 8 comment:7 by , 5 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:8 by , 5 years ago
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
comment:10 by , 5 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:11 by , 5 years ago
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.
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.