virtualbox.org

Odd behaviour by file permissions on a file share causing confusion.

Host is Windows 10, running Virtual Box v5.2.26 r128414. Guest is Linux Mint 18.3. Both operating systems are fully patched up.

Host has opted to share a folder with guest, set in VB to auto-mount, full access and made permanent. Read-only is off.

Guest has installed VB Guest Additions, mounted the share (sudo mount -t vboxsf), as described here. In addition, the Linux admin user and the Linux non-admin user are made members of group vboxsf.

All sort-of works, except that while some folders within the mounted fileshare are properly fully controlled by both users... but other folders are not. In the same fileshare, it should be all wholly consistent. The inconsistency is doing my head in!

The file permissions are equal in a sample of inconsistent folders, ie.:
Root of fileshare: drwxrwxrwx 1 root root 24576 Mar 9 16:44 temp backup to file
File in a sub-folder that works normally: -rwxrwxrwx 1 root root 229 Mar 5 23:29 script
File in a sub-folder that does not work normally: -rwxrwxrwx 1 root root 4543 Jun 29 2014 wkp- Wendover.kmz

The non-admin user sees different options greyed out in the popup context menu, as attached.

Both admin and non-admin Linux users cannot rename, edit or create files in folders whose permissions are somehow corrupted.

There is no impediment to read-write-edit in the host's folders.

Is there a known fix? If not, what is the next step in the diagnosis?

How would you expect Linux permissions to be implemented on an NTFS filesystem? They won't.

Shared folders are not drives, they are a file sharing software protocol like FTP. Permissions only have meaning if the protocol supports the concept, and it generally will be in a platform independant form.

So, you're saying that if the client has given full control permissions, and the host has given full control permissions, and the middleman (VirtualBox) has (apparently) given full control permissions, it's designed not to work anyway, because the middleman doesn't get involved in mapping differential permissions?

taxedserf wrote:Host has opted to share a folder with guest, set in VB to auto-mount

taxedserf wrote:mounted the share (sudo mount -t vboxsf), as described here.

You're using both automount and manual mounting, following a 10-year old article. Have you tried just the automount part? Or just the manual one?

The only way I found to have the guest see, read, edit, sometimes-create the content of the host's share was to adapt the 10-year old article.

Stage 1: in the host's Virtual Box, to map the folders as shares.
Stage 2: in the Linux guest, to mount the shares presented to it by Virtual Box.

Stage 1 as per the attached screenshot.
Stage 2:
In /etc/rc.local: The guest user account who needs to use these shares is a member of group "vboxsf", but (rightfully) has no root/admin rights.

When I first tested this, I did only stage one, and no users on the guest could see the shares. They became visible to the guest's root and non-root users when stage 2 was done and both users were in group "vboxsf".

Other (aged) commentators - outside Virtual Box, blogging their "how to..." instructions suggested mounting in /mnt/ rather than /media/ (which VB does if set to so automatically) and to use rc.local instead of fstab to converse the share between user logins on the Linux guest.

taxedserf wrote:The only way I found to have the guest see, read, edit, sometimes-create the content of the host's share was to adapt the 10-year old article.

Can you please forget that and start fresh? 10 years in the life of a software is aeons!

taxedserf wrote:Stage 1: in the host's Virtual Box, to map the folders as shares.

Good.

taxedserf wrote:Stage 2: in the Linux guest, to mount the shares presented to it by Virtual Box.

No need to, you're confusing the whole thing!

Stage 2 is now reversed (the rc.local file is now modified to comment-out the mount commands). After specific re-tests with re-boots, the ordinary (non-admin) user can read, write and create files as expected, without intervention from the admin user. The ordinary user is still a member of vboxsf.

Superb, many thanks!

Glad you got it going. And thank you for marking the topic as [Solved]...