Vagrant: VirtualBox 5.1.16 breaks NFS mounts

[geerlingguy]

Vagrant version

Vagrant 1.9.2

Host operating system

macOS 10.12.3

Guest operating system

Tested: Ubuntu 16.04 LTS, Ubuntu 14.04 LTS, CentOS 7

Vagrantfile

https://github.com/geerlingguy/drupal-vm/blob/master/Vagrantfile

Debug output

N/A

Expected behavior

NFS mounts should be used with VirtualBox guests.

Actual behavior

When I set the type of the mount to nfs, the vboxsf share is used instead. If I set the type to rsync, the mount is blazing fast.

With everything identical running on VirtualBox 5.1.14 or earlier, NFS mounts correctly and performs quite well. After I upgraded to 5.1.16 today, I had a multitude of issues with NFS mounts.

I have a sneaking suspicion it might be related to a VirtualBox bug fix: vboxsf does not get autoloaded when a mount happens (fs-vboxsf alias missing), but that's totally unconfirmed at this point.

Steps to reproduce

1. Download Drupal VM
2. Run vagrant up (ensure you're on VirtualBox 5.1.16)
3. Load the Drupal home page (http://drupalvm.dev/)

The home page should load in 1-2 seconds. It loads in 10+ seconds with the vboxsf native shared folder(!) Everything else gets to be super slow as well.

References

• New Vagrant builds seem excessively slow (as of March 10, 2017)
• NFS Seems to be the default for the first shared folder if native is tried to be used (seems to affect Windows hosts as well)

[geerlingguy]

Also of note: logging in and running sudo mount to check the shared folder mount points showed that they were using NFS... but it seems like they _actually_ weren't.

And I just re-confirmed by downgrading to 5.1.14, rebuilding (with the _same_ base box, same base config, same Vagrantfile, same codebase (actually tested on two codebases both times), and it is definitely using the speedier NFS mount.

So then I upgraded to 5.1.16 again, and confirmed (just to be _super_ thorough) that 5.1.16 seems to force vboxsf shares even if fstab is saying it's NFS!

[chrisroberts]

@geerlingguy Hi! There are two other reports around shared folders with VirtualBox that have come in so far today: #8352 and #8357. I've been looking through the code change sets in VirtualBox between the 5.1.14 and 5.1.16 release to see what's been causing these problems (as windows long paths are affected not short paths). I did see the module alias modification, but seems odd it would interfere with NFS. However, at this point I don't see any other glaringly obvious reasons.

I'm going to start running some tests to get a repro with the NFS behavior and see if I can chase anything down. Please do let me know if you find anything. Cheers!

[geerlingguy]

Thanks! I also posted a report in the VirtualBox forums, FWIW: https://forums.virtualbox.org/viewtopic.php?f=1&t=82129&p=387656#p387656

[geerlingguy]

@chrisroberts - Note that, in this case, Vagrant happily reports a successful NFS mount, and if you run sudo mount in the guest VM, it reports it's using NFS as well... the only way I _know_ it's not is the fact that I know how horribly sluggish vboxsf is compared to NFS/rsync, and the fact that PHP is spending 98% of it's time in is_dir and file_get_contents points directly to that being the culprit.

[chrisroberts]

Running on MacOS with VirtualBox 5.1.16 and 5.1.16 guest additions in a ubuntu 16.04 guest. Using an NFS mount I'm not noticing any significant differences or abnormalities. @geerlingguy do you have a box handy that's showing the behavior I could pull?

[geerlingguy]

@chrisroberts - geerlingguy/ubuntu1604 or 1404 — and it only manifests if you do a lot of file/dir seeks (like a Drupal uncached request!).

[geerlingguy]

So... maybe my results are a bit off—I just ran the gauntlet again on 5.1.14, and it seems that it's giving the same slower result as well. Digging deeper. I have one other Mac with an old box build that seems to still be fast. I noticed it's running my 1.1.7 version of the geerlingguy/ubuntu1404 box, so I'm going to see if reverting to that version of the box changes anything.

[winf-hsos]

I have the same issue, my mounted drives do not work with the same error message after upgrading to VB 5.1.16. Was this issue resolved?

[eojeel]

Same issue here when upgraded to VB 5.1.16 on windows 10, downgraded to 5.1.14 and all drives are now mounting fine.

[geerlingguy]

Note that after rebuilding my VMs again this morning (literally nothing else on my system—the one where all these problems were exhibited—has changed between 3 days ago to now). It's sitting running all day and night in my office), everything is working normally again.

No slowdown whatsoever, and everything is snappy as before. I wonder if there was some temporary file set up by VirtualBox 5.1.16 on the host that was messing with NFS, or if there might've been a bad package version in Ubuntu that snuck in late last week and was fixed over the weekend? (Though my apt-get upgrade and the fact that I had the VMs configured identically between two Macs in the same house seem to negate that theory).

[rikertothebridge]

This issue is resolved in VirtualBox preview build 5.1.17 revision 113984

[geerlingguy]

I can confirm that upgrading to VirtualBox 5.1.17 (preview build) fixes the NFS mount issue for me. So basically, 5.1.16 was a bit of a cluster, so either stick to 5.1.14 until .18 is released, or live on the edge a little and download 5.1.17 now.

In either case, I'm considering pulling my latest Vagrant Box versions so 5.1.14 versions remain—otherwise everyone building with 5.1.14 will have to wait for the vbguest plugin to install the older additions on every new VM build!

[chrisroberts]

Alright, as this is confirmed to being an upstream issue as well I'm going to close this issue. Thanks for the report and for the updates/confirmation. Cheers!

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.