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 _______________________________________________ vbox-dev mailing list vbox-dev@virtualbox.org https://www.virtualbox.org/mailman/listinfo/vbox-dev
