Vagrant on Windows

• Thu, Sep 5, 2013
• 3-minute read

Recently, we started using Vagrant boxes for our local development. As a base we took the Vagrant config that I’ve built during the last weeks - which worked perfectly, performant and satisfying on Mac.

NFS vs. Windows

But then our first developers started complaining that the box doesn’t work on Windows at all. Basically this was due to the fact that Windows as a Host system does not support NFS - but NFS is the default behaviour of my Vagrant box to mount some shared folders into /var/www/. OK, this problem can be fixed pretty easily by just removing the :nfs => true part from the Vagrantfile and retry to start the box with vagrant up.

After that, the box booted and the installed application was accessible via the browser. All fine.

But then there was a very ugly bug, as soon as the developer started to work on some static files like e.g. CSS or JavaScript:

Shared-Folder compatibility

As soon as a static file was modified (e.g. extended), the browser got the content of the “old” file, and some scrambled characters appended. Depending on how much stuff was added to the file, the same amount or scrambled characters was appended at the end of the file:

Alternatively, if the file got shortened (e.g. content of the file was removed), then the output was again the “old” content of the file - but cut at the position where the “new” file ended in length.

At first we thought it might be related to some strange caching issue on the side of the browser. For this, we even verified and changed the config of our nginx webserver so that all static files get delivered with the proper headers to explicitely advise the browser to not cache the static files. This didn’t help either.

After some googling around, we could solve the issue and the static files are now returned as the should be:

At first we found this entry on Stack Overflow which proposes to use NFS - well, good plan but not for Windows.

Somehow we then found a post in Google Groups which mentions the Apache configuration option “EnableSendfile” needed to be disabled to get it up and running. We’re using nginx, but now he got a new keyword to feed to Google.

This then finally led to the following entry on Stack Overflow that quotes an anser by Mitchell Hashimoto, the creator of Vagrant. This brought up the solution for us:

Sendfile is syscall which is used by nginx to read in the file. As it looks like, sendfile() is incompatible with the shared folder stuff on Windows but would work like a charm on Mac or if the shared folder is mounted via NFS.

To disable sendfile for nginx, just edit /etc/nginx/nginx.conf and make sure your http section contains the following line:

sendfile	off;

This then looks something like this:

http {
	include       mime.types;
	default_type  application/octet-stream;
	sendfile        off;
	keepalive_timeout  65;

	root /var/www/;

	server {
		listen 192.168.42.43:80;
		[...shortened...]
	}

Update: NFS on Windows

I was notified by Lorenz Ulrich that there seems to be a way to get Vagrant and NFS on Windows up and running - but as far as I understood it, it’s the other way around: Mounting a share from the Vagrant box on the Host system as a Windows drive letter.