Problem reloading Chef shared folders
markinjapan opened this issue · 53 comments
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.
@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.
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)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.
@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.
thanks for the workaround @markinjapan! this issue affects me too
Same for me. Thanks @markinjapan.
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.
ouch. Just spent half a day tracking this down as well. Not nice. Thanks for documenting it and the current workarounds.
Bug happened for me as well - quickfix froma bvoe works as well :)
Same here with the chef_solo and chef_zero provisioner.
Suggested fix in #5199 (comment) helped me to work around
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👍 thanks for the different workarounds. but is this going to be fixed with the next update?
Hopefully it will be if #5217 gets merged in. I'm also having this issue, and that change fixed it for me.
On windows, I have no synced_folders file nor directory?
Thanks.
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
I am getting the same issue with chef-zero provisioner (vagrant 1.7.2) this workaround helps.
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
I'm also using chef-zero and experiencing this issue. vagrant 1.7.2
I'm having the same problem and to solve this I just define the provisioning path in chef configuration
config.vm.provision :chef_solo do |chef|
chef.provisioning_path = "/tmp/vagrant-chef-3"
...
endI'm getting this error with chef_solo provisioner and Vagrant 1.7.2.
Not sure if this is the same issue, but I started to experience similar problems. My cookbooks are in the app repo, so they are available in /vagrant (/vagrant/chef/{cookbooks,site-cookbooks}). The debugging output shows a weird behavior.
DEBUG chef_zero: Not sharing /home/diegows/src/solariat/tango/chef/site-cookbooks, exists as /tmp/vagrant-chef/91f8ff2bdcb4f375f529dbdbd744bc69/cookbooks
DEBUG chef_zero: Not sharing /home/diegows/src/solariat/tango/chef/cookbooks, exists as /tmp/vagrant-chef/8145da106c8efd669c8e32f9243b148f/cookbooks
INFO interface: info: [2015-04-03T16:43:36+00:00] INFO: Started chef-zero at http://localhost:8889 with repository at /tmp/vagrant-chef/91f8ff2bdcb4f375f529dbdbd744bc69, /tmp/vagrant-chef/8145da106c8efd669c8e32f9243b148f
The tmp folders are empty, and I'm getting cookbook not found errors. I think it should be using the /vagrant/chef/{cookbooks,site-cookbooks} paths.
More info: I've changed the cookbooks_path in the Vagrantfile to:
chef.cookbooks_path = [
[ ":vm", "/vagrant/chef/site-cookbooks" ],
[ ":vm", "/vagrant/chef/cookbooks" ]
]
Chef is trying to get the cookbook from those paths:
==> default: [2015-04-03T19:11:48+00:00] INFO: Started chef-zero at http://localhost:8889 with repository at /vagrant/chef/site-cookbooks, /vagrant/chef/cookbooks
but
INFO interface: info: [2015-04-03T19:11:54+00:00] ERROR: Cookbook python not found. If you're loading python from another cookbook, make sure you configure the dependency in your metadata
and the python cookbook is there. Destroy and up works.
Using 1.7.2
Those workarounds don't always work for me. The synced_folders file won't exist, and it still throws the same error. Setting the chef.provisioning_path, or using the config.trigger.before trick isn't working either.
I ended up doing this based on some of the recommendation above to work around this. Load the triggers plugin if it isn't already loaded and then delete the synced_folder for the provider I am actually using.
# Require the Trigger plugin for Vagrant
unless Vagrant.has_plugin?('vagrant-triggers')
# Attempt to install ourself.
# Bail out on failure so we don't get stuck in an infinite loop.
system('vagrant plugin install vagrant-triggers') || exit!
# Relaunch Vagrant so the new plugin(s) are detected.
# Exit with the same status code.
exit system('vagrant', *ARGV)
end
# Workaround for https://github.com/mitchellh/vagrant/issues/5199
config.trigger.before [:reload, :up, :provision], stdout: true do
SYNCED_FOLDER = ".vagrant/machines/default/#{ENV['VAGRANT_DEFAULT_PROVIDER']}/synced_folders"
info "Trying to delete folder #{SYNCED_FOLDER}"
begin
File.delete(SYNCED_FOLDER)
rescue StandardError => e
warn "Could not delete folder #{SYNCED_FOLDER}."
warn e.inspect
end
end
How much longer do we have to work around this bug?
Send a PR :)
On Tue, Apr 28, 2015, 22:57 Greg Barker notifications@github.com wrote:
How much longer do we have to work around this bug?
—
Reply to this email directly or view it on GitHub
#5199 (comment).
@diegows read through the history, I've had a PR open since January 19 reverting the change that broke things.
Just ran into this same issue, @markinjapan thanks for workaround.
@BlakeMesdag thanks for the PR, hopefully it can be integrated in the next Vagrant release.
I just wanted to say thanks for the workarounds. @spkane you inspired me to add plugin auto installation for the triggers workaround as well as a plugin for keeping my guest extensions in sync which sometimes prevents the shared folders from working properly too. I don't run the trigger on :provision actions as this also prevented me from using the chef-solo provisioner due to it not finding the cookbooks I had shared up. I got error output about the constants, and since I use multi-machine and VirtualBox I ended up with
config.trigger.before [:reload, :up ], stdout: true do
my_SYNCED_FOLDER = ".vagrant/machines/#{config_name}/virtualbox/synced_folders"
info "Trying to delete folder #{my_SYNCED_FOLDER}"
begin
File.delete(my_SYNCED_FOLDER)
rescue StandardError => e
warn "Could not delete folder #{my_SYNCED_FOLDER}."
warn e.inspect
end
end@mikeAtTealium Glad it was useful. It was a trick I picked up from another peer awhile back.
Thank you @mikeAtTealium and @spkane, your hack works beautifully!
Another workaround:
I don't know if someone already posted this but it might be helpful,
I'm using vdd(Vagrant Drupal Development), In my case this error occurred after adding site in config.json right after changing synced_folders type to nfs,
So workaround was to provision right after changing synced_folders type, don't make any other changes before provisioning and only after provision I made changes to config.json (add sites or change whatever you want) and provision again.
This worked for me.
I can confirm the problem and the workaround. Seems like a pretty major bug that needs fixing asap.
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')@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?
+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. :(
Confirmed. This is a very annoying major bug and should really be fixed.
@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.
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
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.
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.
@dkinzer find have -delete flag. I can't test it, because it doesn't work for me.
@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.
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'
@lukas0krupa Ah go it! Thanks for the tip!
Fixed!
HOORAY! Thank you @mitchellh !!
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.
@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 ?
Running into this issue with Vagrant 1.7.4.
Seemingly resolved by upgrading vagrant-berkshelf to 4.0.4 (was at 2.0.2).