vbox virtualbox paranoia.

Alain De Vos

Alain De Vos

/usr is a zfs mount
/usr/local is a zfs mount

Virtualbox will not start on mounted partitions !!! Due to hardening.

[No, to start virtualbox i need 4-way authentication with relevant information about the size of my shoes. Come on people ... (for a moment cynic)]

PS: Tried to compile virtualbox from source in order to disable stupid hardening . FreeBSD not recognised OS.

Currently trying to create a jail on ufs without mounts. I'm curieus.

Ooh & result, X forwarding of virtualbox does not work.

PS: I can install virtualbox in another directory , but links are hardcoded, so they will refer into /usr/local & this solution will also not work.
 
I should recompile virtualbox from the github repo and disable hardening in the config.
Problem , it does not compile , it does not recognise the OS.
Note, i'm lacking the knowledge of freebsd devel/virtualbox devs...
 
Alain De Vos said:
Virtualbox will not start on mounted partitions !!! Due to hardening.
Click to expand...
To which hardening are you referring to?

In a default installation (no specific ACLs, chmod(1) permissions set), assuming the user calling "virtualbox" is in the "vboxusers" group, "vitualbox" runs just fine, whether "local" in /usr/local is a zfs dataset mount point or a regular directory of /usr/.
 
No it does not for me. But i must analyse further.

Could not launch the VM process for the machine 'y' (VERR_ACCESS_DENIED).

Resultaatcode:VBOX_E_IPRT_ERROR (0x80BB0005)
Component:MachineWrap
Interface:IMachine {85632c68-b5bb-4316-a900-5eb28d3413df}


==================================================
Code: 
$ VBoxManage list vms
"y" {08a69dd0-79bc-4cc0-ba6f-98c3d36de367}

Code: 
x@myfreebsd:~ $ VBoxManage startvm "y"
VBoxManage: error: Could not launch the VM process for the machine 'y' (VERR_ACCESS_DENIED)
VBoxManage: error: Details: code VBOX_E_IPRT_ERROR (0x80bb0005), component MachineWrap, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LaunchVMProcess(a->session, sessionType.raw(), ComSafeArrayAsInParam(aBstrEnv), progress.asOutParam())" at line 729 of file VBoxManageMisc.cpp

Code: 
x@myfreebsd:~ $ VBoxManage list hdds
UUID:           90323de4-99a1-4faf-adff-2a17bc5a639a
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /MABOX/mabox_raw.vmdk
Storage format: VMDK
Capacity:       204800 MBytes
Encryption:     disabled

Code: 
x@myfreebsd:~ $ VBoxManage showmediuminfo "/MABOX/mabox_raw.vmdk"
UUID:           90323de4-99a1-4faf-adff-2a17bc5a639a
Parent UUID:    base
State:          created
Type:           normal (base)
Location:       /MABOX/mabox_raw.vmdk
Storage format: VMDK
Format variant: fixed unknown
Capacity:       204800 MBytes
Size on disk:   204800 MBytes
Encryption:     disabled
In use by VMs:  y (UUID: 08a69dd0-79bc-4cc0-ba6f-98c3d36de367)

Please note the raw disk is on a partition on a disk where on that same disk other partitions are mounted.
 
I new it ...

root@myfreebsd:~/VirtualBox VMs/y # VBoxManage startvm "y" --type headless
Waiting for VM "y" to power on...
VBoxManage: error: Failed to load R0 module /usr/local/lib/virtualbox/VMMR0.r0: Symlinks are not permitted: '/usr/local' (VERR_SUPLIB_SYMLINKS_ARE_NOT_PERMITTED).
VBoxManage: error: Failed to load VMMR0.r0 (VERR_SUPLIB_SYMLINKS_ARE_NOT_PERMITTED)
VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component ConsoleWrap, interface IConsole
root@myfreebsd:~/VirtualBox VMs/y #
 
1. Check for Volume Metadata Protection

