Skip to content

Instantly share code, notes, and snippets.

@jhenkens
Last active April 30, 2016 05:30
Show Gist options
  • Save jhenkens/9543707 to your computer and use it in GitHub Desktop.
Save jhenkens/9543707 to your computer and use it in GitHub Desktop.
Mac OS X 10.9.2, Vagrant 1.5.1, VMWare Fusion 6.0.2
I had some intense difficulties getting this all to work. The VMs would boot
fine with gui=true, but then would fail as soon as I turned that off. Yet when
they failed, they were actually running just fine! I could ssh in, but neither
vagrant nor vmrun could find the running VMs! You would think that it would
give better errors, but no.
First off, most boxes you find online will be using the VMWare configuration 9,
which will only boot if you have gui=true the first boot, so you can upgrade it
to the configuration 10. Secondly, there were a bunch of problems with the
/var/*/vmware folders which were causing issues. These all boil down to
persmissions issues.
First, Vagrant complains about permissions on the DHCP VMware files in
/var/db/vmware. At least vagrant tells us about these errors, but they seem to
pop back up every time we fix it. Oh well. do a cd /var/db/vmware, then do sudo
chown root:staff ., then do sudo chmod g+rs ., finally, for good measure, sudo
chmod g+r ./*.
Next, the VMware 'vmrun' error "Error: The operation was canceled" in my case
was becasue of permissions on a symlink in /var/run/vmware. Similar thing, just
cd into that directory, and make it owned by root:staff, and do the g+rs to
sticky the read group setting on the folder.
These are probably ugly fixes, but oh well. It fucking works and I'm happy.
Time for sleep.
3/14/2014 Detailed notes:
samwell:pre32 johanhenkens$ vagrant up
Bringing machine 'default' up with 'vmware_fusion' provider...
==> default: VMware requires root privileges to make many of the changes
==> default: necessary for Vagrant to control it. In a moment, Vagrant will ask for
==> default: your administrator password in order to install a helper that will have
==> default: permissions to make these changes. Note that Vagrant itself continues
==> default: to run without administrative privileges.
Password:
==> default: Cloning VMware VM: 'precise32'. This can take some time...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
An error occurred while executing `vmrun`, a utility for controlling
VMware machines. The command and output are below:
Command: ["start", "/Users/johanhenkens/VMWare Vagrant VMs/5229e1f5-393c-4fb4-9268-b270ba604855/vagrant-precise32.vmx", "nogui", {:notify=>[:stdout, :stderr]}]
Stdout: 2014-03-14T11:45:28.903| ServiceImpl_Opener: PID 33978
Error: The operation was canceled
Stderr:
samwell:pre32 johanhenkens$ vmrun list
Total running VMs: 0
samwell:pre32 johanhenkens$
Fixed by:
cd /var/run/vmware
sudo chown root:staff .
sudo chmod g+rs .
sudo chmod g+rx ./*
sudo chown root:staff ./*
Next error:
samwell:pre32 johanhenkens$ vagrant up
Bringing machine 'default' up with 'vmware_fusion' provider...
==> default: Verifying vmnet devices are healthy...
==> default: Preparing network adapters...
==> default: Starting the VMware VM...
==> default: Waiting for the VM to finish booting...
==> default: The machine is booted and ready!
==> default: Forwarding ports...
default: -- 22 => 2222
==> default: Configuring network adapters within the VM...
Vagrant couldn't read the VMware DHCP leases file due to permissions
issues! Please make sure that the file below has sufficient read
permissions so that the user running Vagrant can read it.
/var/db/vmware/vmnet-dhcpd-vmnet8.leases
That file is overwritten every time you bring up a VM. So, do the same thing.
cd /var/db/vmware
sudo chown root:staff .
sudo chmod g+rs .
sudo chmod g+r ./*
sudo chown root:staff ./*
@jmartelletti
Copy link

After dealing with the same frustrations for way too long, and observing different behaviour across my colleagues machines, I finally narrowed down where this issue stemmed from... obvious in retrospect.

My user default umask was set to 0077 which caused was causing vmware to create the dhcp leases file with the overly restrictive permissions.

Change this umask to something more permissive, re-login to OS X, restart vmware and now the problem is gone 😌

@tehviking
Copy link

I just wanted to say that these following these steps (and changing the umask), I was finally able to get vagrant running again with VMware. Thank you so much!

@kennonb
Copy link

kennonb commented Aug 5, 2015

What specifically did you change the umask to tehviking?

@zeevl
Copy link

zeevl commented Aug 9, 2015

umask 022 solved this for me..

@CWSpear
Copy link

CWSpear commented Aug 17, 2015

I had this issue, too. Where's the best place to update your "default umask?" I added it to /etc/profile, but that didn't seem to work (I'm using zsh). I can add it to my .zshrc, but didn't know if there was a "better" place to do this?

@ethier
Copy link

ethier commented Aug 26, 2015

This is a very frustrating issue. One additional wrinkle for me appears to be whether you're using Terminal or iTerm. Using iTerm, the leases file was always too restrictive, but the correct permissions are set in Terminal.

So, set umask (in Yosemite):

launchctl config user umask 002
launchctl config system umask 002

In earlier Mac OSX version you need to edit /etc/launchctl-user.conf and /etc/launchctl.conf for user and system umask settings respectively.

Once done, and vagrant up done in Terminal I was able to provision the machine. Switching over to iTerm after works as expected.

@rphillips
Copy link

I would like to thank everyone on this gist. I ran into the same issue, tried everything, and also figured out that iTerm2.9.20150626 [1] had an issue on setting it's own umask (077) for terminal sessions. There was a patch committed to iTerm a couple months ago. I downloaded yesterdays nightly (20150812), then rebooted and vagrant is working correctly again.

[1] gitlab/3661

[Edit] Found the patch.

@kudos
Copy link

kudos commented Aug 28, 2015

@rphillips this was it exactly for me too. Thanks for taking the time to let us know.

@ethier
Copy link

ethier commented Aug 31, 2015

@rphillips, thanks for the update. Just tried the latest nightly and everything is looking good for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment