Failed to start VirtualBox on Linux host complaining about /usr/lib/virtualbox/VBoxRT.so

[Steve Sun]

Host: CentOS 7 64bit, kernel version 3.10.0-514.16.1.el7.x86_64

VirtualBox gives this error message and exit with code 1:

VirtualBox: Error -610 in supR3HardenedMainInitRuntime!
VirtualBox: dlopen("/usr/lib/virtualbox/VBoxRT.so",) failed: <NULL>

VirtualBox: Tip! It may help to reinstall VirtualBox.

Happens with version 5.1.20_114628 and 5.1.22_115126. No such problem with 5.1.18 or 5.1.16.

I use rpm -ivh xxx.rpm to install, and rpm -e xxx to remove it. All testing rpm packages are downloaded from official website.

[Steve Sun]

I found the problem. I accidentally changed the owner of /usr to non-root user and group. For earlier versions, this is not a fatal error, but since 5.1.20 it is fatal.

In fact, I found out the reason when I install the extension pack, which complained about /usr ownership and stopped. The tip given by VirtualBox is not that helpful.

[Frank Mehnert]

With 5.1.16 or 5.1.18 you would not have been able to start any VM if /usr has the wrong permission. There are additional checks with 5.1.20 / 5.1.22 but I agree that the error message should be improved.

[Anton]

I'm try to install VirtualBox on Debian Stretch and got this error. Workaround sudo chown root:root /usr sudo chown root:root /usr/lib

[Frank Mehnert]

Replying to qwazer:

I'm try to install VirtualBox on Debian Stretch and got this error. Workaround sudo chown root:root /usr sudo chown root:root /usr/lib

Sorry, but this is not a workaround but this is the actual fix. If either of these directories are owned by someone else than root that user would be able to change the content of system files.

I agree that VirtualBox should warn in more human-readable form but the check as such is correct.

[naisanza]

Fixing the directory ownership solved my problem.

For the directory to have changed in the first place would have required root privileges. If the change of ownership is of concern, and the change is unknown, then the system should be seen as untrusted and should be handles as so.