Vagrant: shared folder not mounting

[auxbuss]

Hi,

The vm appears to mount v-root okay:

$ vagrant reload
[default] Attempting graceful shutdown of linux...
[default] Running any VM customizations...
[default] Clearing any previously set forwarded ports...
[default] Forwarding ports...
[default] -- ssh: 22 => 2222 (adapter 1)
[default] Cleaning previously set shared folders...
[default] Creating shared folders metadata...
[default] Booting VM...
[default] Waiting for VM to boot. This can take a few minutes.
[default] VM booted and ready for use!
[default] Mounting shared folders...
[default] -- v-root: /vagrant
$ 

But /vagrant is empty on the guest. The shared folder contents were available prior to upgrading the OS, which was created via:

$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
$ vagrant init lucid32
$ vagrant up

I'm new to vagrant, so not clear how to start debugging.

[auxbuss]

I managed to fix this by updating guest additions on the VM.

[ramsingla]

You can recompile the kernel modules for guest additions with

 /etc/init.d/vboxadd setup

That way, you don't need to reinstall them - just rebuild the modules after a kernel update.

[broox]

Thanks for the tip! running /etc/init.d/vboxadd setup on the virtual machine then running vagrant reload solved this problem for me

[wiseteck]

yeap.. same for me. My problem occurred because I did an yum updates which upgrade the kernel. You need to rebuild the vbox kernel modules for shared folders to work.

[ehaughee]

I had to run the preparation steps here: https://forums.virtualbox.org/viewtopic.php?t=15679 before it worked.

[ghost]

It took me a while to find this issue.

vagrant provision gets screwed up if you update the kernel on the guest machine, and forget to run /etc/init.d/vboxadd setup then vagrant reload.

E.g: Chef-solo will fail with error "Chef::Exceptions::CookbookNotFound: Cookbook * not found", since the chef.provisioning_path (/tmp/vagrant-chef-1/chef-solo-1) will be an empty directory.

[benben]

@ghost : thanks! I've found your post just before getting insane!

[uehondor]

My issue occurred after I ran the vagrant halt command because I needed to restart the host machine.

But, executing the command sudo /etc/init.d/vboxadd setup on the guest os and vagrant reload on the host solved my issue as well.

Thanks guys.

[trickeyone]

Ran into the same issue. Running the /etc/init.d/vboxadd setup then vagrant reload solved the issue for me. Would definitely adding this to the documentation for others. Took me a few Google searches to find this solution.

[robbles]

Also seeing this issue with the vanilla Precise 64-bit box (http://files.vagrantup.com/precise64.box).

Is there some workaround for this that we can put in the Vagrantfile, so that new machines aren't created in this broken state?

If not, this seems like a bug in vagrant to me...

[robbles]

To be more specific - a new VM created with a basic Vagrantfile just using the box I mentioned results in the shared folders not surviving the host going to sleep.

So every time the machine is woken up, you have to restart the VM. The solution of reinstalling the Guest Additions seems to work, but shouldn't the guest be in a full-working state after running vagrant up anyways?

[fresheneesz]

I just ran into this. Installing guest additions is a work around, not a solution. Can someone please reopen this? I agree with robbles, after vagrant up things should be working. My shared folder has been working and has suddenly stopped without any apparent reason. I had to kill and reinstall my vagrant machine from scratch.

[yoshiwaan]

Having dkms installed when the Virtualbox guest additions are installed is supposed to fix this I believe, but that would need fixing at the box level.

The vagrant-vbguest plugin helped fix this for me, it automatically recompiles guest additions if they're old.

[cortopy]

Thanks @yoshiwaan . The plugin worked smoothly and fixed this issue for me