mount.nfs: access denied by server while mounting

[andyp1per]

https://github.com/mitchellh/vagrant/issues/5424 is not fixed. The cause is the installation of docker on the guest. Please see my comments there.

[jamesandres]

This particular issue has been plaguing me for about 1.5 years. What works for me is to stick on Vagrant 1.8.x running Virtualbox 5.0.x. Currently that means 1.8.7 and 5.0.40 respectively.

I took a crack at debugging the vagrant issue and can confirm the code is structured such that it grabs the top network (which is usually eth0/1) and assumes that is what NFS should bind to. However when docker is installed the docker0 network ends up first on the list so it binds to docker.

[gshulegaard]

Just wanted to chime in and say that I have this issue as well.

[chrisrollins65]

I commented on https://github.com/hashicorp/vagrant/issues/5424 before noticing it was closed, but I'm having the same issue.

I currently have to manually uninstall docker in my VM before each new provision as a result.

Vagrant 1.9.5, OSX 10.13.3

[r4j4h]

Also having the same issue

==> 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 192.168.50.1:/Users/me/path/to/code /vagrant

Stdout from the command:

Stderr from the command:

mount.nfs: access denied by server while mounting 192.168.50.1:/Users/me/path/to/code

WEBPT-DEV-WK79:php56 jhegman$ vagrant version
Installed Version: 2.2.0
Latest Version: 2.2.0

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

Running macOS High Sierra 10.13.6

FWIW I I also run https://github.com/adlogix/docker-machine-nfs for speedy docker toolbox and for Mac OSX High Sierra I had to modify my nfs bind mount parameters

