I have a FreeBSD-13.0-BETA3 virtualbox VM on a Windows 10 host. Every time I try to mount a shared folder, the virtual machine reboots. The VirtualBox host is version 6.1.16 r140961. I have installed emulators/virtualbox-ose-additions from packages and have compiled it from ports, with no success. I also have a 12.2-RELEASE VM on the same host that mounts the shared folder without issues with the same configuration and using the same steps. On this VM, I manually load /boot/modules/vboxvfs.ko, then run mount_vboxvfs -w, at which point it reboots. This has been consistent behavior since 13.0-ALPHA, and is still present in 13.0-BETA4. I have not seen any other reports of this happening.
I just tested with 13.0-RC1, and am having the same issue
Confirmed with 6.1.18 host. Actually yesterday's update of emulators/virtualbox-ose-additions to 6.1.18 makes it even worse: system crash upon "service vboxservice start". This is stable/13-n244826-c4dbe899aa0 marginally beyond RC1.
This looks like 244962 John groenveld@acm.org Index: files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c =================================================================== --- files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c (revision 568115) +++ files/patch-src_VBox_Additions_freebsd_vboxvfs_vboxvfs__vnops.c (working copy) @@ -1,6 +1,6 @@ --- src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c.orig 2021-01-07 15:34:22 UTC +++ src/VBox/Additions/freebsd/vboxvfs/vboxvfs_vnops.c -@@ -14,228 +14,1347 @@ +@@ -14,228 +14,1351 @@ * VirtualBox OSE distribution. VirtualBox OSE is distributed in the * hope that it will be useful, but WITHOUT ANY WARRANTY of any kind. */ @@ -160,6 +160,10 @@ + .vop_write = vboxfs_write, + .vop_bmap = VOP_EOPNOTSUPP }; ++ ++#if __FreeBSD_version > 1300000 ++ VFS_VOP_VECTOR_REGISTER(vboxfs_vnodeops); ++#endif -static int vboxvfs_access(struct vop_access_args *ap) +static uint64_t
(In reply to groenveld from comment #3) Thanks! Indeed that fixes the case for me.
I'll have opportunity to test this patch this week. I'll report back my findings.
Fixed by PR 255208 which is a late duplicate.
Fixed by ports 8a311de0cb804d as reported in bug #255208 I was not aware of this previous submission, sorry.