Vagrant: MacOSX: requested NFS version or transport protocol is not supported

Created on 26 Jul 2016  ยท  33Comments  ยท  Source: hashicorp/vagrant

Everything worked perfectly last week. I assume my Mac was updated automatically.

I also tried:

  • to clear /etc/exports
  • to use mount_options in Vagrantfile
  • to run sudo nfsd start which shows The nfsd service is already running. on my host system
  • to recreate folders from scratch

Vagrant version

Vagrant 1.8.5

Host operating system

OS X El Capitan 10.11.6 (15G31)

Guest operating system

Ubuntu Trusty 14.04.4 LTS

Vagrantfile

require 'rbconfig'

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box = "ubuntu/trusty64"

  config.vm.provider "virtualbox" do |vb|
    vb.customize ["modifyvm", :id, "--memory", "2048"]
    vb.name = "test-nfs-share"
  end

  config.vm.network "private_network", ip: "192.168.33.99"

  config.vm.synced_folder ".", "/home/vagrant/projects", nfs: true
end

Debug output

https://gist.github.com/razbakov/bae56e1440b09b6833982fd3dc210993

Expected behavior

Folder is shared with NFS

Actual behavior

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

set -e
mkdir -p /home/vagrant/projects
mount -o vers=3,udp 192.168.33.1:/Users/xxx/Projects/simplebox-test/simpleboxtest /home/vagrant/projects
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/home/vagrant/projects
fi


Stdout from the command:



Stderr from the command:

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

Steps to reproduce

vagrant up

References

Those stackoverflow questions can be related, but didn't help me:

bug synced-foldernfs

Most helpful comment

I had 127.0.0.1 localhost commented out in my /etc/hosts file on my mac and I uncommented it and now nfs mounting works.

All 33 comments

Hi there,

Can you please try setting nfs_version: 4 in your Vagrantfile? It's possible OSX dropped support for v3 or something, but I'm unable to reproduce this on the same version of OSX myself.

@sethvargo do you mean mount_options?

I tried. It throws this error

set -e
mkdir -p /home/vagrant/projects
mount -o vers=3,udp,nfsvers=4,vers=4,actimeo=1,rsize=8192,wsize=8192,timeo=14,nolock,udp,intr,user,auto,exec,rw 192.168.33.1:/Users/razbakov/Projects/simplebox-test/simpleboxtest /home/vagrant/projects
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/home/vagrant/projects
fi

@sethvargo

doesn't help either:

==> default: Mounting NFS shared folders...
The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

set -e
mkdir -p /home/vagrant/projects
mount -o vers=4,udp 192.168.33.1:/Users/razbakov/Projects/simplebox-test/simpleboxtest /home/vagrant/projects
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/home/vagrant/projects
fi


Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: an incorrect mount option was specified

Try using TCP on IPv4 - I found that for some reason UDP on IPv4 wasn't supported on OS X 10.11 (ran rpcinfo against the Mac NFS server to find this out, using rpcinfo 172.28.128.1 |egrep "service|nfs").

Example of what worked for me - note the nfs_udp: false:

config.vm.synced_folder ".", "/home/myuser/proj", type: "nfs", nfs_udp: false, mount_options: ['rw', 'async', 'fsc' ,'actimeo=2']

I've since upgraded to OS X 10.12 El Capitan and rpcinfo shows that UDP on IPv4 is supported.

Background: useful StackOverflow thread

@RichVel doesn't help, I tried your suggestion with nfs 3 and nfs 4:

The following SSH command responded with a non-zero exit status.
Vagrant assumes that this means the command failed!

set -e
mkdir -p /home/vagrant/projects
mount -o vers=4,rw,async,fsc,actimeo=2 192.168.33.1:/Users/razbakov/Projects/simplebox-test/simpleboxtest /home/vagrant/projects
if command -v /sbin/init && /sbin/init --version | grep upstart; then
  /sbin/initctl emit --no-wait vagrant-mounted MOUNTPOINT=/home/vagrant/projects
fi


Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: Protocol not supported

@razbakov suggest you try rpcinfo command, your solution may be different to mine but rpcinfo was very useful as a guide.

You don't seem to be specifying TCP or UDP here - what happens if you try something like my Vagrantfile line which does include that?

@RichVel rpcinfo shows nothing about nfs. Does it mean that nfs service is not running on my Mac?

But if I run this on Mac sudo nfsd start it says me The nfsd service is already running.

@razbakov you need todo rpcinfo -p <your host ip address>

@bjoernhaeuser it gives nothing new. My host OS provides no nfs. Or at least virtualbox can't see it.

I ran vagrant up today and everything works fine. I didn't update anything. I have the same version. And everything works. I can't give any explanation why. That's very strange.

