VirtualBox

Ticket #18345 (closed defect: fixed)

Opened 10 months ago

Last modified 4 months ago

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

Reported by: random 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

comment:1 Changed 10 months ago by random

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.

comment:2 Changed 10 months ago by 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.

comment:3 Changed 10 months ago by random

@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.
Last edited 10 months ago by random (previous) (diff)

comment:4 Changed 10 months ago by 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.

comment:5 Changed 7 months ago by bird

  • Summary changed from Read-only flag of shared folders: not handled properly under Windows Host Linux Guest to 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 Changed 6 months ago by michael

  • Status changed from new to closed
  • Resolution set to fixed

comment:7 follow-up: ↓ 8 Changed 4 months ago by Daniel Pielmeier

  • Status changed from closed to reopened
  • Resolution fixed deleted

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.

Last edited 4 months ago by Daniel Pielmeier (previous) (diff)

comment:8 in reply to: ↑ 7 Changed 4 months ago by 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

comment:9 Changed 4 months ago by Daniel Pielmeier

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

comment:10 Changed 4 months ago by michael

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:11 Changed 4 months ago by 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.

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use