This content has been written a long time ago. As such, it might not reflect my current thoughts anymore. I keep this page online because it might still contain valid information.

Installing Vagrant In A Restricted Environment

Lately, I worked on installing Vagrant in a restricted environment. By “restricted environment”, I mean an infrastructure with restricted permissions for our users, disk quotas, NFS volumes, and a stable operating system: Debian Squeeze32. This work has been done in collaboration with the sysadmin of my University.


Vagrant needs VirtualBox 4.0 or upper, but the latest VirtualBox version available for Debian stable is 3.2.10 OSE. Fortunatelly, Debian Backports provide VirtualBox 4.0.x:

# /etc/apt/sources.list
deb squeeze-backports main

Installing VirtualBox becomes easy:

apt-get -t squeeze-backports install virtualbox virtualbox-dkms

The virtualbox-dkms package is required to compile the module. If you want a graphical user interface, install virtualbox-qt.

Also,if you use a virtualization solution (KVM for instance), you should unload its module (rmmod is your friend).

Now, let’s install Vagrant. Last stable version is 1.0.5, and you can find packages at:

dpkg -i vagrant_1.0.5_i686.deb

Customizing the default directories

As I said in introduction, users have disk quotas (500Mo) so they can’t use Vagrant for two reasons:

  • VirtualBox stores its VMs in ~/VirtualBox VMs/;
  • Vagrant stores its boxes in ~/.vagrant.d/.

The solution is to change these two directories. Thanksfully, Vagrant provides a VAGRANT_HOME environmental variable so you can easily change the Vagrant directory:

export VAGRANT_HOME=/path/to/vagrant

In our case, we used /usr/local/vagrant as main Vagrant directory, and we set it for all users. That allowed us to import a set of boxes for our users.

Let’s do the same thing for VirtualBox! Err… no. There is no environmental variable defined for VirtualBox, but we can still configure VirtualBox using vboxmanage:

vboxmanage setproperty machinefolder /path/to/virtualbox

VBoxManage setproperty is useful to change global settings. The command above changes the default machine folder (~/VirtualBox VMs by default).

We made a tiny shell script named vagrant and located in the PATH of our users to run this command and to forward the eventual arguments to Vagrant. The reason is quite simple, there is no way to run VBoxManage using Vagrant before everything else. I opened an issue for that (#1247).

To avoid conflicts, you can use $USER to define one machine folder per user:

vboxmanage setproperty machinefolder "/usr/local/virtualbox/$USER"

So far so good, our users can run Vagrant to install VMs.

The initramfs prompt (of death)

We tried the lucid32 Vagrant box, which is an official box, but it didn’t work. This was an issue related to the box itself. VirtualBox couldn’t boot it, an initramfs prompt was displayed. Most of the time, this appears because no disk can be found.

That’s why we tried to change the disk controller, we removed the SATA controller and attached the disk to the IDE controller. With this configuration, we were able to boot the image, and to log in. This was been reported as well.

So the fix was to switch from a SATA controller to an IDE controller. It can be done using VBoxManage:

vboxmanage storagectl <UUID> --name "SATA Controller" --remove
vboxmanage storageattach <UUID> --storagectl "IDE Controller" --port 0 --device 0 --type hdd --medium /path/to/box-disk1.vmdk

Vagrant provides a way to customize a VM thanks to the config.vm.customize parameter:

config.vm.customize ["modifyvm", :id, "--memory", 1024]

However, we decided to patch the boxes instead of using this parameter. One reason was that we didn’t know how to get the path to the vmdk file.

We were able to boot a lucid32 VM, but a new issue appeared: NFS. In order to share the current working directory with the VM, we used this configuration in the Vagrantfile:

config.vm.share_folder("v-root", "/vagrant", ".", :nfs => true)

It worked fine without NFS set to true but it was quite slow. Thus, NFS was a requirement.

The Surprise

I dug into the code to understand how NFS was managed, and why it asked for admin credentials. I was really suprised while reading the code. There is no way to configure Vagrant to control the NFS part, and sadly it asks for the root password.

There is no way to give the root password to our users (mainly students). We ended up patching Vagrant to use exportfs and a shell script to perform sed. nfsd is always up so there is no need to restart it, and exportfs does a good job. As /etc is not writable for everyone, we used a shell script to change the content of /etc/exports using a simple sed -i -e. And now, both commands are sudoable.

And, that’s it! Our users can use Vagrant as usual.

Useful Tips

Debugging Vagrant can be really useful, especially when you start playing with VM customization. To enable logging, use the VAGRANT_LOG environmental variable:


Hardware virtualization should be enabled if you want to run 64bits VMs on a 32bits host. The VirtualBox documentation isn’t clear about that in the chapter about hardware vs software virtualization.


Vagrant needs some improvements to be more configurable, and a bit safer in my opinion. However, it is flexible enough, we can do pretty much whatever we want with it, and it just works!

Feel free to fork and edit this post if you found a typo, thank you so much! This post is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.


Sorry, I removed all comments on December 19, 2019. You can tweet me or send me an email if you like.