Problem reloading Chef shared folders

[markinjapan]

After rebooting a virtual machine configured to use chef-zero, it seems the vagrant provision command no longer works, and displays the following error:

==> default: Running provisioner: chef_zero...
==> default: Detected Chef (latest) is already installed
**Shared folders that Chef requires are missing on the virtual machine.
This is usually due to configuration changing after already booting the
machine. The fix is to run a `vagrant reload` so that the proper shared
folders will be prepared and mounted on the VM.**

However, running the vagrant reload command doesn't seem to recreate all of the shared folders required for chef-zero to operate:

==> default: Attempting graceful shutdown of VM...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
**==> default: Mounting shared folders...
    default: /vagrant => /Users/$USER/Dev
    default: /tmp/vagrant-chef/91d356a57ac0d6c98d383bfab1f9fee7/nodes => /Users/$USER/chef-repo/nodes**
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: to force provisioning. Provisioners marked to run always will still run.

Naturally, the vagrant provision command still outputs the same error.

Please note, when initially running vagrant up, there were 3 shared folders created for chef (roles, nodes, and cookbooks):

==> default: Mounting shared folders...
    default: /vagrant => /Users/$USER/Dev
    default: /tmp/vagrant-chef/6616dcf9743a971e3f12afe6c9dbbdaf/roles => /Users/$USER/chef-repo/roles
    default: /tmp/vagrant-chef/91d356a57ac0d6c98d383bfab1f9fee7/nodes => /Users/$USER/chef-repo/nodes
    default: /tmp/vagrant-chef/517144fb3ab4b18253f23b7e166c95e1/cookbooks => /Users/$USER/chef-repo/cookbooks

This looks like a bug, or am I doing something wrong?

Note: I'm running Vagrant 1.7.2 on OS-X Yosemite.

[BlakeMesdag]

@sethvargo I've run into this as well, it appears the caching for synced_folders is preventing the synced_folders being populated while loading the provisioner.

The bug was introduced in 155516f.

[BlakeMesdag]

Fixed locally by changing https://github.com/mitchellh/vagrant/blob/master/plugins/provisioners/chef/provisioner/chef_solo.rb#L37 to

existing = synced_folders(@machine, cached: false)

[markinjapan]

Thanks @BlakeMesdag. After more digging, I've found that a VM already experiencing this issue can be fixed by removing the "synced_folders" file (a cache, I presume) and reloading the VM:

rm .vagrant/machines/default/virtualbox/synced_folders
vagrant reload

Not ideal, but better than destroying the VM and initialising from scratch.

[BlakeMesdag]

@markinjapan I did that as well. I think the intent behind the change that was added for caching was to prevent adding duplicate shares from multiple plugins/code paths.

The cache file doesn't get cleaned up on halt or on dirty exits though, so it causes this issue.

[erupenkman]

thanks for the workaround @markinjapan! this issue affects me too

[iramello]

Same for me. Thanks @markinjapan.

[mativillagra]

Thanks. I have found this before destroying my Ubuntu Vagrant machine. The rm on the synced_folders works form me. I just update to vagrant version to 1.7.2.

[edsinclair]

ouch. Just spent half a day tracking this down as well. Not nice. Thanks for documenting it and the current workarounds.

[PragTob]

Bug happened for me as well - quickfix froma bvoe works as well :)

[tknerr]

Same here with the chef_solo and chef_zero provisioner.

Suggested fix in #5199 (comment) helped me to work around

[BlakeMesdag]

If you don't want to manually delete the file every time, you can use the vagrant-triggers plugin to add an after hook on reload/halt (replace default with your machine name):

Vagrant.configure("2") do |config|
  config.trigger.after [:reload, :halt], stdout: true do 
    `rm .vagrant/machines/default/vmware_fusion/synced_folders`
  end
end

[pkyeck]

👍 thanks for the different workarounds. but is this going to be fixed with the next update?

[Scythril]

Hopefully it will be if #5217 gets merged in. I'm also having this issue, and that change fixed it for me.

[jdunmore]

On windows, I have no synced_folders file nor directory?

Thanks.

[spuder]

I run into this multiple times a day when using a windows vagrant box. Both vagrant 1.7.2 and 1.7.1 are affected on Mac OSX. Anxiously awaiting vagrant 1.7.3

[a-chernykh]

I am getting the same issue with chef-zero provisioner (vagrant 1.7.2) this workaround helps.

[dgollub]

I use this workaround in my Vagrantfile

config.trigger.before [:reload, :up, :provision], stdout: true do
  SYNCED_FOLDER = ".vagrant/machines/default/virtualbox/synced_folders"
  info "Trying to delete folder #{SYNCED_FOLDER}"
  # system "rm #{SYNCED_FOLDER}"
  begin
    File.delete(SYNCED_FOLDER)
  rescue Exception => ex
    warn "Could not delete folder #{SYNCED_FOLDER}."
    warn ex.message
  end
end

[ghost]