I had the same issue with vagrant 1.8.5 + virtualbox 5.1.2. I fixed it with a temporary workaround by downgrading NFS to v3 like so:

  config.vm.synced_folder "/path1", "/path2", type: "nfs", nfs_version: 3

Looks like there is a bug in vagrant v.1.8.5. Everything worked without issues in 1.8.4.

@ivanfrolovmd does nfsv4 work for you if you disable udp?

config.vm.synced_folder "/path1", "/path2", type: "nfs", nfs_version: 4, nfs_udp: false

Reading through this ticket and reading up on NFS I think there are a couple different things going on. Initially, it seems as though an upgrade may have been applied to a running nfs server which caused the initial problems and were automatically resolved later due to a reboot, or service restart (my assumption as the issue fixed itself).

What compounds this problem is depending on the version of the nfs server, it may default to version 4 and not properly fallback to version 3 if the UDP option is set. And the errors received from the mount command are not very indicative of the actual problem (things like incorrect mount option was specified).

7740 adds a warning to vagrant's output when UDP is enabled with NFSv4 and includes some documentation updates calling out that specific configuration pairing. I'm going to close this issue up with #7740 being the resolution, but if more problems are encountered, please open a new issue.

Thanks!

I have the same problem again. It didn't work. Then I changed nothing and it started working. Nothing changed. It is not working again.

This is happening to me as well. It appeared out of nowhere after a system crash/reboot, and hung in through a few version upgrades. Sadly, I don't have the original version of vagrant I was running, but the problem persisted in 1.8.6.

Downgrading to 1.8.4 got me going again, but in a weird way. It now skips the shared folder config i have listed in Vagrantfile and goes and mounts the default /vagrant to pwd via vboxfs

Logging in and trying to mount manually gives the same old error.

I've had a dealing with this issue today on 1.8.4, 1.8.5 and 1.8.6 and I've had to disable NFS in order to mount the drives. Tried many things using both VBox 5.0 and 5.1, but nothing worked.

I'm open to suggestions but I'm confident I've tried all I can.

@chrisroberts
Please reopen the ticket. It is not solved.

It is randomly works and doesn't work again.

Adding the line 127.0.0.1 localhost to the /etc/hosts file worked for me

References:

Isn't it still a bug of vagrant?

@razbakov Is it possible this is IPv6 related? I've had some issues with OS X hosts and VirtualBox VMs where forcing use of 127.0.0.1 made SSH work.

Maybe try replacing that /etc/hosts line with ::1 localhost to see if forcing IPv6 breaks it.

@rdonkin i added IPv6 to hosts. It is not breaking.

The problem occurs again.

Adding the line 127.0.0.1 localhost to the /etc/hosts file

Doesn't help anymore.

@razbakov I'm having similar issues, running Vagrant 1.7.4 and VirtualBox 5.0.32 r112930 on macOS Sierra 10.12.1. Tried upgrading Vagrant to 1.9.1, but no go.

A temporary solution which is working for me is to

  • halt and/or force exit Vagrant
  • do a physical reboot
  • comment out rows/clean /etc/exports
  • run Vagrant again

It's a real pain in the ass, but it seems to be working (second day in a row for me, at least).

It seems this problem boils down to a corrupt exports file, though Vagrant should be reporting this as it normally does - but whatever the cause here it isn't.

I've had another machine come back with the problem, but the following process has fixed it for us:

  • vagrant halt
  • move exports file to backup location, to ensure /etc/exports either doesn't exist or contain information on the affected virtual machine
  • vagrant up

I faced the similar issue, and the solution from @fubarhouse worked for me too. I have just removed the entries of my vm from /etc/exports and did vagrant reload.

Solution from @fubarhouse worked for me too, using Vagrant 1.8.7 and VirtualBox 5.1.10 on macOS 10.11.6 - just commented out lines in /etc/exports and did vagrant destroy && vagrant up.

For anybody continuing to have the problems after using the temporary fix in my previous comment:

We've noticed that on those machines have the error come back afterwards, to fix it again (and permanently) we did the following:

I had 127.0.0.1 localhost commented out in my /etc/hosts file on my mac and I uncommented it and now nfs mounting works.

@bkmorse Yes, indeed. This was the solution for me!

@bkmorse's solution was also what helped me out.

Reporting this still as an issue on 2.0.1

I had this very issue and solved it like this: https://github.com/hashicorp/vagrant/issues/9666#issuecomment-390601602

Please let me know if the solution in that comment solved your issue too.

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

Related issues

OtezVikentiy picture OtezVikentiy  ยท  3Comments

rhencke picture rhencke  ยท  3Comments

bbaassssiiee picture bbaassssiiee  ยท  3Comments

cbednarski picture cbednarski  ยท  3Comments

DreadPirateShawn picture DreadPirateShawn  ยท  3Comments