shared folders not working correctly on Lubuntu 18.0.4 guest

[ccox]

Shared folders worked on Lubuntu 16 but failed after I upgraded to 18.0.4 (thankfully I have a backup copy of 16). The shared folders mount points do not show up on reboot, and I have to re-run the installer script from the additions CD image after each reboot. The mount points (sf_source) then show up in /media/... but get a permission denied error trying to view them. This appears to be a permission (or access list) problem in creating the mountpoint directories, and I can view the contents of the directories with "sudo ls /media/sf_source'. This sudo workaround, is, of course, not something I can actually live with. I have tried reinstalling/rebuilding the guest additions multiple times, without a change in behavior.

[ccox]

log from Lubuntu 18.0.4 guest usage today

[ccox]

Still happening with VirtualBox 5.2.16

[PaulForgey]

I also have this issue, VirtualBox 6.0, Ubuntu 19.10 (macOS 10.14.6 host).

$ id
uid=1000(paulf) gid=1000(paulf) groups=1000(paulf),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),111(lxd),116(lpadmin),117(sambashare),998(vboxsf)
$ ls -ld /Users/paulf
ls: cannot access '/Users/paulf': Permission denied
$ sudo ls -ld /Users/paulf
drwxrwx--- 1 root vboxsf 2048 Feb 17 11:03 /Users/paulf

[Frank Batschulat (Oracle)]

Replying to PaulForgey:

I also have this issue, VirtualBox 6.0, Ubuntu 19.10 (macOS 10.14.6 host).

$ id
uid=1000(paulf) gid=1000(paulf) groups=1000(paulf),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),111(lxd),116(lpadmin),117(sambashare),998(vboxsf)
$ ls -ld /Users/paulf
ls: cannot access '/Users/paulf': Permission denied
$ sudo ls -ld /Users/paulf
drwxrwx--- 1 root vboxsf 2048 Feb 17 11:03 /Users/paulf

Let me guess: /Users/paulf is the shared folder inside the guest?

Should I guess more? VirtualBox 6.0 is rather outdated, perhaps you use 6.0.16 which is the latest?

I can try more guessing, I suppose it's better if you can provide a proper written problem statement which included a description of your particular setup.

Otherwise I can only reply with "This works for me in 6.0.16 and 6.1.2".

NB: some Linux version do require to logout and login again once you've edited /etc/group to add a user to the vboxfs group, some Linux version even seem to cache it and require an entire reboot to make /etc/group changes visible and working. So when exactly is your problem happening?

[PaulForgey]

I believe I've found the cause for this and a workaround.

The mount point was created automatically by adding the shared folder to the VM while creating it and installing.

The underlying mount point was created root:root drwxr-x---, thus unreadable and unsearchable by anyone outside root/root. Even though once mounted the root of the mounted fs had the group vboxsf, the underlying mount point are the permission which will be used to traverse over to that filesystem.

The workaround is to temporarily umount and chgrp vboxsf on the mount point.

[Frank Batschulat (Oracle)]

Replying to PaulForgey:

I believe I've found the cause for this and a workaround.

The mount point was created automatically by adding the shared folder to the VM while creating it and installing.

The underlying mount point was created root:root drwxr-x---, thus unreadable and unsearchable by anyone outside root/root. Even though once mounted the root of the mounted fs had the group vboxsf, the underlying mount point are the permission which will be used to traverse over to that filesystem.

The workaround is to temporarily umount and chgrp vboxsf on the mount point.

How is your shared folder setup, have you made any manual changes to the automatic default settings for the mount point ?

the typical top-level mountpints for automounts and removable media in Linux, /media and /run/media are created by the OS itself at OS installation time and are outside the control of Virtualbox. The OS installation has those directories packaged and whatever default permissions applied to based on the distributions Linux package content.