I'm also using chef-zero and experiencing this issue. vagrant 1.7.2

[ingineering]

I can confirm the problem and the workaround. Seems like a pretty major bug that needs fixing asap.

[jfly]

Thanks to everyone for the workaround, I'm happily deleting this synced_folders file using vagrant-triggers. However, anyone relying upon relative paths in their triggers should be aware of emyl/vagrant-triggers#44. If you want vagrant ... to work in subdirectories, I suggest you add the following to your triggers:

Dir.chdir '..' while !File.exist?('Vagrantfile')

[polobo]

@mikeAtTealium is the #{config_name} meant to be literal or does this workaround require that every known box in the MultiMachine configuration be explicitly specified? I put the config.trigger.before under Vagrant.configure and hard-coded my names and it works fine.

I wanted to place in under config.vm.define "name" do |nm| and then say:
.vagrant/machines/#{var_containing_name}/virtualbox/synced_folders.

Is this possible? Could "virtualbox" be pulled out in the same way?

[davidski]

+1 on picking up this issue. 5 months for the issue and for a user-submitted PR with a fix with nary a comment from a commiter. Vagrant does feel like a half-abandoned project these days. :(

[neovatar]

Confirmed. This is a very annoying major bug and should really be fixed.

[mikeAtTealium]

@polobo That variable is an artifact of the way we use some functions in our Vagrantfile so that we can source independent JSON config files for each VM and use the information from those in configuring each VM with different port forwardings, shared folders, network settings, box images and so forth. I put the trigger config in the function that gets called for each VM so that I could appropriately reference the correspondingly named subfolder for each VM that would have the /virtualbox/synced_folders entry underneath it. I think @dgollub just used "default" there as thats what the VM is called if you aren't naming them yourself.

About "virtualbox" being pulled out in the same way, sure. If you are using various Virtualization providers, say VMWare or whatever else, if you track which you are using for each VMs, you could pass that as a variable, or if you are simply using a different provider for everything, I'd just change VirtualBox to whatever you are using and it should work assuming Vagrant drops the "synced_folders" file there. I've only been using VirtualBox so I'm not certain.

[tuupola]

Same problem with plain install without Chef using vanilla shell provisioner. Initial vagrant up works ok. After that vagrant reload fails with the following.

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant

The error output from the last command was:

/sbin/mount.vboxsf: mounting failed with the error: No such device

Removing synced_folders file does not help. Only way to fix the problem is to do vagrant destroy && vagrant up.

$ vagrant version
Installed Version: 1.7.2
Latest Version: 1.7.2
$ VBoxManage --version
4.3.28r100309
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.10.3
BuildVersion:   14D136

[thecraighammond]

Same here on Window 8.1, vagrant 1.7.2.
I can get the machine to provision by halting it and removing the synced folders (which are there).

cd into the box then run 'rm .vagrant/machines/default/virtualbox/synced_folders'.
I can run --provision after that and it works fine.

I have to do this every time a provision is needed or it fails at the shared folders menu.

[dkinzer]

BTW another trick for workaround that doesn't involve installing plugins is to use an alias:

alias vagrant='rm $(find .vagrant/ -name synced_folders); vagrant'

Then just do vagrant provision as per usual.

You can add the alias to your .bashrc file.

[lukas0krupa]

@dkinzer find have -delete flag. I can't test it, because it doesn't work for me.

[dkinzer]

@lukas0krupa sorry to hear your having issues. My example above simply aliases the removal of the synced folder per the recommended workaround prior to invoking the vagrant command. It works perfectly on my Ubuntu 14.10 OS machine but I can't be certain it will work the same on other platforms.

[lukas0krupa]

No worries, I still have other things to solve, maybe I don't need it at all.

What I meant, is that you could used:
alias vagrant='find .vagrant/ -name synced_folders -delete; vagrant'

[dkinzer]

@lukas0krupa Ah go it! Thanks for the tip!

[mitchellh]

Fixed!

[fletchowns]

HOORAY! Thank you @mitchellh !!

[tuupola]

For future reference someone coming here from Google In my case the problem was caused by running yum -y update while provisioning. This can be fixed by either not running the update or running /etc/init.d/vboxadd setup after the update.

[lukas0krupa]

@mitchellh I upgraded to 1.7.4 today because of this issue, but I still have problems with it.

I am using vagrant with libvirt. I have 3 sysnced_folder and I am disabling default one. I am using 9p with mapped accessmode. I am using 'chef_zero' provision where I set synced_folder_type to '9p' as well. When I reload machine and then provision, it will blow up.

Shared folders that Chef requires are missing on the virtual machine.
This is usually due to configuration changing after already booting the
machine. The fix is to run a `vagrant reload` so that the proper shared
folders will be prepared and mounted on the VM.

Am I doning something wrong ?

[mihasya]

Running into this issue with Vagrant 1.7.4.

[mihasya]

Seemingly resolved by upgrading vagrant-berkshelf to 4.0.4 (was at 2.0.2).