Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem reloading Chef shared folders #5199

Closed
markinjapan opened this issue Jan 16, 2015 · 53 comments

Comments

Projects
None yet
@markinjapan
Copy link

commented Jan 16, 2015

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

This comment has been minimized.

Copy link

commented Jan 20, 2015

@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

This comment has been minimized.

Copy link

commented Jan 20, 2015

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

This comment has been minimized.

Copy link
Author

commented Jan 20, 2015

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

This comment has been minimized.

Copy link

commented Jan 20, 2015

@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

This comment has been minimized.

Copy link

commented Jan 26, 2015

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

@sethvargo sethvargo changed the title Problem reloading chef-zero shared folders Problem reloading Chef shared folders Jan 27, 2015

@iramello

This comment has been minimized.

Copy link

commented Jan 27, 2015

Same for me. Thanks @markinjapan.

hoatle added a commit to hoatle/teracy-dev that referenced this issue Jan 30, 2015

@mativillagra

This comment has been minimized.

Copy link

commented Feb 1, 2015

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

This comment has been minimized.

Copy link

commented Feb 3, 2015

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

@PragTob

This comment has been minimized.

Copy link

commented Feb 4, 2015

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

@tknerr

This comment has been minimized.

Copy link
Contributor

commented Feb 6, 2015

Same here with the chef_solo and chef_zero provisioner.

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

@BlakeMesdag

This comment has been minimized.

Copy link

commented Feb 6, 2015

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

This comment has been minimized.

Copy link

commented Feb 19, 2015

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

@Scythril

This comment has been minimized.

Copy link

commented Feb 24, 2015

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

@jdunmore

This comment has been minimized.

Copy link

commented Feb 26, 2015

On windows, I have no synced_folders file nor directory?

Thanks.

@spuder

This comment has been minimized.

Copy link

commented Mar 3, 2015

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

@andreychernih

This comment has been minimized.

Copy link

commented Mar 24, 2015

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

@dgollub

This comment has been minimized.

Copy link

commented Mar 25, 2015

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
@jfly

This comment has been minimized.

Copy link

commented May 13, 2015

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

This comment has been minimized.

Copy link

commented May 19, 2015

@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

This comment has been minimized.

Copy link

commented May 23, 2015

+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

This comment has been minimized.

Copy link

commented May 27, 2015

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

patcon added a commit to patcon/toronto-city-hall-api that referenced this issue Jun 3, 2015

Add workaround for synced_folder being lost.
Vagrant has a bug where it loses track of the berkshelf synced folder.

See: hashicorp/vagrant#5199 (comment)
@mikeAtTealium

This comment has been minimized.

Copy link

commented Jun 5, 2015

@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

This comment has been minimized.

Copy link

commented Jun 8, 2015

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

This comment has been minimized.

Copy link

commented Jun 11, 2015

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

This comment has been minimized.

Copy link

commented Jun 19, 2015

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

This comment has been minimized.

Copy link

commented Jul 9, 2015

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

@dkinzer

This comment has been minimized.

Copy link

commented Jul 9, 2015

@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

This comment has been minimized.

Copy link

commented Jul 9, 2015

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

This comment has been minimized.

Copy link

commented Jul 9, 2015

@lukas0krupa Ah go it! Thanks for the tip!

mitchellh added a commit that referenced this issue Jul 9, 2015

@mitchellh

This comment has been minimized.

Copy link
Member

commented Jul 9, 2015

Fixed!

@mitchellh mitchellh closed this Jul 9, 2015

@fletchowns

This comment has been minimized.

Copy link

commented Jul 9, 2015

HOORAY! Thank you @mitchellh !!

@tuupola

This comment has been minimized.

Copy link

commented Jul 10, 2015

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

This comment has been minimized.

Copy link

commented Jul 24, 2015

@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 ?

artm added a commit to gastropoda/recipes that referenced this issue Aug 14, 2015

@mihasya

This comment has been minimized.

Copy link

commented Sep 8, 2015

Running into this issue with Vagrant 1.7.4.

@mihasya

This comment has been minimized.

Copy link

commented Sep 8, 2015

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

@hashicorp hashicorp locked and limited conversation to collaborators Nov 21, 2015

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.