Vagrant: Files in NFS-sync folder not syncing from host to guest when changed.

[briangonzalez]

I am working with Vagrant 1.6.3 and VirtualBox (VBoxManage -v yields 4.3.12r93733).

I have noticed that changes to files on the host to do not always propagate to their corresponding shared file on the guest.

In the screenshots below, notice that the change from -50px to -22px has not propagated to the guest, which still shows -50px. This is intermittent, but happens about every 5 saves or so.

We have verified the issue on hosts OSX 10.9.2 and OSX 10.8 running an Ubuntu 13.04 guest.

Host SCSS File

Guest SCSS File

[canausa]

Can you verify the guest additions match that of the version of virtual box
you are using?

On Wed, Jul 16, 2014 at 4:28 PM, Brian Gonzalez [email protected]
wrote:

I am working with Vagrant 1.6.3 and VirtualBox (VBoxManage -v yields
4.3.12r93733).

I have noticed that changes to files on the host to do not always
propagate to their corresponding shared file on the guest.

In the screenshots below, notice that the change from -50px to -22px has
not propagated to the guest, which still shows -50px. This is
intermittent, but happens about every 5 saves or so.

We have verified the issue on hosts OSX 10.9.2 and OSX 10.8 running an
Ubuntu 13.04 guest.
Host SCSS File

[image: screen shot 2014-07-16 at 1 02 59 pm]
https://cloud.githubusercontent.com/assets/659829/3604985/3947c8a2-0d26-11e4-9667-c2aaf862f7b7.png
Guest SCSS File

[image: screen shot 2014-07-16 at 1 02 38 pm]
https://cloud.githubusercontent.com/assets/659829/3604983/2b5f12b8-0d26-11e4-894b-769266a6f1b7.png

—
Reply to this email directly or view it on GitHub
https://github.com/mitchellh/vagrant/issues/4204.

[jacefarm]

Yeah, for 10.8.5 I'm running 4.3.12 on VB and VBGA.

[briangonzalez]

For me:

VBox

$ VBoxManage -v
4.3.12r93733

VBGuest

$ vagrant vbguest --status
GuestAdditions 4.3.12 running --- OK.

[canausa]

If you are using the virtual box shared folders this is generally a virtual
box problem and not entirely a vagrant issues. It seems that way when now
as you say 1 out of 5 saves are not seen on the vm.

On Wed, Jul 16, 2014 at 5:02 PM, Brian Gonzalez [email protected]
wrote:

For me:
Host

$ VBoxManage -v
4.3.12r93733

Guest

$ vagrant vbguest --status
GuestAdditions 4.3.12 running --- OK.

—
Reply to this email directly or view it on GitHub
https://github.com/mitchellh/vagrant/issues/4204#issuecomment-49226623.

[briangonzalez]

@canausa But I am using NFS shared folders.

[janhoogeveen]

I'm also having some problems with this on Ubuntu 14. I did a few quick tests, which I'll paste below. @briangonzalez could you try out if you experience the same?

Detect changes without NFS. Using Virtualbox. Everything works rather okay. Starting a gulp or grunt server takes some time (around 10 secs) but after that file changes are propagated nicely and reliable.

When using NFS, I have to include a newline or remove a line in the file to let the guest system know the file is changed. Here are some mount_options I tried while using NFS and my comments on how they work.

tldr. don't use NFS or use NFS with the following mount options for an acceptable working environment. :mount_options => ['nolock,vers=3,udp,noatime,actimeo=1']

        #without mount options: #starts almost instantly. can take a long time before file changes are reported. livereload needs newline.
        #:mount_options => ['nolock,vers=3,udp,noatime,actimeo=1'] #starts instantly. changes are fast. < 2 secs for sass reload in browser. < 1 secs for js reload in browser.
        #:mount_options => ['nolock,vers=3,udp,noatime,actimeo=0'] #takes > 10 secs to start. after starting sass in browser is < 1.5 secs. js < 1 secs. reloading is unreliable and needs newlines.
        #:mount_options => ['nolock,vers=3,udp,actimeo=1'] #starts instantly. changes are fast. livereload needs newline.
        #:mount_options => ['nolock,vers=3,udp,actimeo=0'] #takes >10 secs to start. after starting tasks are fast. #livereload needs newline.
        #:mount_options => ['nolock,vers=3,udp,noatime'] #starts instantly. sass takes ~10 secs to output something. #livereload needs newline.

