65
votes

I'm using Vagrant to run an Ubuntu powered VirtualBox with Apache2.

The webserver, among others, serves static files from my /vagrant directory.

This works well most of the time. But when I change an image on my shared folder and reload the website, the previous version of the image is served, but it's truncated.

It works if I delete the old picture first from my shared folder, refresh the website so the picture is NOT shown, then save the new file and reload the website again.

Does anyone knew about this problem? I don't have anything special installed, just Apache 2 with mod_rewrite and PHP with Mongo, APC Plugin, MongoDB as well as nodeJS with a bunch of scripts.

6
I had the same problem but with a text (json) file. I was only able to do a specific enough search to find this answer after I tried Nginx and found that it had the same problem as Apache.Nathan Long

6 Answers

133
votes

Found the answer here:

JC,

What you're seeing is probably because the server serving the static files is using the "sendfile()" syscall, which is broken with the VirtualBox file system. You need to disable sendfile() usage in your server. For Apache:

EnableSendfile off

And for nginx: sendfile off;

Best, Mitchell

8
votes

This has been driving me crazy! Thanks for posting this Philipp. For those of you who have no idea how to do change the config file, here is what I did:

To find the file: $ sudo find -name "nginx.conf"

Mine was here: ./etc/nginx/nginx.conf

So I ran this to modify it: $ sudo nano ./etc/nginx/nginx.conf

Change the line that contains sendfile on; to sendfile off;

Don't forget to exit and vagrant reload!

6
votes

This is old bug in VirtualBox (see: #819, #9069, #12597, #14920) where vboxvfs seems to have some problems with mmapped access to files which are synched.

This may happen when you edit the file outside of VM, and you expect to see the same change within the VM.

To workaround this problem, you need to disable the kernel sendfile support to deliver files to the client by disabling EnableSendfile option, either in httpd.conf or in vhosts file, e.g.

<Directory "/path-to-nfs-files">
  EnableSendfile Off
</Directory>

This is especially trouble for NFS or SMB mounted files. After the change reload the Apache.

Similar for Nginx (in nginx.conf), e.g.

sendfile off;

Other workaround is to remember to not edit the files on the host, or try to re-edit the same file, but within the VM.


Another workaround includes dropping the Linux pagecache, e.g.

echo 1 > /proc/sys/vm/drop_caches

Or to clear the caches every second (as per this post), try:

watch -n 1 $(sync; echo 1 > /proc/sys/vm/drop_caches)

Note: Number 1 stands for freeing pagecache, 2 for dentries and inodes, 3 for pagecache, dentries and inodes.


The above problem can be replicated by the following mmap-test program, see: mmap-problem.c.

4
votes

I've got similar problem with VirtualBox/Docker/Nginx environment.

The decision with dropping Linux pagecache echo 1 > /proc/sys/vm/drop_caches works fine but looks awkward.

Also the directive sendfile off; in the nginx.conf didn't solve the problem and I tried to use it with expires off; directive together and it was successful.

So, my decision looks like

sendfile off;
expires off;
3
votes

For anyone using Laravel 5, Barryvdh's Debugbar and browserSync via gulp.watch, you may get this error. I had exactly the same error because of how browser Sync was proxying my request. If I viewed my dev server via: http://127.0.0.1:3000/laravel/page I got the error http://127.0.0.1/laravel/page error gone.

I've flagged it with our friends at browserSync, they do an awesome job. So, it's more of a reason than a solution, but rather than spend hours trying to fix it, test to see if this is your problem before wasting any more time.

This issue is also similar to the errors found in this article

0
votes

This was also responsible for strange behavior regarding CSS files in a CentOS/VirtualBox setup.

You could change the contents of a CSS file in the /vagrant folder, and the browser would show a Status of 200 (instead of a 304), meaning it knew the file was new. But the contents wouldn't have changed.