Even with debug flags, FreeBSD may still block writes if it detects a valid GEOM provider (like a UFS/ZFS signature) on the partition you are passing to the VM.

  • Identify the partition: Find exactly which partition the VMDK uses (e.g., /dev/ada0s1).
  • Check for active mounts: Run mount and gpart show. If FreeBSD has "tasted" a filesystem on that partition, it might hold an internal lock.
  • Temporary Workaround: If you don't need the other partitions on that disk while the VM is running, try unmounting all other partitions from that physical disk to see if the GEOM lock releases.
 
n 2026, the reason QEMU works where VirtualBox fails with
VERR_ACCESS_DENIED on a FreeBSD host is primarily due to differences in how they request and manage access to the physical disk.

  • VirtualBox's Strict Safety Checks: VirtualBox uses an "all-or-nothing" safety model. It attempts to open the entire physical device (e.g., /dev/ada0) to manage the raw partition. If FreeBSD's GEOM subsystem detects any active metadata or mounted slices on that same disk, VirtualBox may view the device as "locked" or "inaccessible" for writing to ensure host data safety.
  • QEMU's Direct I/O Approach: QEMU typically operates as a more flexible user-space application that can target a specific slice (e.g., /dev/ada0s1) directly. Unlike VirtualBox, it often lacks the built-in "safety" wrappers that preemptively block access when it detects other mounted partitions on the same physical drive.
  • User Isolation vs. Root Capabilities: By default, QEMU is often run with more permissive parameters or via scripts that bypass typical user-space restrictions. VirtualBox's internal COM service (VBoxSVC) enforces strict ownership checks between the user starting the VM and the actual file/device owners.
 
Yep, my main freebsd filesystem is currently mounted on the same drive and virtualbox fails big time , qemu works fine. But no acceleration. So x forwarding is unusable slow.
 
Alain De Vos said:
Yep, my main freebsd filesystem is currently mounted on the same drive and virtualbox fails big time , qemu works fine. But no acceleration. So x forwarding is unusable slow.
Click to expand...
Can you explain in mode depth this Virtualbox issue. I have Virtualbox installed and working fine. Compiled from ports.

Can you load the kernel module?

Code: 
root@Aurum ~# grep vbox /boot/loader.conf
vboxdrv_load="YES"

root@Aurum ~# kldstat|grep vbox
 2    3 0xffffffff82342000    933b8 vboxdrv.ko
26    2 0xffffffff89a5d000     4248 vboxnetflt.ko
29    1 0xffffffff89a71000     55f0 vboxnetadp.ko

In my system, it just compiles fine from the ports and runs as expected.

In /etc/group there should be vboxusers group.
 
devfs.conf

own ada0 root:operator
own ada0p2 root:operator
perm ada0 0660
perm ada0p2 0660

It's because i use a "raw" disk. Ie an existing Linux partition with Mabox-Linux.
The problem is Virtualbox wants to access the "full disk" /dev/ada but it is locked because i have a mount on another partition , on the same disk , my root partition.
 
Alain De Vos said:
devfs.conf

own ada0 root:operator
own ada0p2 root:operator
perm ada0 0660
perm ada0p2 0660

It's because i use a "raw" disk. Ie an existing Linux partition with Mabox-Linux.
The problem is Virtualbox wants to access the "full disk" /dev/ada but it is locked because i have a mount on another partition , on the same disk , my root partition.
Click to expand...
There is a reason why it want the full disk: to have access to the efi partition to boot the vm.
Nothing prevent you to search for a way to allow destructive geom command on mounted filesystem, and maybe it will work.
TLDR, it seems that it has nothing to do with any paranoia in Virtualbox, just the geom layer prevent it to do things on the entire disk when some partition in it are mounted.
There are option to geom to allow such access, you will have to search yourself about it and the risk involved, given I don't want to be accountable of your data.
 
You must log in or register to reply here.
Back
Top