Virtualenv not creating an environment

Question

I installed Virtualenv on Ubuntu 12.04 and was using it to work on a sample project under the unity desktop. I'm using VirtualBox and was having some issues with the unity desktop so changed to the KDE desktop.

I'm now trying to create a new project but the virtualenv won't allow me to create a new environment in my project folder. In the terminal I navigate to the project folder, type virtualenv venv and get the following error messages:

Traceback (most recent call last):
  File "/usr/bin/virtualenv", line 3, in <module>
    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 1215, in install_python
    copyfile(stdinc_dir, inc_dir)
  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
shutil.Error: [('/usr/include/python2.7/numpy', 'venv/include/python2.7/numpy', '[Errno 30] Read-only file system')]

Can anyone help me resolve this? I've tried reinstalling virtualenv but no joy. Thanks

Extravagant

It's complaining that you're trying to create a virtualenv on a read-only filesystem. What directory are you trying to make it in? Can you touch a file there? – Superjacent

@Dougal It's a vbox shared folder. The project with the working env is also in this folder however. edit: Yes I can touch a file in the same folder. Created a new file no issues – Extravagant

Okay: can you mkdir -p venv/include/python2.7/numpy; touch venv/include/python2.7/numpy/test? Maybe venv or a subdir is a link to a read-only filesystem? – Superjacent

@Dougal Completed with no issues – Extravagant

Answer 1

Ok after a bit more in-depth googling found that this is a VirtualBox issue, not a Ubuntu problem. The shared folders are protected from this activity. I don't know how/why it worked the first time round but it is a known bug. I created a project outside of the shared folder with no problems. Thanks for the input Dougal.

Extravagant

You can disable the protection and it was not disabled in older VirtualBox versions. See my answer – Unquestioned

Answer 2

Virtualenv is using symbolic links (shutil.copytree uses them, see traceback). Creating symbolic links in a VirtualBox shared folder is disabled. Simple test in terminal (inside the guest machine):

$ ln -s testfile

Either you'll get a failed to create symbolic link './testfile': Read-only file system or Protocol error.

You can enable symbolic links in shared folders by executing in terminal on the host (solution from schisamo):

$ vboxmanage setextradata VM_NAME "VBoxInternal2/SharedFoldersEnableSymlinksCreate/NAME_OF_YOUR_SHARED_FOLDER" 1

Replace VM_NAME with the name of the virtual machine, as seen in the VirtualBox Manager:

and NAME_OF_YOUR_SHARED_FOLDER with the name of the shared folder which you can see in the settings of the virtual machine:

After the setting, restart the VirtualBox.

You can check the settings (on the host) with

$ vboxmanage getextradata VM_NAME enumerate

Fix for Windows (Ahti Kitsik) (thanks to Bryan's answer).

---

VirtualBox implemented symbolic links for shared folders since version 4.0 (for Linux and Solaris) but are disabled since version 4.1.8 for security reasons. That may be the reason why it first worked for you and later not.

Documentation:

VirtualBox shared folders also support symbolic links, also called symlinks, under the following conditions:

• The host operating system must support symlinks. For example, a Mac OS X, Linux, or Oracle Solaris host is required.
• Currently only Linux and Oracle Solaris Guest Additions support symlinks.
• For security reasons the guest OS is not allowed to create symlinks by default. If you trust the guest OS to not abuse the functionality, you can enable creation of symlinks for a shared folder as follows [see above]

Unquestioned

@Meglio It's the name of your shared folder as in the VirtualBox settings. Changed it to NAME_OF_YOUR_SHARED_FOLDER in my answer. – Unquestioned

Still not clear - which settings, e.g. if I'm using Vagrant? Is it the name as seen by the guest os or by the host os? Is it just name or full path? Please could you explain. – Peake

@Peake I change my answer to explain your question in more detail. Hope you can use it now. For the Vagrant settings, see Bryan 's answer. – Unquestioned

just two (obvious) clarifications: - execute vboxmanage on the host not the guest - use quotes for "SHARE_NAME" if the folder name contains spaces – Warrantable

@Warrantable Thanks. I've added them. – Unquestioned

Answer 3

Ahti Kitsik posted a workaround on his blog: https://ahtik.com/fixing-your-virtualbox-shared-folder-symlink-error/

VBoxManage setextradata YOURVMNAME VBoxInternal2/SharedFoldersEnableSymlinksCreate/YOURSHAREFOLDERNAME 1

YOURSHAREFOLDERNAME is the name of the shared folder according to VirtualBox.

If you happen to be using Vagrant, here's the fix for your Vagrantfile:

config.vm.provider :virtualbox do |vb|
  vb.customize ["setextradata", :id, "VBoxInternal2/SharedFoldersEnableSymlinksCreate//vagrant","1"]
end

Middleoftheroader

"If you happen to be using Vagrant". The default shared folder is (or used to be) /vagrant, so this example shows how to make use of that. – Middleoftheroader

It would be great if you clarified if it needs to be the folder on the guest or host machine. Going to give it a shot though, fingers crossed – Peraea

It's been a long time since I dealt with this, but the shared folder of VirtualBox here refers to the symlink created inside the virtual machine. This is hinted at by the super long string, but I recall using /vagrant inside the VM but never had /vagrant on the host. – Middleoftheroader

According to @Dominik's answer it should be NAME_OF_YOUR_SHARED_FOLDER, which going from his screenshot and me matching this to my Vagrant VirtualBox the name is vagrant and not /vagrant. i.e. it's asking for the name and not the path. – Exemplification

@Peraea /vagrant is on the Guest (VM machine), unless there is a custom shared directory set in the VagrantFile on the host machine. – Exemplification

N.B. According to this Server Fault comment, Vagrant does this by default now, so you shouldn't need to set it any more – Exemplification

Answer 4

I've encountered this exact same error with virtualenv and VirtualBox (managed through Vagrant) with a Ubuntu guest.

Remembering a previous incident where file permissions caused me problems I tried turning on nfs sharing in my Vagrantfile:

config.vm.share_folder("v-root", "/home/vagrant/apps", "/home/gareth/Projects/project-name/", :nfs => true)

This solved the problem for me. The process for getting nfs sharing on VirtualBox is a little more involved though:

https://www.virtualbox.org/wiki/Sharing_files_on_OSE

Glyconeogenesis

Answer 5

I see this solution on github.com :

upgrade virtualenv to the latest version(1.11.6), and use it as

virtualenv --always-copy testenv

the options will not use hard link but copy the files

Soapsuds

Answer 6

In addition to the already mentioned requirement to allow symlinks via VBoxManage setextradata i found that another requirement seems to be that the (absolute) path to the venv-folder has to be the same as on the host if you want to use the venv both on the host and in the VM. So keep that in mind when setting the mountpoint for the shared folder.

That seems to be more of a limitation of venv due to the path being set in pyvenv.cfg and not an issue of VirtualBox though. But as i scratched my head over this for two days now, it might be good to know for others, too ;)

Rosetterosewall