Vagrant: Vagrant VMware Workstation Plugin 5.0.0/5.0.1 does not work with user account

Created on 25 Oct 2017 · 17Comments · Source: hashicorp/vagrant

I updated the vagrant-vmware-workstation plugin from 4.0.24 to 5.0.0 and tried a first vagrant status in my normal user terminal without administrative rights.

Vagrant version

Vagrant 2.0.0

Host operating system

Windows 7 Enterprise, Windows domain joined, user account different to local admin account

Guest operating system

Windows Server 2016, but any other as well

Vagrantfile

# Copy-paste your Vagrantfile here

Debug output

Provide a link to a GitHub Gist containing the complete debug output:
https://www.vagrantup.com/docs/other/debugging.html. The debug output should
be very long. Do NOT paste the debug output in the issue, just paste the
link to the Gist.

Expected behavior

What should have happened?

It should show the status of the Vagrant VM's.

Actual behavior

What actually happened?

This is the output in my user terminal (user "stefan.scherer") during the update and the first vagrant status call:

C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows>vagrant plugin list
vagrant-reload (0.0.1)
  - Version Constraint: > 0
vagrant-share (1.1.9, system)
  - Version Constraint: > 0
vagrant-vmware-workstation (4.0.24)
  - Version Constraint: > 0

C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows>vagrant plugin update
Updating installed plugins...
Fetching: vagrant-vmware-workstation-5.0.0.gem (100%)
Building native extensions.  This could take a while...

Vagrant is installing the VMware plugin which requires
Administrator access. You may be prompted for your password to
complete setup.

Successfully uninstalled vagrant-vmware-workstation-4.0.24
Updated 'vagrant-vmware-workstation' to version '5.0.0'!

C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows>vagrant status
C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:153:in `initialize': No such file or directory @ rb_sysopen - C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.sealsystems.local-stefan.scherer/UserData/helper.args (Errno::ENOENT)
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:153:in `open'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:153:in `with_args_file'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:115:in `execute'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:103:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:39:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:77:in `installed?'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/plugin.rb:28:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant2.0.0/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:543:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:194:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `<main>'

C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows>

I opened another terminal to have a look at C:\ProgramData\HashiCorp\VagrantVMware folder:

C:\ProgramData\HashiCorp\VagrantVMware>dir
 Datenträger in Laufwerk C: ist SYSTEM
 Volumeseriennummer: 12B3-B99A

 Verzeichnis von C:\ProgramData\HashiCorp\VagrantVMware

25.10.2017  08:02    <DIR>          .
25.10.2017  08:02    <DIR>          ..
25.10.2017  08:02    <DIR>          ROENB014-localadmin
               0 Datei(en),              0 Bytes
               3 Verzeichnis(se), 386.636.275.712 Bytes frei

C:\ProgramData\HashiCorp\VagrantVMware>dir ROENB014-localadmin
 Datenträger in Laufwerk C: ist SYSTEM
 Volumeseriennummer: 12B3-B99A

 Verzeichnis von C:\ProgramData\HashiCorp\VagrantVMware\ROENB014-localadmin

25.10.2017  08:02    <DIR>          .
25.10.2017  08:02    <DIR>          ..
25.10.2017  08:02    <DIR>          bin
25.10.2017  08:02    <DIR>          UserData
               0 Datei(en),              0 Bytes
               4 Verzeichnis(se), 386.636.275.712 Bytes frei

C:\ProgramData\HashiCorp\VagrantVMware>dir ROENB014-localadmin\bin
 Datenträger in Laufwerk C: ist SYSTEM
 Volumeseriennummer: 12B3-B99A

 Verzeichnis von C:\ProgramData\HashiCorp\VagrantVMware\ROENB014-localadmin\bin

25.10.2017  08:02    <DIR>          .
25.10.2017  08:02    <DIR>          ..
25.10.2017  08:02                57 installed_by
25.10.2017  08:00         5.294.592 vagrant_vmware_desktop_sudo_helper_windows_amd64.exe
               2 Datei(en),      5.294.649 Bytes
               2 Verzeichnis(se), 386.636.730.368 Bytes frei

C:\ProgramData\HashiCorp\VagrantVMware>dir ROENB014-localadmin\UserData
 Datenträger in Laufwerk C: ist SYSTEM
 Volumeseriennummer: 12B3-B99A

 Verzeichnis von C:\ProgramData\HashiCorp\VagrantVMware\ROENB014-localadmin\UserData

25.10.2017  08:02    <DIR>          .
25.10.2017  08:02    <DIR>          ..
               0 Datei(en),              0 Bytes
               2 Verzeichnis(se), 386.636.730.368 Bytes frei

C:\ProgramData\HashiCorp\VagrantVMware>

