Vagrant: mount.nfs: access denied by server while mounting

Created on 3 Mar 2015 · 31Comments · Source: hashicorp/vagrant

Mounting shared folders fails due to Vagrant putting the wrong IP address in the /etc/exports file when there are multiple interfaces using the 172.16.0.0/12 IP address space inside the virtual machine. This can reliably be reproduced with the Vagrantfile and steps shown below:

Vagrant.configure("2") do |config|
  config.vm.box = "chef/centos-7.0"
  config.vm.synced_folder ".", "/vagrant", type: "nfs"
  config.vm.network "private_network", type: "dhcp"
  config.vm.provision "shell", inline: <<EOS                                    
set -eu                                                                         
sudo yum -q -y install docker                                                   
sudo systemctl enable docker                                                    
sudo systemctl start docker                                                     
EOS                                                                             
end

Create the virtual machine with vagrant up
Restart the host (this seems to be crucial — the issue does not reproduce without this step)
Start the virtual machine with vagrant up and observe the NFS mount error as shown below:

$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'chef/centos-7.0' is up to date...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
    default: Adapter 2: hostonly
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> 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' 172.28.128.1:'/Users/test/vagrant' /vagrant

Stdout from the command:



Stderr from the command:

mount.nfs: access denied by server while mounting 172.28.128.1:/Users/test/vagrant

$ vagrant ssh -c 'ip addr'
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:20:5d:4b brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global dynamic enp0s3
       valid_lft 86359sec preferred_lft 86359sec
    inet6 fe80::a00:27ff:fe20:5d4b/64 scope link 
       valid_lft forever preferred_lft forever
3: enp0s8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 08:00:27:90:4b:4f brd ff:ff:ff:ff:ff:ff
    inet 172.28.128.4/24 brd 172.28.128.255 scope global dynamic enp0s8
       valid_lft 1175sec preferred_lft 1175sec
    inet6 fe80::a00:27ff:fe90:4b4f/64 scope link 
       valid_lft forever preferred_lft forever
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 56:84:7a:fe:97:99 brd ff:ff:ff:ff:ff:ff
    inet 172.17.42.1/16 scope global docker0
       valid_lft forever preferred_lft forever
Connection to 127.0.0.1 closed.

$ cat /etc/exports
# VAGRANT-BEGIN: 501 0fdeca89-3fd5-435a-ac64-d0439fd5b4af
"/Users/test/vagrant" 172.17.42.1 -alldirs -mapall=501:20
# VAGRANT-END: 501 0fdeca89-3fd5-435a-ac64-d0439fd5b4af

Notice that Vagrant has incorrectly picked up the IP address of the "docker0" network interface (instead of the IP address of its own private network interface) and put it in /etc/exports!

Rebooting the virtual machine (without rebooting the host) after the initial NFS mount error often does not reproduce it. However, sometimes it does. But rebooting the host itself reliably reproduces the NFS mount error.

$ vagrant version
Installed Version: 1.7.2
Latest Version: 1.7.2

You're running an up-to-date version of Vagrant!

$ sw_vers -productName
Mac OS X

$ sw_vers -productVersion
10.10.2

bug synced-foldernfs

Source

markhallm

👍1

Most helpful comment

