NFS vs VirtualBox Shared Folders: Performance vs Compatibility

Direct answer

Vagrant does **not** automatically fall back to VirtualBox Shared Folders when an NFS synced folder fails on a Windows host; it aborts with an error. To get the performance of NFS while avoiding silent mount failures, you must ensure the Windows NFS Server service is ready before Vagrant attempts the mount and verify the mount succeeded.

Confirmed facts

• NFS provides higher throughput and lower latency than VirtualBox Shared Folders for large files and concurrent access because it uses the host’s native network stack and kernel‑level caching.
• VirtualBox Shared Folders work out‑of‑the‑box on Windows, Linux, and macOS guests but add userspace overhead, which hurts performance on many small‑file or metadata‑heavy workloads.
• On Windows, the NFS Server service ("Server for NFS") must be started, the appropriate firewall ports (TCP/UDP 2049, 111) opened, and the export must be correctly configured before the guest tries to mount.
• Vagrant’s NFS synced folder type (type: "nfs") will raise a Vagrant error if the mount command returns a non‑zero exit status; there is no built‑in fallback mechanism.

Steps to guarantee a stable NFS sync folder on a Windows host

1. Enable and start the Windows NFS Server

   # PowerShell (run as Administrator)
   Enable-WindowsOptionalFeature -Online -FeatureName NFS-Server -All
   Start-Service nfs-server
   Set-Service nfs-server -StartupType Automatic
   

2. Configure firewall

   netsh advfirewall firewall add rule name="NFS Server" dir=in action=allow protocol=TCP localport=2049,111
   netsh advfirewall firewall add rule name="NFS Server" dir=in action=allow protocol=UDP localport=2049,111
   

3. Create an NFS export (example exporting C:\vagrant-data to the VM)

   # PowerShell
   New-NfsShare -Name "vagrant-data" -Path "C:\vagrant-data" -Clients "/24" -Permission ReadWrite
   

4. Test the export manually from a Linux client (or the VM before Vagrant starts)

   showmount -e 
   # Should list the share
   sudo mount -t nfs :/vagrant-data /mnt/test
   # Verify mount works, then umount
   sudo umount /mnt/test
   

5. Add a pre‑check in your Vagrantfile (optional but helpful)

   config.vm.provision "shell", inline: <<-SHELL
      if ! mountpoint -q /vagrant; then
        echo "NFS mount not ready, exiting"
        exit 1
      fi
      SHELL
   

6. Define the synced folder

   config.vm.synced_folder ".", "/vagrant", type: "nfs"
   

Detecting silent NFS mount failures

• Run Vagrant with increased verbosity to see the mount command and its output:

  VAGRANT_LOG=info vagrant up
  

  Look for lines like "NFS: Mounting shared folders…" followed by either "success" or a non‑zero exit code.
• Inside the guest after vagrant up, check whether the mount is present:

  mount | grep vboxsf   # should be empty for NFS
  mount | grep nfs      # should show your export
  

• Inspect Windows Event Viewer under "Applications and Services Logs → Microsoft → Windows → NFS‑Server" for errors such as "access denied" or "port not listening".
• If the mount fails, Vagrant will abort and display an error similar to:

  ==> default: Mounting NFS shared folders...
  ==> default: Failed to mount folders in Linux guest. This is usually because
  ==> default: the "vboxsf" file system is not available. Please verify that
  ==> default: the guest additions are properly installed and the host can
  ==> default: resolve the NFS server.
  

  Treat any non‑zero exit status as a failure; there is no silent success.

One missing diagnostic detail that could change the recommendation

Are you seeing a specific error message in the Vagrant log (e.g., "access denied", "timeout", or "port 2049 not reachable")? Knowing the exact failure reason would let us tailor firewall or export‑permission fixes rather than applying a generic pre‑check.