On Wed, Jan 13, 2021 at 11:02:28AM -0600, Larry Finger wrote:
> On 1/13/21 4:16 AM, Sérgio Basto wrote:
> > Do you use in kernel module or vboxsf from virtualbox sources ?
>
> * am using the kernel module. Changing to kernel 5.9 does not help. I
> suspect the problem is with mount.vboxsf.
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.
> Larry
Cheers,
Brent
_______________________________________________
vbox-dev mailing list
vbox-dev@virtualbox.org
https://www.virtualbox.org/mailman/listinfo/vbox-dev