So the problem seems to be that Vagrant looks for a folder

"C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.sealsystems.local-stefan.scherer"

but only a folder

"C:\ProgramData\HashiCorp\VagrantVMware\ROENB014-localadmin"

exists.
My user account "stefan.scherer" is a domain user, the admin account "localadmin" is a local admin account. This is a corporate notebook so I can't have the same username for non-admin tasks.

Steps to reproduce

Use an administrator account "foo"
Use an user account "bar"
Run "vagrant plugin update" as normal user "bar", enter admin user "foo" in the UAC dialogs
Run "vagrant status" in an Vagrant environment folder with a Vagrantfile

References

Release notes 4.0.25: https://github.com/hashicorp/vagrant-plugin-changelog/blob/master/vagrant-vmware-changelog.md#4025

bug providevmware

Source

StefanScherer

All 17 comments

I now tried to use the new plugin 5.0.0 in my localadmin terminal which I worked with the older plugin 4.0.24.
But I also get the error

C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows>vagrant status
C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-workstation/sudo_helper.rb:153:in `initialize': No such file or directory @ rb_sysopen - C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.sealsystems.local-localadmin/UserData/helper.args (Errno::ENOENT)
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:153:in `open'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:153:in `with_args_file'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:115:in `execute'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:103:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:39:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/sudo_helper.rb:77:in `installed?'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.0/lib/vagrant-vmware-work
station/plugin.rb:28:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:543:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:194:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `<main>'

So it seems that the installer used the hostname and using the plugin uses the FQDN as it now looks for the folder "C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.sealsystems.local-localadmin".

PS: I also have a multi VM Vagrant environment to spin up a Windows domain https://github.com/StefanScherer/adfs2 with two test domain users in it if this could be helpful to investigate the problem.

StefanScherer on 25 Oct 2017

I tried to create the missing folder ( C:\ProgramData\HashiCorp\VagrantVMware\ROENB014.sealsystems.local-stefan.scherer\UserData ) manually which worked, but then a vagrant status just hangs.
I have created a gist https://gist.github.com/StefanScherer/e1649d4bde2f3010ea567cdca01970e1 with the vagrant debug output.

StefanScherer on 25 Oct 2017

@StefanScherer Thanks for the report! I'm having a look at this today and will get a fix out shortly.

chrisroberts on 25 Oct 2017

👍1

@StefanScherer A new version of the plugin was released today (5.0.1) which includes Windows installation fixes. Please let me know if you still encounter problems after updating. Thanks!

chrisroberts on 28 Oct 2017

Thanks @chrisroberts. So I now dare to update my working setup (Vmware Workstation 12.5.x, downgraded to vagrant-vmware-workstation 4.0.24) to the latest version. Wish me good luck :-)

I now have updated my Windows 7 Enterprise machine to VMware Workstation 14.0.0 and updated to vagrant-vmware-workstation 5.0.1

In a user terminal a vagrant up just hangs. Then with $env:VAGRANT_LOG="debug" another vagrant up showed "DEBUG sudo_helper: Started VMware helper task. Waiting for result."
Hm, so I aborted the vagrant command, opened up the task scheduler and removed the task.
Another vagrant up then complained about something missing. Oh, I messed things up. But with a vagrant plugin update the scheduled task will be installed again.

But I still have no success running vagrant up, it just hangs.

 INFO runner: Running action: environment_load #<Vagrant::Action::Builder:0x000000040e26b8>
 INFO warden: Calling IN action: #<HashiCorp::VagrantVMwareworkstation::SetupPlugin:0x00000004098d38>
 INFO sudo_helper: Sudo helper bin path: C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/bin/vagrant_vmware_desktop_sudo_helper_windows_amd64.exe
DEBUG sudo_helper: Writing to arguments file: {:Ident=>"1bee41fe-854f-4f37-8b8b-3ba3f4f7e3fb", :Args=>["validate"]}
 INFO subprocess: Starting process: ["C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/bin/vagrant_vmware_desktop_sudo_helper_windows_amd64.exe", "task"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: ERFOLGREICH: Es wurde versucht, die geplante Aufgabe "vagrant-vmware-desktop-SEALSYSTEMS-stefan.scherer" auszuführen.
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
DEBUG sudo_helper: Started VMware helper task. Waiting for result.

I now have the situation that my work PC is now in an unusable state for Vagrant. 🤕 Any recommendations? 😄

With Process Monitor (procmon.exe from Sysinternals) I have captured the vagrant up and can see the following process tree. The sudo helper starts the task and the exe will be started
bildschirmfoto 2017-10-28 um 20 51 54

bildschirmfoto 2017-10-28 um 20 52 18

bildschirmfoto 2017-10-28 um 20 59 38

The sudo helper running in system account exits with exit code 1.

Is the Process Monitor PML file useful for you?
Or is there any other log file of the sudo helper running as SYSTEM?
Another detail, I'm running Windows 7 Enterprise with German UI, so the one line "stdout: ERFOLGREICH: Es wurde versucht, die geplante Aufgabe "vagrant-vmware-desktop-SEALSYSTEMS-stefan.scherer" auszuführen." shows a German text. Don't know if the program fetches the stdout in some way.

Then I tried to run vagrant up in my admin terminal again, but this leeds to this error message:

PS C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows> vagrant up output1
C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-workstation/sudo_
helper.rb:156:in `initialize': No such file or directory @ rb_sysopen - C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.
sealsystems.local-localadmin/UserData/helper.args (Errno::ENOENT)
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:156:in `open'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:156:in `with_args_file'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:115:in `execute'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:103:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:39:in `call'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/sudo_helper.rb:77:in `installed?'
        from C:/Users/stefan.scherer/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.1/lib/vagrant-vmware-work
