[vbox-dev] Shared folder automount only mounts volumes as root on Linux

[Larry Finger]

On 1/13/21 11:59 AM, Brent Paulson wrote:
> This sounds like a mismatch between the VirtualBox-supplied mount
> utilities and the Linux-supplied shared folder kernel module.  The
> VirtualBox mount.vboxsf utility and the VBoxService automount utility
> both call mount(2) with a 'data' argument containing a
> 'vbsf_mount_info_new' structure filled in with the mount details.  The
> VirtualBox shared folders kernel module knows how to parse this
> structure but if the VirtualBox mount.vboxsf utility is used with a
> Linux shared folder kernel module on a recent Linux kernel then the
> fs_context_operations parse_monolithic function will be called which on
> Linux is currently:
> 
> static int vboxsf_parse_monolithic(struct fs_context *fc, void *data)
> {
>      unsigned char *options = data;
> 
>      if (options && options[0] == VBSF_MOUNT_SIGNATURE_BYTE_0 &&
>                 options[1] == VBSF_MOUNT_SIGNATURE_BYTE_1 &&
>                 options[2] == VBSF_MOUNT_SIGNATURE_BYTE_2 &&
>                 options[3] == VBSF_MOUNT_SIGNATURE_BYTE_3) {
>          vbg_err("vboxsf: Old binary mount data not supported, remove obsolete mount.vboxsf and/or update your VBoxService.\n");
>          return -EINVAL;
>      }
> 
>      return generic_parse_monolithic(fc, data);
> }
> 
> The 'vbsf_mount_info_new' structure contains the identifying signature
> bytes referenced above which explains why the mount options such as
> uid=123 aren't seen when there is a userland vs. kernel mismatch.
> 
> The VirtualBox mount utilities are going to start calling mount(2) with a
> 'data' argument containing a string of comma-separated mount options in
> the not-too-distant future so that any mismatch going forward won't
> cause such surprises.

Brent,

Thanks for the update. I look forward to the not-too-distant update.

Larry