3

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.

Any troubleshooting tip?

1 Answer 1

3

OK guys. After:

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

In short. After almost destroyed my GNU/Linux distribution, it seems I was affected by a systemd limitation.

Inspecting my default systemd Tomcat service:

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

...

I documented myself about all the involved settings and expecially NoNewPrivileges and I've found out that: 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.

So try disabling that configuration (I've commented it):

sudo systemctl edit --full tomcat9.service
...

# NoNewPrivileges=true

...

Then restart Tomcat:

sudo systemctl restart tomcat9.service

And everything will 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. Cheers!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.