VirtualBox

Opened 13 months ago

Closed 13 months ago

Last modified 13 months ago

#21816 closed defect (invalid)

Shared folders group owner set to root instead of vboxsf

Reported by: domp Owned by:
Component: shared folders Version: VirtualBox-7.0.10
Keywords: vboxsf group owner Cc:
Guest type: Linux Host type: Linux

Description (last modified by domp)

Mounting a shared folders in a Linux guest VM, the owner group is set to root instead of vboxsf, this forbid the users to fully access to the folder.

Furthermore the permission set to files are quite strange, on the first level files have 664 (or 774), in deeper levels have 660 (or 770). (Not a VBox issue)

My VB host is Linux Mint 20.3, and guests where I observed the issue are MXLinux 23 and Linux Mint 21.2.

Step to reproduce the issue:

  1. Create a Shared Folder (I shared: Downloads);
  2. Add current VM Guest user to vboxsf group sudo usermod -aG vboxsf $(whoami) and restart the guest;
  3. Create mountpoint;
  4. Check mountpoint owners are <myuser>:<myuser>;
  5. Manually mount shared folder:
    sudo mount -t vboxsf <sf_name> <sf_mountpoint>
    
  6. Check mountpoint owners, you'll find root:root;
  7. User cannot fully access to data even he's member of vboxsf.

As workaround you have mount the shared folder passing the gid parameter to force the ownership to vboxsf.

sudo mount -o gid=<vboxsf gid> -t vboxsf <sf_name> <sf_mountpoint>

Attachments (4)

VBox.log (129.4 KB ) - added by domp 13 months ago.
VBox.log.1 (293.2 KB ) - added by domp 13 months ago.
VBox.log.2 (292.6 KB ) - added by domp 13 months ago.
VBox.log.3 (336.3 KB ) - added by domp 13 months ago.

Download all attachments as: .zip

Change History (11)

by domp, 13 months ago

Attachment: VBox.log added

by domp, 13 months ago

Attachment: VBox.log.1 added

by domp, 13 months ago

Attachment: VBox.log.2 added

by domp, 13 months ago

Attachment: VBox.log.3 added

comment:1 by domp, 13 months ago

Description: modified (diff)

comment:2 by galitsyn, 13 months ago

Hi domp,

I presume the guest is running in systemd environment. In this case you might need (likely) to reboot the guest in order to make usermod -a -G vboxsf <user> to take effect.

Regarding to file access modes, I do not see that we change it explicitly in driver unless it is specified with the mount -o option. Please compare access modes with the host side.

in reply to:  2 ; comment:3 by domp, 13 months ago

Replying to galitsyn:

Hi domp,

I presume the guest is running in systemd environment. In this case you might need (likely) to reboot the guest in order to make usermod -a -G vboxsf <user> to take effect.

Regarding to file access modes, I do not see that we change it explicitly in driver unless it is specified with the mount -o option. Please compare access modes with the host side.

Hi galitsyn, thanks for your answer. Yes, guests are running in systemd environment. Anyway I already added the user to vboxsf group and rebooted the machine several times from that moment.

The issue I observed is not related to the user membership, but the fact that the mount set, by default, the owner of the shared folder to root:root instead of root:vboxsf (like it was on 6.1.x releases).
Indeed if I mount the shared folder adding the explicit parameter -o gid=<vboxsf_gid>, I can access to data.

About the access modes, indeed, it could be caused by the host side, I'll update the ticket description to remove it from the scope.

Last edited 13 months ago by domp (previous) (diff)

comment:4 by domp, 13 months ago

Description: modified (diff)

in reply to:  3 ; comment:5 by galitsyn, 13 months ago

Replying to domp:

Replying to galitsyn:

Hi domp,

I presume the guest is running in systemd environment. In this case you might need (likely) to reboot the guest in order to make usermod -a -G vboxsf <user> to take effect.

Regarding to file access modes, I do not see that we change it explicitly in driver unless it is specified with the mount -o option. Please compare access modes with the host side.

Hi galitsyn, thanks for your answer. Yes, guests are running in systemd environment. Anyway I already added the user to vboxsf group and rebooted the machine several times from that moment.

The issue I observed is not related to the user membership, but the fact that the mount set, by default, the owner of the shared folder to root:root instead of root:vboxsf (like it was on 6.1.x releases).
Indeed if I mount the shared folder adding the explicit parameter -o gid=<vboxsf_gid>, I can access to data.

About the access modes, indeed, it could be caused by the host side, I'll update the ticket description to remove it from the scope.

Hi domp,

Normally (by default), a shared folder would be mounted on system boot by VBoxService daemon. VBoxService will evaluate gid of vboxsf group and specify it in mount options explicitly. If you mount folder manually, you would need to do it yourself. This ticket looks as "not an issue" to me.

in reply to:  5 comment:6 by domp, 13 months ago

I remember that in 6.1.x releases vboxsf was set also mounting manually a shared folder, maybe I'm wrong.
Anyway, I tested the automount and can confirm that vboxsf was set as group owner of the shared folder.
So if it's the expected behavior, I agree with you to cancel this issue ticket.

Thanks a lot

Replying to galitsyn:

Replying to domp:

Replying to galitsyn:

Hi domp,

I presume the guest is running in systemd environment. In this case you might need (likely) to reboot the guest in order to make usermod -a -G vboxsf <user> to take effect.

Regarding to file access modes, I do not see that we change it explicitly in driver unless it is specified with the mount -o option. Please compare access modes with the host side.

Hi galitsyn, thanks for your answer. Yes, guests are running in systemd environment. Anyway I already added the user to vboxsf group and rebooted the machine several times from that moment.

The issue I observed is not related to the user membership, but the fact that the mount set, by default, the owner of the shared folder to root:root instead of root:vboxsf (like it was on 6.1.x releases).
Indeed if I mount the shared folder adding the explicit parameter -o gid=<vboxsf_gid>, I can access to data.

About the access modes, indeed, it could be caused by the host side, I'll update the ticket description to remove it from the scope.

Hi domp,

Normally (by default), a shared folder would be mounted on system boot by VBoxService daemon. VBoxService will evaluate gid of vboxsf group and specify it in mount options explicitly. If you mount folder manually, you would need to do it yourself. This ticket looks as "not an issue" to me.

comment:7 by galitsyn, 13 months ago

Resolution: invalid
Status: newclosed

You are welcome. Closing.

Last edited 13 months ago by galitsyn (previous) (diff)
Note: See TracTickets for help on using tickets.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy Automated Access Etiquette