Tomcat unable to execute VBoxManage: NS_ERROR_FAILURE (0x80004005)

Question

Today I've seen an issue similar to this one: VBoxManage: won't start virtuals machines NS_ERROR_FAILURE (0x80004005) but in a completely different inexplicable context I can describe here.

In a distribution based on Ubuntu 20.04, I was able to issue this command from a normal user:

$ whoami
my-user-name
$ VBoxManage startvm --type headless my.app-name

But I was not able to execute the same command from Java, specifically from Tomcat9, from the same user:

ProcessBuilder pb = new ProcessBuilder("bash", "-c", "whoami"); // my-user-name
Process p = pb.start();

ProcessBuilder pb = new ProcessBuilder("bash", "-c", "VBoxManage ...");
Process p = pb.start();

In this last case I was obtaining this error:

VBoxManage: error: Details: code NS_ERROR_FAILURE (0x80004005), component MachineWrap, interface IMachine

Note that I was also able to issue that command successfully from an emergency tty console, or from any other non-interactive shells, but not from Java executed by the Tomcat process.

Everyone on the Internet just suggests to reinstall VirtualBox but this is a completely irrelevant solution for this case (also because I tried multiple times reinstalling Tomcat or VirtualHost without changing anything). Also they suggest to adopt --type headless but I already did.

I also tried these, without success:

• re-installing Tomcat
• re-installing VirtualBox (twice)
• updating the kernel to weird unstable versions
• flashing a newer BIOS

Any troubleshooting tip?

Answer 1

I had the same problems. I was affected by a systemd limitation.

Inspect your systemd Tomcat service (with your exact version):

sudo systemctl cat tomcat9.service

#
# Systemd unit file for Apache Tomcat
#


...

# Security
User=my-user-name
Group=my-user-name
PrivateTmp=yes
AmbientCapabilities=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

...

You may have the above settings, expecially NoNewPrivileges. This is problematic for some use cases, since: 1

If true, ensures that the service process and all its children can never gain new privileges through execve() (e.g. via setuid or setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that a process and its children can never elevate privileges again.

If this is your problem, disable that configuration (I've commented it):

sudo systemctl edit --full tomcat9.service

...

# NoNewPrivileges=true

...

Then restart Tomcat:

sudo systemctl restart tomcat9.service

And everything should be OK again.

---

I hope this would help other people in avoiding hours of troubleshooting because of this specific limitation in your default systemd service unit adopted by distributions. Add a comment if you have more notes.