VboxManage Error: Code E_ACCESSDENIED (0x80070005) - Access denied

[hesevo]

Hi

When I attempt to run the following command:

VBoxManage hostonlyif ipconfig vboxnet0 --ip 172.28.128.1 --netmask 255.255.255.0

I got the message:

"VBoxManage: error: Code E_ACCESSDENIED (0x80070005) - Access denied (extended info not available)"

I downgraded to 6.1.26 version and it is working fine, as it is expected.

My host operative system is MacOS Big Sur

Thanks

[Jan Vansteenkiste]

I have the same issue on Linux 5.14.14. Downgrading also solved this problem for me.

[Luossa]

I too have the same issue on Debian 11 (Bullseye) with Linux kernel 5.10.46. Luckily I found the previous version. This is a MAJOR issue that would warrant fast fix and publishing new version of VirtualBox.

[janitor]

6.1.28 imposes additional control on the addresses that can be set for host-only interfaces. The changelog could have been more explicit about it. It didn't help that an already low-key changelog entry also lost its link to the fine manual.

[ssh22]

Replying to janitor:

6.1.28 imposes additional control on the addresses that can be set for host-only interfaces. The changelog could have been more explicit about it. It didn't help that an already low-key changelog entry also lost its link to the fine manual.

So, if I got this right, on the newest 6.1.28 release, host-only networking won't work if I need to have 10.0.2.15 assigned to some VM, if host is MacOS and /etc/vbox/networks.conf doesn't exists? To been able to have this IP, I need to add the network 10.0.2.xx/8 to that file?

[Nick Hibma]

What a complete deranged change and way to implement that change. E_ACCESSDENIED is not a correct error message either. It should have been E_INVALID. A reference as to what the problem is caused by would have been nice too. I just wasted an hour on a setup I've been using for the past 5 years everyday, and which all of a sudden stopped working.

Not good.

[mucuser]

@janitor what is the purpose on imposing "additional control on the addresses that can be set for host-only interfaces"?

It is a major limitation and issue introduced with this change for many users (think about VPN software changing routes)

Please revert this change, do not close it as "invalid".

[Nick Hibma]

I expect some more sensible way to handle this. MacOS users do not edit files in /etc/ like Linux users do. This bug represents the fact that VB devs violated POLA and KISS.

[Klaus Espenlaub]

I can accept criticism that the documentation for this change is somewhat hard to find. The HTML/PDF manual has a link, but in wiki:Changelog it got lost for technical reasons. This is far from optimal.

However, I do not agree with the (rather unfriendly/hostile worded) request to undo this change. To answer the reasonable request for explaining the purpose: It moves the system wide network config powers back under the control of the administrator where it always should have been. In quite a few organization there is strict control over network resources, and in a way the VirtualBox users have become used to getting some "whole OS visible" network config power without needing administrator privileges.

The "edit a file in /etc" solution might not be elegant, but it does the job and it is actually in my opinion much more "KISS" then having some separate (because VirtualBox overall does not need admin privileges) GUI utility which allows configuring this after authenticating as administrator. Especially if all you want is giving any VirtualBox user the permission to create arbitrary host-only configs. The documentation provides examples what to do.

We're accepting sensible contributions, as always.

[Nick N Ame]

At the very least, the management UI can detect existing configurations that fall into this situation (disallowed without existence of or entries in this new, proprietary file) and flag them or prompt the user with instructions to repair, no? At install time, or inside the LaunchDaemon, one could detect problematic configurations and start up the management UI for the user.

As an aside, what may appear unfriendly/hostile to some ears sounds like a pretty earnest expression of some pretty understandable frustration to mine. A breaking change where—oversight or no—the ball was well hidden is going to make a for an unpleasant time for a lot of people. It's a pretty awful product experience that forces (a lot of) customer eyeballs off what they wanted to be looking at onto this mistake with a pretty expensive resolution overhead. I don't think its tenable to argue that isn't or shouldn't be frustrating.

Consider focusing less on the presentation and more on empathizing with the potentially thousands of people this may be tripping up right now. Think of the aggregate hours wasted. That's not pretty and—in my mind—deserves affording some space for some venting.

[Nick N Ame]

Also, why are subnets not automatically whitelisted in /etc/vbox/networks.conf when added/changed in the management UI? Neither the the management UI nor VBoxManage even hint at that requirement when creating/managing new vboxnetn interfaces. They could easily surface this. They could go further and ask for admin privileges to make the required conf file changes. Users without admin privileges would be tipped off right away they need to stay in the default swim lanes.

There is so much that could have been attempted here to salvage the product experience here with a minimal amount of empathy for end user contact with the obvious implications of this change. I think claiming this was merely about better surfacing documentation totally misses the forest for the trees. It fundamentally misunderstands customer expectations for an upgrade, especially one to a point release.

[vb4apc]

Taking offense and a frustrated user may not be the best company response. This was a breaking change for me as well and I wasted a far amount of time tracking down the fix.

Regardless of the reasoning behind it, this is a bug. The error message returned in by both the GUI and CLI does nothing to indicate what what the actual error is. Seriously, a simple "The network specified is not in the permitted range. Please see the documentation for 'Host-Only Networking' to modify this range" would have saved a fair amount of time and frustration.

[ginin]

Instead of "Access denied (extended info not available)", having something like "Requested address not whitelisted in /etc/vbox/networks.conf, please see Section 6.7 of User Manual" would have been a lot better and a very simple fix. Saw this on 6.1.30, hard to believe this has been sitting for 2 releases already.

[Jeremy Beker]

I would still argue that for OS X that using the file /etc/vbox/networks.conf is not acceptable. OS X, by default, does not allow even admins to edit files in the /etc directory. And asking people to disable SIP is irresponsible.

[fips]

Could another frustrated user ask for step-by-step (command line) instructions on how to solve the above original question? I am trying to use docker-machine on MacOS, which terminates with a similar error as the OP mentions. So far, I seem to be unable to find the critical piece of information in the user manual that would solve the matter.

Having "0.0.0.0/0 ::/0" as the only line in /etc/vbox/networks.conf did not change the behavior...

[fth0]

Replying to fips:

Having "0.0.0.0/0 ::/0" as the only line in /etc/vbox/networks.conf did not change the behavior...

Use "* 0.0.0.0/0 ::/0" as written in the VirtualBox User Manual. ;)

[Archer]

Replying to fth0:

Use "* 0.0.0.0/0 ::/0"

What...? It needs the literal asterisk at the beginning of every line? What does that even signify? The syntax of this file, simple as it is, is never described in the documentation, just a few block-formatted examples of lines to add, and I thought the author just made a mistake in their markdown. There are other bullet point lists on the same page. The first thing I did was stick a CIDR range on a line -- the way everyone and the ambiguous documentation all imply -- and then when that did nothing, I assumed I was given bad information, which it turns out I was.

This is silly. Error messages that bark an obfuscatory code at the user instead of saying what it means are silly, and wasteful of everyone's time. You have the space to insert a localized string. You've done it for other error messages, like the one where the modules aren't loaded and it tells you to load the modules. Say what you mean.

And as a Linux sysadmin, thank you, but I have plenty of other ways (control groups) to stop your process assigning an address to an interface outside of what I want to allow. Your process does not get an opinion, and placing a configuration file in /etc to imply that it does makes little sense. Leave the system settings to the system.

I should not have had to come here. Anything that breaks the user's expectations or otherwise impairs a workflow is, always, as a rule, a bug -- but that is a Linux philosophy, and there is enough to frown at on this page without bringing up Oracle's relationship to Linux philosophies.