async,noatime,actimeo=1,nolock,vers=3,udp ( https://github.com/adlogix/docker-machine-nfs/issues/79 )

I have not tried adjusting this yet here, as the real issue seems to be it grabbing the wrong interface. But I figured I'd mention since I notice @chrisrollins65 is also running High Sierra.

[r4j4h]

Just to follow up, changing the bind mount parameters did not help at all.

Definitely seems like it's a choosing-wrong-interface situation.

I did however find that switching away from nfs and using rsync+gatling worked.

For that, config.vm.synced_folder "./", "/vagrant", :nfs => true became config.vm.synced_folder ".", "/vagrant", type: "rsync", rsync__exclude: [".git/"] which obviously has different performance characteristics as it is copying files instead of using them over a local intra-host network but does get me past this issue without mucking with other systems or interfaces :(

[r4j4h]

So further follow up, I determined that it may be a host system issue.

From my Mac OSX host /etc/exports I determined two things:

1. Running sudo nfsd restart was required
2. I found I was able to export a further up root path /Users but not /Users/myuser/whatever. (Once /Users is mounted, one can still mount things deeper within it though...)

This was determined by using vagrant ssh and then running showmount -e <host ip>. This was the same IP Vagrant tried to use. I already had another VM (as mentioned docker-machine-nfs) and it showed up when I ran this. It is mounting my /Users so I tried duplicating it and pointing to my vagrant IP and after sudo nfsd restart voila the Vagrant IP showed up on the Vagrant box's showmount output.

So I am effectively having to use nfs_export: false and define it myself.

I have not determined the cause yet - another developer has an almost identical setup sans docker-machine-nfs and it "just works". We both have the same folder ownership/group permissions around /User and our respective user sub-folders.

Vagrant is adding the right /etc/exports, to the right ip, but either nfsd is not restarting properly to pick it up, or my folders are only able to be exported from high up in the folder hierarchy.

I wish I had an easier repro or fix, such as specific ownership or how to share it with nfsd's group but I hope my debugging steps can help someone else get to the bottom of their situations.

EDIT: To help a little more, I forgot to mention after adding the /Users mount and the right IP showing up in showmount output, I then successfully manually mounted the nfs mount. Here is the actual mount command, it's basically the same thing that Vagrants output prints, but this may help someone in need:

sudo mount -o vers=3,udp 192.168.50.1:/Users/me/path/to/code /vagrant

I do have to run this each time I up the box, unfortunately

[mryanb]

Also running into a similar issue if I start more than 1 vagrant host, appears to coincide with a recent upgrade to macOS 10.14.5 (18F132).

• Running Vagrant 2.2.4
• Running showmount -e localhost only displays 1 NFS path. /etc/exports indicates there should be 2.

Reverting to shared folders for now ☹️

Errors I was seeing: vagrant reload on second host

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.80.1.1:/Users/me/Sites/some-site/webroot /var/www/vagrant

Stdout from the command:

Stderr from the command:

mount.nfs: access denied by server while mounting 10.80.1.1:/Users/me/Sites/some-site/

vagrant reload

NFS is reporting that your exports file is invalid. Vagrant does
this check before making any changes to the file. Please correct
the issues below and execute "vagrant reload":

exports:5: /Users/me/Sites/some-site conflicts with existing export /Users/me/Sites

[carnnia]

the problem still exists with vagrant 2.2.5 and macOS Catalina V10.15

[maecha]

Hi, Everyone. Catalina has been annoying me since it was released (Catalina is a bad woman, isn't she?). I used to have this problem. I fixed the problem. So I wanted to write things I did .

My environment is this now:

❯❯❯ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15
BuildVersion:   19A583

❯❯❯ vagrant --version
Vagrant 2.2.4

Things I did

I had to update Vagrantfile and /etc/exports.

But first, I did this:

❯❯❯ vagrant plugin install vagrant-vbguest
❯❯❯ vagrant plugin install vagrant-omnibus

Actually, I don't know whether this action is effective for this problem or not. So you might not need it.

Vagrantfile

First, I updated config.vm.synced_folder in Vagrantfile like this:

config.vm.synced_folder "/System/Volumes/Data" + Dir.pwd, '/[DIR-NAME]', type: 'nfs'

I added "/System/Volumes/Data" into this line.

via: https://apple.stackexchange.com/questions/367158/whats-system-volumes-data

/etc/exports

Next, I updated /etc/exports and added /System/Volumes/Data into its line. Like this:

❯❯❯ sudo vi /etc/exports
# VAGRANT-BEGIN: 501 3cee32a0-9e19-4a6e-94b0-2f042dbc9180
"/System/Volumes/Data/Users/seiyamaeda/[DIR-NAME]/" xxx.xxx.xx.xx -alldirs -mapall=501:20
# VAGRANT-END: 501 3cee32a0-9e19-4a6e-94b0-2f042dbc9180

❯❯❯ sudo nfsd restart # For refreshing this config

After that, I reloaded Vagrant.

❯❯❯ vagrant reload

And then, this problem vanished.

[kwn]

@seiyamaeda

This might work if I'm the only user of the Vagrant file, or the whole development team uses MacOS. In our case we have mixture of Linux and Macos users so unfortunately we cannot hardcode any paths. And modifying /etc/exports manually is not very elegant.

[maecha]

@kwn Yeah, This way is depends on each development team situation. So yes, It is not a cool way. Just now, I recreated /etc/exports and I did vagrant reloadand then the problem didn't come out. Humm, Apparently I didn't need update /etc/exports as you say. So I don't have to modify it manually anymore.

[clemenspeters]

Thanks a lot @seiyamaeda !!! I also had to update my VirtualBox version to make it work on macOS 10.15 (Catalina).

In the Vagrantfile I put:

config.vm.synced_folder "/System/Volumes/Data" + Dir.pwd + "/../ordershop-2", "/home/vagrant/www/shopware", create: true, type: "nfs", mount_options: ['actimeo=1']

Also I had to remove old records from ~/.ssh/known_hosts to connect to vagrant via SSH (from Sequel Pro).

[tobybenjamin]

HUGE THANK YOU @seiyamaeda for the perfect instructions.

I've been trying to debug this for days, and following your steps worked immediately.

[kwn]

The issue has been resolved in Vagrant 2.2.6 which was released yesterday. I just tested it in Catalina and there are no more workarounds needed.

[marvinschroeder]

I am still having this issue when using synced folders on a USB/external volume.

ProductName: Mac OS X ProductVersion: 10.15 BuildVersion: 19A602

VirtualBox: Version 6.0.14 r133895 (Qt5.6.3) Vagrant: 2.2.6 with vagrant-bindfs (1.1.4), vagrant-hostsupdater (1.1.1.160), vagrant-vbguest (0.20.0) Box: laravel/homestead 8.2.1

I have all my repositories on a external USB drive (1 TB). Under Mojave this worked like charm. But now on Catalina I did not managed to setup the virtual box because of a "permission error".

For this command on the guest machine..

mount -o vers=3,udp,actimeo=1,nolock 192.168.10.1:/System/Volumes/Data/Volumes/VMs/Repositories/project.local /home/vagrant/code/project.local

..I get the following error..

mount.nfs: access denied by server while mounting 192.168.10.1:/System/Volumes/Data/Volumes/VMs/Repositories/project.local

I am using the laravel/homestead box and tried specifing the paths as following:

/Volumes/VMs/Repositories/project.local
/System/Volumes/Data/Volumes/VMs/Repositories/project.local 
../project.local

The Vagrant project root is /System/Volumes/Data/Volumes/VMs/Repositories/Homestead so I tried also relative paths.

The volume is not encrypted. For testing I gave VirtualBox, Terminal, mount and mount_nfs full disk access in the OS X privacy settings.

The setup works (like under High Sierra and Mojave) only if I move the "Repositories" folder beneath "/Volumes/Macintosh HD/Users/marvin/".

Am I missing something in permissions for other Volumes?

[iamfinky]

FWIW I think I've just discovered a potential issue with this: if your path contains a space, as is allowed in macOS, that space will break the NFS exports line created by Vagrant.

As a workaround, renaming my directory to remove the space has resolved the issue.

[SteveRohrlack]

What worked for me:

• making sure iterm/terminal has "full disk access"
• installing the vagrant-vbguest plugin (idk for sure if that helped)
• allow "full disk access" to /sbin/nfsd (see https://github.com/laravel/homestead/issues/1304#issuecomment-545391163)

Btw.: my shared folders reside on an external drive

[ngocphamm]

@SteveRohrlack Can you please let me know what "item" exactly you are talking about in your first point?

I'm having this issue even with Vagrant 2.2.6, and I have already done the other 2 items in your list.

mount.nfs: access denied by server while mounting 192.168.56.1:/System/Volumes/Data/Volumes/DATA/www

[SteveRohrlack]

@SteveRohrlack Can you please let me know what "item" exactly you are talking about in your first point?

I'm having this issue even with Vagrant 2.2.6, and I have already done the other 2 items in your list.

mount.nfs: access denied by server while mounting 192.168.56.1:/System/Volumes/Data/Volumes/DATA/www

That was a typo - I meant “iterm”. I fixed the typo it in my comment.

[ngocphamm]

Thanks for your answer!

I use Alacritty and just gave it full disk access but still having this issue 😞

[matejstrasek]

Same issue here. Running Vagrant 2.2.6, macOS 10.15.1, VirtualBox 6.0.14 and keep getting mount.nfs: access denied by server while mounting.

Gave full disc access to nfsd, iterm and virtualbox. Also turned off FileVault to disable encryption. Cleaned /etc/exports and restarted nfsd. Tried also with adding /System/Volumes/Data/ to synced_folders. Still keep getting same error.

Code is on APFS (case-sensitive) volume.

Any more ideas what to try?

[MarioLegenda]

I had the same issue. All I had to do is disable starting docker on startup from this post. Do a vagrant reload after it. When you ssh into it, do a sudo systemctl start docker or sudo service docker start, whatever works with you. It all works. Vagrant version 2.2.3 with Ubuntu 18.04.

EDIT:

I read this entire thread and my development environment is not as complicated as all of yours and I failed to mention that. Sorry. I was in a coffee shop and was in a hurry but later forgot to update it.

Anyway, I'm working on two microservices that, for development purposes, are on a single Ubuntu machine while my host is a Mac. One microservice is in NodeJS, the other in Go. My Go project points to /var/www dir on my virtual machine that has www-data group and the rest of web permissions.

The main reason why this error was happening, for me at least, is because I used absolute paths and Docker. So for example,

config.vm.synced_folder "/Users/myusername/you/know/the/rest", "/var/www/html"

would fail. Then I shutdown the docker on boot like above but it still didn't work. So I changed it to a relative path that was the same as the absolute path as before, with docker on boot turned off

config.vm.synced_folder "../applications/my-app-name/dir-to-sync", "/var/www/html"

And it worked. The only downside is that, since Go is installed on the vagrant linux OS, my IDE does not know of any third party packaged that I install so its all red :). But I can live with that.

Hope that someone finds this helpful.

[ngocphamm]

For me the VM I'm trying to spin up doesn't have docker in it. I think it's just the fact that the shared folder(s) I configured for that VM is in a different volume (/System/Volumes/Data/Volumes/DATA/www) than the primary Macintosh HD volume.

[gadelkareem]

Installing the plugins and modifying the Vagrantfile was not required. Only updating the /etc/exports to include the new path /System/Volumes/Data/Users and removing the old /Users ones and giving full access to nfsd https://github.com/laravel/homestead/issues/1304#issuecomment-545391163

[ghost]

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.