Still happening on latest Vagrant 1.9.1 :(

panique on 19 Dec 2016

👍16

All 31 comments

I am experiencing something similar:
https://meta.discourse.org/t/vagrant-fails-mounting-discourse-stdin-is-not-a-tty/14047/19

Nevermind me writing about stdin being the problem, I think the real issue comes from the mount.nfs access denied error.

carstenhag on 9 Apr 2015

Related issue here...

VM again has two private_network interfaces, but in my case one of those interfaces is a VirtualBox internal network (and therefore is unreachable from the host machine):

machine.vm.network "private_network", type: "dhcp"
machine.vm.network "private_network", ip: "10.0.0.1", netmask: "255.255.255.0", virtualbox__intnet: "unreachable"

Whilst vagrant attempts to have the guest mount the folder using the host's reachable address (i.e. that on the former network), it configures /etc/exports with the guest's unreachable address (i.e. that on the latter network):

==> machine: 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' 172.28.128.1:'/path/to/share' /path/to/mount

Stdout from the command:



Stderr from the command:

stdin: is not a tty
mount.nfs: access denied by server while mounting 172.28.128.1:/path/to/share

$ cat /etc/exports
# VAGRANT-BEGIN: 1025 01234567-89ab-cdef-fedc-ba9876543210
"/path/to/share" 10.0.0.1 -alldirs -mapall=1025:20
# VAGRANT-END: 1025 01234567-89ab-cdef-fedc-ba9876543210

I tried reordering the configuration of the VM's interfaces within the Vagrantfile, to no avail: presumably vagrant writes into /etc/exports the address of the first (private network?) interface to become available—and since the (unreachable) internal interface is statically addressed, it's available before the dynamically addressed (reachable) interface.

Interfaces connected to networks unreachable from the host (such as VirtualBox internal networks) should obviously be excluded from the pool of potential interfaces considered for /etc/exports configuration. However, the simplest solution might be to provide a configuration directive that enables the Vagrantfile author to specify exactly which interface should be used.

eggyal on 18 Aug 2015

I have experienced this too using 1.7.4 (latest). It seems Vagrant misguesses the correct IP when writing to /etc/exports. But in my case I also got a rpc.mountd[7555]: refused mount request from 192.168.34.1 for [...]: illegal port 44172 error, which I work around by adding the insecure option to my export:

"/my/shared/folder" 192.168.34.1(insecure,rw,no_subtree_check,all_squash,anonuid=0,anongid=0,fsid=[...])

This is far from ideal because my host's /etc/exports is rewritten by Vagrant on every up or reload, but works for me.

JaimeObregon on 11 Oct 2015

i experiencing the same issue on a vmware osx guest with multiple interfaces.
in my Vagrantfile:
config.vm.network "private_network", ip: "192.168.116.81"
config.vm.network "private_network", ip: "192.168.116.82"

ifconfig: (interfaces ordered in appearance)
en3: added via Vagrantfile (192.116.168.81)
en4: added via Vagrantfile (192.116.168.82)
en2: default dhcp, (192.116.168.32)

/etc/exports:
"/path/to/my/folder" 192.168.116.81 -alldirs -mapall=502:20

what do you mean about introducing a new configuration option in Vagrantfile which would instruct vagrant to use a specific ip address in /etc/exports?
for example:
config.vm.synced_folder "./","/target/path", id: "sync-this", type: "nfs", allow_ip: "192.116.168.32"
or allow_ip: "all" to make a list of all ip's found

asoki on 9 Nov 2015

after some forced experiments, i think one fix could be to use the ip address of the enX interface with the smallest X number in the /etc/exports file.
or use vagrant ssh -c 'route get my.host.ip.addr' to determine the right interface. (at least for osx guests)

route get my.host.ip.addr
   route to: my.host.ip.addr
destination: default
       mask: default
    gateway: 192.168.116.2
  interface: en2
      flags: <UP,GATEWAY,DONE,STATIC,PRCLONING>
 recvpipe  sendpipe  ssthresh  rtt,msec    rttvar  hopcount      mtu     expire
       0         0         0         0         0         0      1500         0

asoki on 10 Nov 2015

I believe I am experiencing this (or some variant of it) as well on VMs with 3 NICs configured as follows:

Adapter 1: Standard Vagrant NAT with an ssh port forward.
Adapter 2: VirtualBox IntNet for VMs to communicate with each other over, static IP.
Adapter 3: Host-only adapter set to type: 'dhcp'.

Vagrant will only put the address of Adapter 2 in the /etc/exports file, but requests to the host obviously go out via Adapter 3, so the mount request is denied.

This issue disappears if Adapter 3 is configured with a static IP address. In this case Vagrant populates /etc/exports with the addresses of both Adapter 2 and Adapter 3.
So it would appear that Vagrant is doing something strange when asked to use DHCP for the host-only adapter.

Vagrant version: 1.8.1
VirtualBox version: 5.0.20r106931 (issue occurred on earlier versions too).

phyber on 5 May 2016

Did someone find a solution to that problem? I'm still having it with Vagrant 1.8.5 and the Vagrant file there: https://github.com/b9lab/truffle-vagrant-env/blob/master/Vagrantfile

sarbogast on 21 Jul 2016

Still happening on latest Vagrant 1.9.1 :(

panique on 19 Dec 2016

👍16

geerlingguy on 28 Dec 2016

👍1

Still happening on latest Vagrant 1.9.1 :(

Indeed, I've lost too much time trying to get NFS mounts working on my setup, which is:
Mac OS Sierra, Virtualbox 5.1, Vagrant 1.9.1, Ansible 2.2.0. I also happen to use WunderTools which depends on @geerlingguy :s Drupal VM.

I got help from the mastermind behind WunderTools, and as said in it's readme, downgrading to Vagrant 1.9.0 finally solved the mounting issue. Phew!

ilmarioranen on 10 Jan 2017

👍2

Started on a new vagrant project and upgraded to Vagrant 1.9.1, suddenly seeing this weird problem on a Oracle Enterprise Linux 7 (aka Red Hat Enterprise)
Downgrading to 1.9.0 solved this

koechsle on 28 Feb 2017

Same issue here - vagrant picks up docker0 interface ip and sets up /etc/fstab with the wrong address.

m4ce on 28 Feb 2017

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!

chrisroberts on 1 Mar 2017

@chrisroberts: So the official solution to this problem is "downgrade to a previous version"? There's no intention to roll back whatever change caused this problem so that it is resolved in future versions?

eggyal on 4 Mar 2017

👍5

@chrisroberts, @eggyal From the thread and personal experience, it appears that version 1.9.1 introduced a regression. However, upgrading to version 1.9.2 appears to have resolved this issue.

lhridley on 5 Mar 2017

👍3

For me, nothing here and in the other related issues works in my Mac OS Sierra except clean the entries in the file /var/db/mountdexptab

In my case before solved the problem (when stuck with the access denied message):

alpha@maculikulkin:~/workspace$ cat /var/db/mountdexptab 
949BDEF8-00BE-36DC-9EDA-0073257ED437 949BDEF8-00BE-36DC-9EDA-0073257ED437 0x603C812F /
XID 0x00000003 Users/alpha/workspace/web
XID 0x00000002 Users/alpha/workspace/manager
XID 0x00000001 Users/alpha/workspace/admin
------------------------------------ 3BD83172-94BF-4FBF-A98C-EBF23E0B4FDB 0xE4DAE038 /Users/alpha/workspace/web
XID 0x00000001 .
------------------------------------ 0340F9ED-D9B4-497A-929B-8DFC7699691F 0x7454F63E /Users/alpha/workspace/admin
XID 0x00000001 .
------------------------------------ EE65BC4C-C298-446A-8481-80CC2C7BA9BE 0x54D10784 /Users/alpha/workspace/manager
XID 0x00000001 .

Later when is fixed (wow!):

alpha@maculikulkin:~/workspace$ cat /var/db/mountdexptab 
949BDEF8-00BE-36DC-9EDA-0073257ED437 949BDEF8-00BE-36DC-9EDA-0073257ED437 0x603C812F /
XID 0x00000001 Users/alpha/workspace/admin
XID 0x00000002 Users/alpha/workspace/manager
XID 0x00000003 Users/alpha/workspace/web

Just delete the extra lines of mounting points!

Enjoy bitches!!! 💃

tecnocat on 7 Mar 2017

❤2

I also confirm that upgrading to 1.9.2 fixes the issue for me.

m4ce on 7 Mar 2017

Tried everything as but nothing worked . Just upgraded the version from Vagrant 1.7.4 to Vagrant 1.9.3 and its working fine now without having any issue.

shamsulbuddy on 30 Mar 2017

I had a similar problem in Ubuntu, Vagrant version 1.9.3, VB version 5.1.22

The problem was that my host's OS has changed the ifconfig to the ip command, and vboxnet0 did not have an ip address.

I had to run:

ip a add 192.168.33.1/255.255.255.0 dev vboxnet0 before Vagrant could start the NFS share

There were many other things I tried: starting/stopping the firewall (ufw, iptables, both, neither); adding specific rules to the firewall to allow all traffic to this IP; service start for each of nfs-common, nfs-kernel-server, nfs-server, nfs-client; and clearing out my /etc/exports

It wasn't until I made sure my vboxnet0 had an IP on the host machine that everything worked.

chadfurman on 27 May 2017

This is happening for me on Vagrant 1.9.5, OSX 10.12. I've tried downgrading to 1.9.3, still the same problem. Basically the nfs export routine picks the wrong IP second time through.

Here are my /etc/exports for the first vagrant up and then the second.

andypiper:~ andy$ more /etc/exports
# VAGRANT-BEGIN: 501 4609d02b-319a-4414-85dc-9fcd270f9fce
"/Users/andy/push/apiper_default/Diffusion/Main" 172.28.128.6 -alldirs -mapall=501:20
# VAGRANT-END: 501 4609d02b-319a-4414-85dc-9fcd270f9fce
andypiper:~ andy$ more /etc/exports
# VAGRANT-BEGIN: 501 4609d02b-319a-4414-85dc-9fcd270f9fce
"/Users/andy/push/apiper_default/Diffusion/Main" 172.17.0.1 -alldirs -mapall=501:20
# VAGRANT-END: 501 4609d02b-319a-4414-85dc-9fcd270f9fce

You can see that second time it picks the wrong IP (its the IP of my docker network inside the VM) and NFS won't mount. Something must be deeply flawed in the logic for this to occur. It's 100% reproducible.

Inside the VM:

ubuntu@ubuntu-xenial:~$ ifconfig
docker0   Link encap:Ethernet  HWaddr 02:42:b9:f3:82:0d  
          inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

enp0s3    Link encap:Ethernet  HWaddr 02:f2:73:7c:19:36  
          inet addr:10.0.2.15  Bcast:10.0.2.255  Mask:255.255.255.0
          inet6 addr: fe80::f2:73ff:fe7c:1936/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:496 errors:0 dropped:0 overruns:0 frame:0
          TX packets:342 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:50958 (50.9 KB)  TX bytes:49671 (49.6 KB)

enp0s8    Link encap:Ethernet  HWaddr 08:00:27:d9:12:de  
          inet addr:172.28.128.6  Bcast:172.28.128.255  Mask:255.255.255.0
          inet6 addr: fe80::a00:27ff:fed9:12de/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:25 errors:0 dropped:0 overruns:0 frame:0
          TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:3903 (3.9 KB)  TX bytes:5234 (5.2 KB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:14 errors:0 dropped:0 overruns:0 frame:0
          TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:920 (920.0 B)  TX bytes:920 (920.0 B)

Same thing with 1.8.7.
The problem is docker. Once you install docker on the vm it creates a new guest network and this confuses vagrant. If I don't install docker on the guest then things work as expected. To repro just add sudo apt-get -y install docker.io to your vagrant init script.
This bug as originally reported by the OP is not fixed, please can we reopen?

andyp1per on 21 Jun 2017

👍2

I could fix this problem with solution posted here https://www.comoinstalarlinux.com/error-en-vagrant-al-montar-directorio-compartido-con-nfs/

Modify Vagrantfile with synced directory to add NFS 4 and does not use UDP.

Works fine and could mount NFS on Vagrant VM with out problem.

larmedina75 on 5 Jul 2017

I don't think the problem is the NFS version - have a look at the OP, this is about Vagrant picking the wrong network interface. There were other issues like the one you reference but I believe those were fixed in later versions of Vagrant.

andyp1per on 6 Jul 2017

+1 not fixed

inakrin on 12 Sep 2017

Confirmed the issue still exists on 1.8.1 version with the same error. If the version of NFS would be switched from 3 to 4, the provision/up progress is hanging there without an extra error message.

oslaustin on 15 Sep 2017

Actually my issue was related to ecryptfs. My home folder in Ubuntu 17.04 is encrypted and nfs doesn't support shares on ecryptfs.
But it would be good if vagrant generated some informative message about the cause of failure, it's taken for me a couple of hours to figure it out.

inakrin on 15 Sep 2017

👍3

not fixed in windows using vagrant-winnfsd

kabala on 6 Oct 2017

@inakrin might I ask how you fixed it? I am currently experiencing the same issue and also run an encrypted home folder.

garethmcc on 19 Jan 2018

same issue, vagrant 1.9.5, macOS 10.13.3.
The first time I provisioned it worked perfectly. From the second time on it is using 172.17.0.1 as the IP, just like @andyp1per noted.

And just like he noted, my machine uses docker as well. For the time being, my fun solution is to uninstall docker before re-provisioning.

vagrant ssh
sudo apt-get purge docker-ce
sudo rm -rf /var/lib/docker
exit
vagrant reload --provision

chrisrollins65 on 6 Mar 2018

I spend half a day today debugging it and found what was the problem. I hope it will help some of you.

My config:

Vagrant 2.2.3
vagrant-ignition (0.0.3, global)
vagrant-share (1.1.9, global)
vagrant-vmware-fusion (5.0.4, global)

System Version: macOS 10.14.2 (18C54)
VMware Fusion: Version 10.1.5 (10950653)

(so everything up to date)

The problem

The IP address in /etc/exports does not match the IP address of guest host, therefore
I got mount.nfs: access denied by server while mounting

Why is it happening?

VMware Fusion runs internal DHCP server which provides IP address for each VM,
usually this IP address is attached to eth0, and your :private_network is attached to eth1

It seems that Vagrant does not have any problems figuring out the IP address of the guest VM when it comes to SSH access.
However when Vagrant changes the /etc/exports it seems it takes IP from /var/db/vmware/vmnet-dhcpd-vmnet8.leases

I found that in my /var/db/vmware/vmnet-dhcpd-vmnet8.leases there is literally hundreds of entries, some of them over 2 years old.
And for given MAC address there are sometimes more than one entry, causing this discrepancy in the /etc/exports.

Solution

Stop all VMs, exit VMware Fusion, and clear /var/db/vmware/vmnet-dhcpd-vmnet8.leases file.

nixilla on 17 Jan 2019

Had the same problem having the vagrant-directory inside my via ecryptfs encrypted home.
Moving it outside solved it.

fg-ok on 11 Feb 2019

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.