You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vagrant should under windows fallback to start VBoxManage.exe as administrator and/or other user.
Actual behavior
The invocation of vagrant up with a Vagrantfile configuration line like config.vm.network :private_network, type: "dhcp" or config.vm.network :private_network, ip: "192.168.10.1" will fail as reported in #6059, #6168.
This is - at least for Windows 7 Pro with a strict user permission managment - because vagrant tries to run VBoxManage as regular user not allowed to change the network interfaces setup.
It would be better to either check if the permissions are sufficient and otherwise decline the action. Much better - in cases the rights are insufficient as well in cases where the needed interface does already exist - would be to skip the corresponding parts and nevertheless try to continue. The best option of course: vagrant should retry to start this kind of operations with the option to aquire the needed rights, i.e. the option to execute VBoxManage as other user or with elevated, administrative rights.
The very least (and not graceful because the user won't be able to bring the VM up) would be to fail with a descriptive error message and tell the user that it might be caused by insufficient execution rights.
The failing operation can be reproduced by applying the above line and staring the VM box:
C:\devel\workspace\broker>vagrant up
Bringing machine 'broker-1' up with 'virtualbox' provider...
==> broker-1: Importing base box 'centos/7'...
==> broker-1: Matching MAC address for NAT networking...
==> broker-1: Checking if box 'centos/7' version '1902.01' is up to date...
==> broker-1: Setting the name of the VM: broker-1
==> broker-1: Clearing any previously set network interfaces...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["hostonlyif", "create"]
Stderr: 0%...
Progress state: E_FAIL
VBoxManage.exe: error: Failed to create the host-only adapter
VBoxManage.exe: error: SetupDiCreateDeviceInfo failed (0x00000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInte
rface
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleCreate(struct HandlerArg *)" at line 94 of file VBoxManag
eHostonly.cpp
For details try to execute the called VirtualBox command by itself
C:\devel\workspace\broker>c:\devel\tools\VirtualBox\VBoxManage.exe hostonlyif create
0%...
Progress state: E_FAIL
VBoxManage.exe: error: Failed to create the host-only adapter
VBoxManage.exe: error: SetupDiCreateDeviceInfo failed (0x00000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component HostNetworkInterfaceWrap, interface IHostNetworkInte
rface
VBoxManage.exe: error: Context: "enum RTEXITCODE __cdecl handleCreate(struct HandlerArg *)" at line 94 of file VBoxManag
eHostonly.cpp
which is apperently the exactly same command vagrant tries to execute.
Running the very same, failed command stated in the uninformative error message by an administrative account does not throw an error
C:\tmp>c:\devel\tools\VirtualBox\VBoxManage.exe hostonlyif create
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Interface 'VirtualBox Host-Only Ethernet Adapter #2' was successfully created
Unfortunately it does not help to execute the line manually and restart vagrant up because vagrant unnecessarily dumps an existing network assignment in the VM and superfluously tries to create the network interface once again.
Hey Brian, the issue remains the same regardless of the VirtualBox version. I tested it with 5.2.28, 6.0.0, 6.0.6.
At my organisation I have local adminstartive permission for the workstation but not via the account I use to develop. This account hastn't got almost any rights especially not to create or modify a network interface.
So I guess the execution of the tool will never work if there is no user change or elevation requested.
How should the restricted development account perform a action that needs administrative rights?
I can't see a reason this might change by reinstallation/altering the installation, adding a signed driver or something like that.
Can you shed some light here?
@thungsten - unfortunately attempting to run a command as an elevated user poses some extra challenges in Windows. I'll mark this issue as an enhancement.
For now though I recommend trying to talk to your organization admin to get more permissions for doing tasks like these. Thanks!
Vagrant version
Vagrant 2.2.4
Host operating system
Windows 7 Pro
Expected behavior
Vagrant should under windows fallback to start VBoxManage.exe as administrator and/or other user.
Actual behavior
The invocation of
vagrant up
with a Vagrantfile configuration line likeconfig.vm.network :private_network, type: "dhcp"
orconfig.vm.network :private_network, ip: "192.168.10.1"
will fail as reported in #6059, #6168.This is - at least for Windows 7 Pro with a strict user permission managment - because vagrant tries to run VBoxManage as regular user not allowed to change the network interfaces setup.
It would be better to either check if the permissions are sufficient and otherwise decline the action. Much better - in cases the rights are insufficient as well in cases where the needed interface does already exist - would be to skip the corresponding parts and nevertheless try to continue. The best option of course: vagrant should retry to start this kind of operations with the option to aquire the needed rights, i.e. the option to execute VBoxManage as other user or with elevated, administrative rights.
The very least (and not graceful because the user won't be able to bring the VM up) would be to fail with a descriptive error message and tell the user that it might be caused by insufficient execution rights.
The failing operation can be reproduced by applying the above line and staring the VM box:
For details try to execute the called VirtualBox command by itself
which is apperently the exactly same command vagrant tries to execute.
Running the very same, failed command stated in the uninformative error message by an administrative account does not throw an error
Unfortunately it does not help to execute the line manually and restart
vagrant up
because vagrant unnecessarily dumps an existing network assignment in the VM and superfluously tries to create the network interface once again.References
The text was updated successfully, but these errors were encountered: