Recently I stumbled upon a weird issue which I had it before but neglected to fix it completely, `Vagrant Shared Folders` on CentOS.
The problem is when I upgrade my VirtualBox to 4.3.22 (on a Windows 7 host) and Vagrant to 1.7.2 my previous CentOS 6.5 shared folders started acting up.
The problem was the initial `vagrant up` was working perfectly fine, all the shared folders were mapped and working like a charm. BUT subsequent `vagrant reload`s were not the same. The machine was rebooting successfully but the shared folders were raising the following issue:
> default: Machine booted and ready! > default: Checking for guest additions in VM... > default: Mounting shared folders... default: /vagrant =&amp;amp;gt; D:/myproject Failed to mount folders in Linux guest. This is usually because the &amp;amp;quot;vboxsf&amp;amp;quot; 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
The problem was because of the version discrepancy between VirtualBox guest Additions between `Host` and `Guest`.
Initially you could just log in to the VM and manually update the VirtualBox guest additions:
$vagrant ssh -bash-4.1$ sudo /etc/init.d/vboxadd setup
but even that was not working in my case with `CentOS 6.5`. It was raising the following:
Removing existing VirtualBox non-DKMS kernel modules [ OK ] Building the VirtualBox Guest Additions kernel modules The headers for the current running kernel were not found. If the following module compilation fails then this could be the reason. The missing package can be probably installed with yum install kernel-devel-2.6.32-504.8.1.el6.x86_64 Building the main Guest Additions module [FAILED] (Look at /var/log/vboxadd-install.log to find out what went wrong) Doing non-kernel setup of the Guest Additions [ OK ]
Viewing the contents of the log files indicated the following:
$ cat /var/log/vboxadd-install.log /tmp/vbox.0/Makefile.include.header:97: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=&amp;amp;lt;directory&amp;amp;gt; and run Make again. Stop. Creating user for the Guest Additions. Creating udev rule for the Guest Additions kernel module. -bash-4.1$
Which means that the kernel headers are miss-matching. This post helped me to get it straight and by running the following command I was able to get the kernel headers right:
$ sudo yum install gcc dkms kernel-devel
Now I could run the `vboxadd` again and it works smoothly:
$ sudo /etc/init.d/vboxadd setup
Now if you log out of the VM and do a `vagrant reload` everything would work as expected.
My final step was to integrate these in to the Provisioning of the VM as it runs find the first time I’m initializing the machine.
As I’m doing a simple `shell` file to provision the machine, I just added these two lines to the end of the bash file which is used by VagrantFile:
sudo yum install gcc dkms kernel-devel sudo /etc/init.d/vboxadd setup
Hope this would save someone some time.
Adding the commands to the provisioning file is not working. When they are manually executed in the VM, they work perfectly fine, but through the provisioning it fails which I’m investigating more on that.
My friend and colleague, Marc, pointed out that, this could be achieved through the Vagrant plugin `vbox-guest`. Using vbox-guest is pretty straight forward and easy with latest versions of the OSs CoreOS, Ubuntu, CentOS7, etc. The problem I was facing was because of the CentOS 6.5 and the discrepancy between the kernel versions required by Virtualbox and the one comes by default with CentOS 6.5. That is the reason I ruled out the plugin and completely uninstalled it from Vagrant.
Alternative Solution with NFS (winnfsd)
Another option to avoid all the hassles above is to use `NFS`. NFS is not supported natively by Windows.But the excellent Vagrant winnfsd plugin makes it work through a winnfsd service running in the background.
After installing the plugin, all you need is to specify the shared folders in you `VagrantFile` and the set the type to `nfs` as follow:
config.vm.synced_folder &quot;.&quot;, &quot;/vagrant&quot;, type: "nfs"
Simplistic setup is one of the perks of `nfs`, but as it is not supported natively in the host machine, there could be some cases with some issues.
So far I only have seen a case with installation of `node-gyp` which causes an error like this:
CXX(target) Release/obj.target/ursaNative/src/asprintf.o SOLINK_MODULE(target) Release/obj.target/ursaNative.node /usr/bin/ld: Release/obj.target/ursaNative/src/ursaNative.o: bad relocation section name `' Release/obj.target/ursaNative/src/ursaNative.o: could not read symbols: File format not recognized collect2: ld returned 1 exit status make: *** [Release/obj.target/ursaNative.node] Error 1 make: Leaving directory `/vagrant/node_modules/ursa/build'
This is an issue with the underlying shared file system. So far the only way I could have work around this is something like below:
$ cd /tmp $ npm install node-gyp $ cp -r node_modules/node-gyp /vagrant/node_modules/
This is a big issue though. Because of the unpredictable errors and unhelpful messages, I decided to drop the idea of using winnfs. It adds more complexity than it brings simplicity.