station/plugin.rb:28:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:543:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:194:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `<main>'
PS C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows> $env:USERNAME
localadmin

I then created the directory manually and did another vagrant up, but this now also hangs in localadmin account:

PS C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows> mkdir C:\ProgramData/HashiCorp/VagrantVMware/ROENB014.seal
systems.local-localadmin/UserData


    Verzeichnis: C:\ProgramData\HashiCorp\VagrantVMware\ROENB014.sealsystems.local-localadmin


Mode                LastWriteTime     Length Name
----                -------------     ------ ----
d----        28.10.2017     21:37            UserData


PS C:\Users\stefan.scherer\GitHub\plossys\vagrant\am-windows> vagrant up output1

BTW: We have ordered 18 licences and I don't know if other colleages have updated independently. I'll check next week that they should wait a little longer until we have a solution for that.

StefanScherer on 28 Oct 2017

You found a workaround, got the same problem?

daBONDi on 30 Oct 2017

@daBONDi No, I just wait patiently. Have informed my colleages, only one has already upgraded to Workstation 14 and temporarily uses different Vagrant provider right now.

StefanScherer on 30 Oct 2017

Looks like Vagrant Communicates over Textfiles with the Task Schedule Binary "...Sudo helper....."
What i see was Vagrant Set the helper.args file where the sudo helper process the Files to the wrong folder:

for me it is

The Task Scheduler Binary was located on HasiCorp\VagrantVMWare\- but
vagrant Process writes his helper.args File (Where the Command Request gets written in) on Folder HashiCorp\VagrantVMware\-, when i changed the Task Squence Binary Source to the Binary in HashiCorp\VagrantVMWare\-, then both can communicate with each other but i fail now on with vmrun errors.

Waiting now for nearly 1 Month to get Vagrant working with Workstation 14 :-) and the E-Mail Support address never got anything in return, not even a ticket number or something

From an software architect view, its realy a fucked up system to communicate like this on windows, Interprocess communication is needed, and a windows service, not a dumb exe that get called by an task scheduler

daBONDi on 30 Oct 2017

My workaround to be operable again is downgrading:

# remove VMware Workstation 14.0.0, but keep license and config settings
choco install -y vmwareworkstation -version 12.5.7
vagrant plugin install vagrant-vmware-workstation --plugin-version 4.0.23

I'm going to the VMware 30 days trial, don't know if entering my old license would be a conflict.
Hope this gets fixed until trial ends ;-)

StefanScherer on 1 Nov 2017

👍1

My thoughts about this is, we only need UAC when changing network things. Once the network things are already created, no UAC or sudo helper is needed for the next vagrant up|halt|status and so on. Packer builds work fine as normal user.

So maybe something like https://github.com/winteryoung/uac before the commands needed to run with UAC could do the job?

StefanScherer on 1 Nov 2017

@StefanScherer @daBONDi Hi there. Sorry about the delay. Needed to get a domain setup to reproduce the installation behavior that you were experiencing. We got one setup yesterday, reproduced the issue you were encountering, and released a fix this morning (v5.0.2). The user string generation was being composed differently at install time compared to runtime which was the underlying cause of the issue (which @daBONDi alluded to in an earlier comment, thanks for the pointer to the culprit).

If you still see issues after updating to 5.0.2, please let me know. Cheers!

chrisroberts on 2 Nov 2017

@chrisroberts Thanks for the update! An no worries, I know that testing in a domain setup isn't that trivial ;-)
Yes, I can confirm that vagrant-vmware-workstation plugin 5.0.2 works for me. Wow, what a new feeling to work in my current user's terminal without having a second admin terminal open!

One minor thing, I see this message on every "vagrant up":

==> output1: This machine used to live in C:/Users/stefan.scherer/github/plossys/vagrant/am-windows but it's now at C:/Users/stefan.scherer/GitHub/plossys/vagrant/am-windows.

This message could be suppressed on Windows as Windows paths are case-insensitive.

StefanScherer on 3 Nov 2017

👍1

@StefanScherer Thanks for the confirmation and again, sorry for the initial installation problems. We are getting a more diverse set of Windows environments setup for development and testing which will help reduce these rough spots in the future.

I've created a task to address the moved machine warning and will get it resolved in the next release.

Cheers!

chrisroberts on 3 Nov 2017

@chrisroberts I am getting this as well. It started off with vagrant being slow... then slower... then vagrant up/halt/reload commands would hang.

The final line before hanging (with --debug) is
DEBUG sudo_helper: Started VMware helper task. Waiting for result.

VMWare 14.0.0 build-6661328
vagrant 2.0.1
vagrant-vmware-workstation 5.0.3

bcorcoran on 9 Nov 2017

Apologies... seems to be fixed after another vagrant plugin expunge --reinstall

Will pipe up if it happens again

bcorcoran on 9 Nov 2017

Unfortunately, we seem to be experiencing a very similar issue, with the following environment:

Windows 7 
VMWare Workstation 10.0.2
vmware-workstation-plugin 5.0.3

Initially, after installing the plugin via vagrant, our vmware-workstation-plugin gem was installed in the wrong folder (C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/gems/vagrant-vmware-workstation-5.0.3 instead of C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3), so vagrant was bombing out on that. We moved the gems up into the correct folder, then started getting the following error:

$ vagrant box add some/box-name some-box-file.box
C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:177:in `initialize': No such file or directory @ rb_sysopen - C:\ProgramData/HashiCorp/VagrantVMware/MY_DOMAIN-my_user/UserData/helper.args (Errno::ENOENT)
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:177:in `open'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:177:in `with_args_file'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:129:in `execute'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:117:in `call'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:39:in `call'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/sudo_helper.rb:77:in `installed?'
        from C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/lib/vagrant-vmware-workstation/plugin.rb:28:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/warden.rb:34:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/builder.rb:116:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `block in run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/util/busy.rb:19:in `busy'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/action/runner.rb:66:in `run'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:543:in `hook'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/lib/vagrant/environment.rb:194:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-2.0.0/bin/vagrant:118:in `<main>'

