Vagrant: nfs synced folders fail with nfs-utils 2.3.1, because UDP is no longer active by default

Created on 12 Jan 2018  ยท  7Comments  ยท  Source: hashicorp/vagrant

Vagrant version

Vagrant 2.0.1

Host operating system

Arch Linux

Guest operating system

ubuntu/xenial64

Vagrantfile

...
config.vm.network :private_network, ip: '10.11.12.13'
config.vm.synced_folder ".", "/vagrant/", type: "nfs"
  config.vm.provider "virtualbox" do |vb|
    #   # Display the VirtualBox GUI when booting the machine
       vb.gui = true
    #   
    #   # Customize the amount of memory on the VM:
    vb.memory = 2048
    vb.cpus = 2 

    unless Vagrant::Util::Platform.linux?
      vb.customize [ "guestproperty", "set", :id, "/VirtualBox/GuestAdd/VBoxService/--timesync-set-threshold", 3000 ]
    end 
  end 
...

Debug output

_No, I'm not going to manually look through a 30k line log file to redact personal data. That's a ludicrous requirement._

Expected behavior

NFS shared folder should mount automagically.

Actual behavior

NFS shared folder doesn't mount, instead vagrant up aborts with the error message:

==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

mount -o vers=3,udp 10.11.12.1:/some/path /vagrant

Stdout from the command:



Stderr from the command:

mount.nfs: requested NFS version or transport protocol is not supported

From inside the box:

ubuntu@ubuntu-xenial:~$ sudo mount -vvv -o vers=3,udp 10.11.12.1:/some/path /vagrant
mount.nfs: timeout set for Fri Jan 12 09:59:25 2018
mount.nfs: trying text-based options 'vers=3,udp,addr=10.11.12.1'
mount.nfs: prog 100003, trying vers=3, prot=17
mount.nfs: portmap query failed: RPC: Program not registered
mount.nfs: requested NFS version or transport protocol is not supported

Steps to reproduce

  1. Update to nfs-utils 2.3.1 or set udp=n in /etc/nfs.conf
  2. Set config.vm.synced_folder ... type:"nfs"
  3. systemctl restart nfs-server.service
  4. vagrant up

Description

I've traced the problem down to a changed default configuration in nfs-utils ( http://linux-nfs.org/wiki/index.php/Main_Page ) in the 2.3.1 release from 2017-12-20 ( https://marc.info/?l=linux-fsdevel&m=151378856610540&w=2 ). The commit http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 disables the UDP port by default.

I propose to use TCP for nfs synced_folders by default, especially since it seems to improve performance for some users: http://blog.theodo.fr/2017/07/speed-vagrant-synced-folders/ .

enhancement synced-foldernfs

Most helpful comment

the udp=y option did work to me in host archlinux

All 7 comments

I am also experiencing the same issue.
Solution was to add nfs_udp: false to config.vm.synced_folder arguments.

Also running into this after upgrading to 10.13.3

@stefanotorresi unfortunately this didn't help in my case. The "normal" folder mounting works (but is a bit slow, plus there are issues with the permissions in the VM).

The command I used is:
config.vm.synced_folder "./source/foobar", "/var/www/foobar", type: "nfs", nfs_udp: false

I then also tryed:

    config.vm.synced_folder "./source/foobar", "/var/www/foobar",
        nfs: true,
        nfs_udp: false

Which failed and also

    config.vm.synced_folder "./source/foobar", "/var/www/foobar",
        nfs: true,
        nfs_udp: false,
        nfs_version: 4

Which just hanged at ==> default: Mounting NFS shared folders...

From the wiki (worked for me)

If UDP stopped working then, add udp=y under [nfsd] in /etc/nfs.conf. Then restart nfs-server.service.

the udp=y option did work to me in host archlinux

Hi there,

It looks like this has been resolved within a previously shipped version of Vagrant so I am now closing this issue. If the original issue was not fully resolved, please reopen this issue or create a new one.

Cheers!

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.

Was this page helpful?
0 / 5 - 0 ratings