VirtualBox

Ticket #20626 (reopened defect)

Opened 7 months ago

Last modified 3 months ago

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

Reported by: hesevo Owned by:
Component: other Version: VirtualBox 6.1.28
Keywords: hostonlyif Cc:
Guest type: all Host type: Mac OS X

Description

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

Change History

comment:1 Changed 7 months ago by vStone

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

comment:2 Changed 7 months ago by 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.

comment:3 follow-up: ↓ 4 Changed 7 months ago by janitor

  • Status changed from new to closed
  • Resolution set to invalid

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.

comment:4 in reply to: ↑ 3 Changed 7 months ago by 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?

comment:5 Changed 7 months ago by coroos

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.

comment:6 Changed 6 months ago by 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".

comment:7 Changed 6 months ago by coroos

  • Status changed from closed to reopened
  • Resolution invalid deleted

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.

comment:8 Changed 6 months ago by klaus

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.

comment:9 Changed 6 months ago by 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.

Last edited 6 months ago by Nick N Ame (previous) (diff)

comment:10 Changed 6 months ago by 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.

comment:11 Changed 6 months ago by 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.

comment:12 Changed 6 months ago by 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.

comment:13 Changed 4 months ago by JeremyB

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.

comment:14 follow-up: ↓ 15 Changed 3 months ago by 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...

Last edited 3 months ago by fips (previous) (diff)

comment:15 in reply to: ↑ 14 Changed 3 months ago by 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. ;)

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use