mount.nfs: access denied by server while mounting #5424

makeamark1 · 2015-03-03T16:46:48Z

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

The text was updated successfully, but these errors were encountered:

carstenhag · 2015-04-09T14:01:34Z

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.

eggyal · 2015-08-18T15:30:54Z

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.

JaimeObregon · 2015-10-11T01:45:56Z

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.

asoki · 2015-11-09T18:00:54Z

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 · 2015-11-10T10:41:22Z

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

phyber · 2016-05-05T09:19:23Z

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).

sarbogast · 2016-07-21T18:11:17Z

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

panique · 2016-12-19T19:20:57Z

Still happening on latest Vagrant 1.9.1 :(

geerlingguy · 2016-12-28T17:08:01Z

See related: #8138

ilmarioranen · 2017-01-10T10:06:25Z

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!

koechsle · 2017-02-28T15:03:27Z

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

m4ce · 2017-02-28T15:04:59Z

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

chrisroberts · 2017-03-01T22:12:59Z

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!

eggyal · 2017-03-04T14:02:48Z

@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?

lhridley · 2017-03-05T18:36:48Z

@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.

tecnocat · 2017-03-07T18:42:22Z

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!!! 💃

m4ce · 2017-03-07T19:45:33Z

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

shamsulbuddy · 2017-03-30T14:17:06Z

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.

chadfurman · 2017-05-27T16:05:16Z

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.

andyp1per · 2017-06-21T10:29:29Z

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?

larmedina75 · 2017-07-05T20:30:26Z

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.

andyp1per · 2017-07-06T07:04:26Z

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.

inakrin · 2017-09-12T06:05:47Z

+1 not fixed

oslaustin · 2017-09-15T14:19:48Z

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.

inakrin · 2017-09-15T16:14:09Z

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.

kabala · 2017-10-06T16:38:51Z

not fixed in windows using vagrant-winnfsd

garethmcc · 2018-01-19T12:47:17Z

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

chrisrollins65 · 2018-03-06T09:16:25Z

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

nixilla · 2019-01-17T13:10:27Z

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.

fg-ok · 2019-02-11T08:31:31Z

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

ghost · 2020-03-28T01:55:19Z

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.

sethvargo added bug nfs labels Mar 3, 2015

carstenhag mentioned this issue Apr 9, 2015

NFS mount failed on Ubuntu/Linux mint protobox/protobox#161

Open

sethvargo added synced-folders/nfs and removed synced-folders/nfs nfs labels May 30, 2015

joksnet mentioned this issue Feb 18, 2016

NFS mount from host ip instead of machine ip #7055

Closed

phyber mentioned this issue May 5, 2016

Incorrect /etc/exports generation. #7289

Closed

greg0ire mentioned this issue May 27, 2016

error on Fedora jordisala1991/ArchetypeSonata#2

Closed

FunTimeCoding mentioned this issue Sep 15, 2016

NFS too slow to start on Debian #7795

Closed

chrisroberts added this to the 1.8 milestone Sep 30, 2016

geerlingguy mentioned this issue Dec 28, 2016

mount.nfs: access denied by server while mounting on RHEL guest geerlingguy/drupal-vm#1040

Closed

eoli3n mentioned this issue Jan 9, 2017

sync folder : access denied by the server #8179

Open

revprez mentioned this issue Jan 31, 2017

Encountering "mount.nfs: access denied by server" on Ubuntu 16.10 with NFS synced_folder configured #8241

Closed

mike-source mentioned this issue Mar 1, 2017

Mounting NFS shared folders... richdynamix/magestead#68

Open

chrisroberts closed this as completed Mar 1, 2017

lhridley mentioned this issue Mar 5, 2017

mount.nfs: access denied by server while mounting #8332

Closed

This was referenced Mar 7, 2017

NFS mount fails on subsequent vagrant up commands #1941

Closed

NFS mount error: v1.2.2 #1744

Closed

scythian mentioned this issue Mar 29, 2017

Mount NFS problem on OSX 10.12.3 cibox/cibox#565

Open

andyp1per mentioned this issue Jun 21, 2017

mount.nfs: access denied by server while mounting #8704

Closed

flibbertigibbet mentioned this issue Nov 3, 2017

Feature/kak/allow nfs disable#187 azavea/temperate#190

Merged

waynemerry mentioned this issue Oct 18, 2018

NFS problem in sharing an encrypted folder on host django/django-box#41

Open

mook-as mentioned this issue Jul 19, 2019

Vagrant up had an error: mount.nfs: access denied by server while mounting 192.168.47.1:/root/workspace/xiujuan/scf/.fissile/.bosh SUSE/scf#2587

Closed

ghost locked and limited conversation to collaborators Mar 28, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

mount.nfs: access denied by server while mounting #5424

mount.nfs: access denied by server while mounting #5424

makeamark1 commented Mar 3, 2015

carstenhag commented Apr 9, 2015

eggyal commented Aug 18, 2015

JaimeObregon commented Oct 11, 2015

asoki commented Nov 9, 2015

asoki commented Nov 10, 2015

phyber commented May 5, 2016 •

edited

Loading

sarbogast commented Jul 21, 2016

panique commented Dec 19, 2016

geerlingguy commented Dec 28, 2016

ilmarioranen commented Jan 10, 2017

koechsle commented Feb 28, 2017 •

edited

Loading

m4ce commented Feb 28, 2017

chrisroberts commented Mar 1, 2017

eggyal commented Mar 4, 2017

lhridley commented Mar 5, 2017 •

edited

Loading

tecnocat commented Mar 7, 2017 •

edited

Loading

m4ce commented Mar 7, 2017

shamsulbuddy commented Mar 30, 2017

chadfurman commented May 27, 2017

andyp1per commented Jun 21, 2017 •

edited

Loading

larmedina75 commented Jul 5, 2017 •

edited

Loading

andyp1per commented Jul 6, 2017

inakrin commented Sep 12, 2017

oslaustin commented Sep 15, 2017

inakrin commented Sep 15, 2017

kabala commented Oct 6, 2017

garethmcc commented Jan 19, 2018

chrisrollins65 commented Mar 6, 2018 •

edited

Loading

nixilla commented Jan 17, 2019

fg-ok commented Feb 11, 2019

ghost commented Mar 28, 2020

mount.nfs: access denied by server while mounting #5424

mount.nfs: access denied by server while mounting #5424

Comments

makeamark1 commented Mar 3, 2015

carstenhag commented Apr 9, 2015

eggyal commented Aug 18, 2015

JaimeObregon commented Oct 11, 2015

asoki commented Nov 9, 2015

asoki commented Nov 10, 2015

phyber commented May 5, 2016 • edited Loading

sarbogast commented Jul 21, 2016

panique commented Dec 19, 2016

geerlingguy commented Dec 28, 2016

ilmarioranen commented Jan 10, 2017

koechsle commented Feb 28, 2017 • edited Loading

m4ce commented Feb 28, 2017

chrisroberts commented Mar 1, 2017

eggyal commented Mar 4, 2017

lhridley commented Mar 5, 2017 • edited Loading

tecnocat commented Mar 7, 2017 • edited Loading

m4ce commented Mar 7, 2017

shamsulbuddy commented Mar 30, 2017

chadfurman commented May 27, 2017

andyp1per commented Jun 21, 2017 • edited Loading

larmedina75 commented Jul 5, 2017 • edited Loading

andyp1per commented Jul 6, 2017

inakrin commented Sep 12, 2017

oslaustin commented Sep 15, 2017

inakrin commented Sep 15, 2017

kabala commented Oct 6, 2017

garethmcc commented Jan 19, 2018

chrisrollins65 commented Mar 6, 2018 • edited Loading

nixilla commented Jan 17, 2019

The problem

Why is it happening?

Solution

fg-ok commented Feb 11, 2019

ghost commented Mar 28, 2020

phyber commented May 5, 2016 •

edited

Loading

koechsle commented Feb 28, 2017 •

edited

Loading

lhridley commented Mar 5, 2017 •

edited

Loading

tecnocat commented Mar 7, 2017 •

edited

Loading

andyp1per commented Jun 21, 2017 •

edited

Loading

larmedina75 commented Jul 5, 2017 •

edited

Loading

chrisrollins65 commented Mar 6, 2018 •

edited

Loading