Ticket #18345 (closed defect: fixed)

Opened 4 months ago

Last modified 5 days 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


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:

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 4 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 4 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 4 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 4 months ago by random (previous) (diff)

comment:4 Changed 4 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 4 weeks 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 5 days ago by michael

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use