We fixed that with (via Git Bash):

mkdir -p /c/ProgramData/HashiCorp/VagrantVMware/MY_DOMAIN-my_user/UserData/
touch /c/ProgramData/HashiCorp/VagrantVMware/MY_DOMAIN-my_user/UserData/helper.args

So now we are able to run Vagrant, but we're seeing a similar hang to what @StefanScherer reported a couple weeks back:

...
 INFO runner: Preparing hooks for middleware sequence...
 INFO runner: 2 hooks defined.
 INFO runner: Running action: environment_load #<Vagrant::Action::Builder:0x00000002ab12e0>
 INFO warden: Calling IN action: #<HashiCorp::VagrantVMwareworkstation::SetupPlugin:0x00000002a30708>
 INFO sudo_helper: Sudo helper bin path: C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/bin/vagrant_vmware_desktop_sudo_helper_windows_amd64.exe
DEBUG sudo_helper: Writing to arguments file: {:Ident=>"082d98ef-5d62-49b8-a366-ae0031ba75df", :Args=>["validate"]}
 INFO subprocess: Starting process: ["C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/bin/vagrant_vmware_desktop_sudo_helper_windows_amd64.exe", "username"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: MY_DOMAIN-my_user
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 32000
DEBUG subprocess: Exit status: 0
 INFO subprocess: Starting process: ["C:/Users/my_user/.vagrant.d/gems/2.3.4/gems/vagrant-vmware-workstation-5.0.3/bin/vagrant_vmware_desktop_sudo_helper_windows_amd64.exe", "task"]
DEBUG subprocess: Selecting on IO
DEBUG subprocess: stdout: SUCCESS: Attempted to run the scheduled task "vagrant-vmware-desktop-MY_DOMAIN-my_user".
DEBUG subprocess: Waiting for process to exit. Remaining to timeout: 31999
DEBUG subprocess: Exit status: 0
DEBUG sudo_helper: Started VMware helper task. Waiting for result.

Earlier we also tried reinstalling the plugin, as @bcorcoran suggested:

vagrant plugin expunge --reinstall

Although that bumped us from vmware-workstation-plugin version 5.0.1 to 5.0.3, it doesn't seem to have resolved the issue, unfortunately. I wonder if our problem could be related to the use of an older version of VMWare Workstation. Any ideas or guidance you can provide would be appreciated!

gblair on 13 Nov 2017

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.