One of the web projects that I am working on uses—broadly speaking—MongoDB, Django, and Python. There are other technologies involved too, but these lie at the core. The project is then deployed on Amazon EC2 instances which run on Ubuntu 12.04.

I do not work on the project by myself, but in a small team and we use VirtualBox and Vagrant to make sure that we are all developing in the same environment and that it is also identical to that of the production servers. This makes development and deployment much easier.

Until now I have been using my Macbook and all has been working great. However, since I just built my new development and gaming PC rig and it is much faster and powerful than my several years old laptop, I wanted to set up my development environment on the PC too. I installed VirtualBox and Vagrant, added Precise 64 box, and booted it up using our Vagrant config file. All went fine—until I tried to create a virtual environment for our project. When coding in Python, virtualenv is pretty nifty as it allows you to create multiple virtual environments within one system that can have different versions of Python and sets of libraries. This is particularly handy if different parts of your project require different library versions or have different dependencies.

When I tried to create the virtual environment by running virtualenv env from the command line, I got this error message:

Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 3, in 
    virtualenv.main()
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 938, in main
    never_download=options.never_download)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 1039, in create_environment
    site_packages=site_packages, clear=clear))
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 1186, in install_python
    copyfile(join(stdlib_dir, fn), join(lib_dir, fn))
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 430, in copyfile
    copyfileordir(src, dest)
  File "/usr/lib/python2.7/dist-packages/virtualenv.py", line 405, in copyfileordir
    shutil.copytree(src, dest, True)
  File "/usr/lib/python2.7/shutil.py", line 206, in copytree
    raise Error, errors

Googling lead me to this Stack Overflow question and answer. As the post suggests, this is a VirtualBox problem, not Ubuntu or virtualenv issue. One of the answers includes a link to a post by Ahti Kitsik about Fixing your virtualbox shared folder symlink error. Ahti suggests that this a symlink issue and that it can be fixed by enabling symlinks in VirtualBox. This can be done by running the following command from the command link:

VBoxManage setextradata YOURVMNAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/YOURSHAREFOLDERNAME 1

(Naturally, you would need to replace YOURVMNAME and YOURSHAREFOLDERNAME with the specific names particular to your setup.)

Unfortunately, this did not work me. Virtualenv was still throwing the same error.

At this point my memory gets a little hazy in terms of the specific steps and their sequence as there was a lot of trial and error involved, so my apologies if the following is not crystal clear.

Some more googling and checking logs on my computer revealed that my guest additions did not match my VirtualBox version. Guest additions are a collection of drivers and system applications that add better performance and usability of the virtual machine in your host system. When booting up the VM, I was getting this error:

GuestAdditions versions on your host (4.3.10) and guest (4.2.0) do not match.

The guest additions can be installed and updated using vagrant-vbguest plugin. I used the following update steps (which I found here):

1) Install the vagrant-vbguest plugin: vagrant plugin install vagrant-vbguest
2) Boot the vm without provisioning: vagrant up --no-provision
3) Login with vagrant ssh and run sudo apt-get -y -q purge virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
4) Logout and vagrant halt
5) vagrant up --provision

Doing vagrant up resulted in this error message, though:

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

Another problem to sort out. Greeeeat :/ The fix is quite simple, however:

1) Login to your VM by running vagrant ssh
2) Run sudo ln -s /opt/VBoxGuestAdditions-4.3.10/lib/VBoxGuestAdditions /usr/lib/VBoxGuestAdditions
3) exit and vagrant reload

OK, Vagrant now reloaded fine, no more mismatching guest additions error, but the problem with creating virtualenv persisted. More googling suggested that the problem was related to whether VirtualBox was run as administrator in Windows. You might notice that this is also mentioned in Ahti’s post, but his suggested fix (running secpol.msc and navigating to ‘Local Policies-User Rights Assignments’ and adding your user to ‘Create symbolic links’) did not work for me.

It set me on the right trail, though. I destroyed the VM I had had set up, closed VirtualBox, set it to ‘Run as administrator’ in Windows (right click on the executable, go to ‘Properties > Compatibility’ tab), and opened it. I then also ran my Command Prompt as administrator. This is crucial—both VirtualBox and Command Prompt from which you will be issuing commands to Vagrant—need to be run as administrator. Otherwise you will be getting another error along the lines of VBoxManage.exe: error: Code CO_E_SERVER_EXEC_FAILURE (0x80080005).

Once you have done this, you can boot up your Vagrant as always by running vagrant up. Since we have installed the new version of guest additions, you might get the mount folders error. If you do, just resolve it as described above and run vagrant reload. When the process completes, you should be able to vagrant ssh into your VM and create virtualenv as usual.

I think that running VirtualBox and Command Prompt as administrator is probably actually all that is needed and that it might resolve the virtualenv issue. But since I went through all the steps outlined above in my effort to make it work and I did not roll back all the changes, I describe the whole process in case it is not enough and some of the additional steps are required.

Enjoyed this post? Share it with others.

Email

Facebook

Google

Twitter