[jacefarm]

@janhoogeveen - confirming your findings. Without :mount_options, a newline was required to ensure updates for sass and js upon refresh. Setting the :mount_options worked perfectly. Ultimately, using :nfs and :mount_options => ['nolock,vers=3,udp,noatime,actimeo=1'] results in sass and js updating as expected on refresh, without requiring a newline.

[janhoogeveen]

Unfortunately I had to resort to working without NFS again. It's just too unreliable when using with Gulp.

[jacefarm]

Interesting. I used NFS and :mount_options for the entire day yesterday, and only had one instance where updating did not occur - when I changed only a single character of a CSS file and refreshed. Other than that, all was well, but it left me wondering if something was still fragile.

[parisholley]

My problem has been less with syncing and more on update detection. i have to run sass --watch with the "--poll" parameter otherwise it never detects the change.

[briangonzalez]

@mitchellh Any ideas here?

[mitchellh]

Some programs (I noticed the original issue is using Sublime) use a certain way to write files (Sublime calls it "atomic writes") that NFS sseems to not pick up. I'm not sure what the solution is that Vagrant can do here since I know subl users have fixed this by disabling that mode.

If someone can find a default flag to pass to NFS to make this work then I'd gladly add it. However, until then, I recommend searching around for that setting and disabling it.

Otherwise, I don't think this is a bug with Vagrant. Like I said, show me otherwise, and I'll gladly listen.

[madebyherzblut]

Just for reference: If you use Sublime Text 3 add "atomic_save": false to your user preferences and everything should work as expected. Sublime Text 2 does not have atomic saving.

[karlingen]

:+1: to the "atomic_save" setting.
Thanks @madebyherzblut

[cmwelsh]

I have atomic_save set to false and still have trouble with files not being seen as updated inside the VM. :(

[lasekio]

atomic_save: false doesnt solve problem for me.. Any ideas? My system is OSX 10.8.4 i use NFS sharing. It seems something like caching.

[cmwelsh]

Try adding actimeo=1 to your shared folder configuration. Here is mine for reference.

  config.vm.synced_folder ".", "/vagrant-nfs/project",
    :type => :nfs,
    :mount_options => ['nolock,vers=3,udp,noatime,actimeo=1']

[lmakarov]

I tried all possible mount_options combinations mentioned here and none of them would fix the ST3 issue for me.
The "atomic_save": false setting in ST3 does help and does NOT require any mount_options overrides at all.

I did a little research on this and found out that the root cause is that ST3 by default does not update the ctime file attribute when saving a file. "atomic_save": false fixes this quirk.

[smazurov]

thats great if you're using sublime, but with other apps (PHPStorm, in my case) we're still suffering from this issue. Will try the mount settings and report back.

[lmakarov]

@smazurov I'm also using PHPStorm and have absolutely no issue with it. In fact I do not even have to hit save with PHPStorm - it saves files all the time as you type and NFS has no issues seeing those changes.

Here's my sync_folders config (using this with docker). The host is OS X.

vagrant_root = File.dirname(__FILE__)
config.vm.synced_folder vagrant_root, vagrant_root, type: "nfs", mount_options: ["nolock", "vers=3", "tcp"]

The only important option is "nolock" in my case. Without it the guest won't mount the NFS share.
I think that has something to do with the guest OS/box, since I did not have to specify "nolock" with a different box.

[itsazzad]

@cmwelsh @smazurov
I am trying to share /var/lib/mysql following your suggestion
but failing.

==> default: chown: 
==> default: changing ownership of ‘/var/lib/mysql’
==> default: : Operation not permitted