vagrant icon indicating copy to clipboard operation
vagrant copied to clipboard

mount.nfs: access denied by server while mounting. External drive/volume. macOS 11.3

Open ionutantohi opened this issue 3 years ago • 30 comments

The last macos update (11.3) broke mounting folders using nfs from external drive/volume.

In my setup, I have another partition called "Docs". which is accessible at /Volumes/Docs

This partition is case-sensitive, but I don't think it matters for this issue.

Within this partition I have folder called projects. This folder is used to be shared within the vm.

Vagrant version

Vagrant 2.2.15

Host operating system

macOS BigSur 11.3 (20E232)

Guest operating system

Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-72-generic x86_64)

Virtualbox

Version 6.1.20 r143896 (Qt5.6.3)

Vagrantfile

# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure(2) do |config|

  config.vm.box = 'ubuntu/focal64'
  config.vm.hostname = 'devbox'
  config.vm.network "public_network", ip: '192.168.0.80', bridge: 'en0: Ethernet'
  config.vm.network "private_network", ip: '192.168.1.80'

  config.vm.synced_folder '/Volumes/Docs/projects', '/var/www/html', 
    type: "nfs", 
    nfs_udp: false, 
    nfs_version: 3, 
    mount_options: ['rw', 'tcp', 'fsc','actimeo=2']
end

Expected behavior

A folder located on external volume should be mounted in guest vm.

Actual behavior

mount -o vers=3,rw,tcp,fsc,actimeo=2 192.168.1.1:/System/Volumes/Data/Volumes/Docs/projects /var/www/html

Stderr from the command:

mount.nfs: access denied by server while mounting 192.168.1.1:/System/Volumes/Data/Volumes/Docs/projects

showmount on client

showmount -e 192.168.1.1

Export list for 192.168.1.1:
/System/Volumes/Data/Volumes/Docs/projects 192.168.1.80

Host export file

# VAGRANT-BEGIN: 501 b6e79ee8-05e0-4042-b64e-3fdcef77ecf8
"/System/Volumes/Data/Volumes/Docs/projects" -alldirs -mapall=501:20 192.168.1.80
# VAGRANT-END: 501 b6e79ee8-05e0-4042-b64e-3fdcef77ecf8

ionutantohi avatar Apr 27 '21 15:04 ionutantohi

More details about this:

  • mounting the whole partition /Volumes/Docs works
  • mounting from /Users/user/* also works

In the last macos update there is a change to APFS filesystem, which might be the cause for this image

ionutantohi avatar Apr 28 '21 06:04 ionutantohi

Hi @ionutantohi

i have the same setup with the same problems. Your suggested workaround to mount the whole partition worked for me also, so thank for that.

hope we find a better solution in the future.

enursed avatar Apr 28 '21 10:04 enursed

I've been banging my head over this for the whole day, I'm glad it wasn't just me. I suspected too the latest MacOs update as until the day before the same setup with NFS shares worked just fine. Unfortunately I can't mount the whole partition, @ionutantohi solution doesn't make the cut for me...

unfulvio avatar Apr 28 '21 15:04 unfulvio

uhh actually I nailed it, thanks to @ionutantohi mentioning that mounting from the root of the partition worked for him... turns out that if I mounted that before everything else, to a dummy dir in my VM, then any other mount instruction for any other directory within that partition worked as well!

unfulvio avatar Apr 28 '21 15:04 unfulvio

Indeed, mounting first the whole partition and then my folder worked for me as well, but unfortunately this is not an option for me.

config.vm.synced_folder '/Volumes/Docs', '/tmp/shared-partition', 
config.vm.synced_folder '/Volumes/Docs/projects', '/var/www/html', 

But, I don't think this solution is ok going on. In my tests, after reloading vagrant with above shared folders, it complained that nfs exports are not right

# VAGRANT-BEGIN: 501 66d3d041-06db-4025-82bc-b6ac8a8102b3
"/System/Volumes/Data/Volumes/Docs" -alldirs -mapall=0:80 192.168.1.80
"/System/Volumes/Data/Volumes/Docs/projects" -alldirs -mapall=0:80 192.168.1.80
# VAGRANT-END: 501 66d3d041-06db-4025-82bc-b6ac8a8102b3
exports:6: /System/Volumes/Data/Volumes/Docs/projects conflicts with existing export /System/Volumes/Data/Volumes/Docs

@unfulvio did you encounter this if you run vagrant reload?

Anyway, this is not related to the original issue.

ionutantohi avatar Apr 28 '21 17:04 ionutantohi

Actually you're right @ionutantohi - initially sharing the whole volume seemed to fix, but later I bumped in the same error you mentioned in your latest comment, if I also want to share some specific folder inside the volume to another mount point in the VM, bummer.

I tried adding paths in different ways, different mount options or NFS version to use, but I still could not get around the issue. Any luck as an actionable workaround until a fix or proper solution is in place?

I don't want to switch to VirtualBox shared folders... for some reason they become unreliable if I add too many (I share over 50 folders), so I'm out of luck...

unfulvio avatar Apr 29 '21 02:04 unfulvio

In my case, the workaround was to move from the external volume and not use it.

So, I copied everything from /Volumes/Docs/projects to /Users/user-name/projects and used /Users/user-name/projects in vagrant file.

Note: symlink from /Volumes/Docs/projects to /Users/user-name/projects doesn't work, don't try.

ionutantohi avatar Apr 29 '21 05:04 ionutantohi

Understood, @ionutantohi

Unfortunately that's precisely what I wanted to avoid... I had my volume with folders to share in a different partition for reasons. I wonder if there's a workaround out there with user permissions. Sounds like, judging by the error type.

unfulvio avatar Apr 29 '21 10:04 unfulvio

by the way may I suggest to edit the issue title to remove "External drive" as this may happen also in the same drive but a different volume - can mention that

unfulvio avatar Apr 29 '21 10:04 unfulvio

I had the same issue (macOS Big Sur 11.3, Vagrant 2.2.15, VirtualBox 6.1.22) with additional partition (APFS Volume).

mount.nfs: access denied by server while mounting 10.10.20.1:/System/Volumes/Data/Volumes/Drive/Projects

Everything works correctly on macOS Big Sur 11.2.

vadimskrotsky avatar May 02 '21 11:05 vadimskrotsky

Same problem with Vagrant 2.2.15 and VirtualBox 6.1.18!

Forced to move the code from the external disk to a user subdirectory.

Not great, when you don't have much space on the mac internal disk :(

JmRy avatar May 02 '21 16:05 JmRy

vagrant 2.2.16 and VirtualBox 6.1.22 BigSur 11.4 mount.nfs: access denied by server while mounting 192.168.149.1:/System/Volumes/Data/Volumes/Dev/Projects/VOL/code/application/OLCS

same - works with local folder

sdh100shaun avatar Jun 13 '21 07:06 sdh100shaun

I got a tempory fix to work, but it does mean mounting the whole secondary partition on the vm.

It works by creating two shares where the second is the project folder can mount in the right place (the second does not need adding to the exports file)

Before:

config.vm.synced_folder ".", "/vagrant", type: "nfs", mount_options: ['actimeo=1']

After

config.vm.synced_folder "/Volumes/Development", "/development", type: "nfs", mount_options: ['actimeo=1']
config.vm.synced_folder "/Volumes/Development/path/to/project", "/vagrant", type: "nfs", nfs_export: false, mount_options: ['actimeo=1']`

vagrant 2.2.16 - VirtualBox 6.1.22 - BigSur 11.4

bluerhinos avatar Jun 13 '21 08:06 bluerhinos

@bluerhinos thanks - that fix appears to work for me

sdh100shaun avatar Jun 13 '21 08:06 sdh100shaun

I tried @bluerhinos solutions, made fresh installs of vagrant and VirtualBox but still get this: mount.nfs: access denied by server while mounting I am running OS X 11.4...

andreassp avatar Jun 15 '21 14:06 andreassp

I have the same problem and i got a fix. If netplan.io is installed on your linux distribution uninstall it.

apt remove netplan.io

kalypso63 avatar Jun 24 '21 09:06 kalypso63

Just upgraded to OS 11.4, and vagrant 2.2.16. Same issue with "System/Volumes/Data" being prepended to the paths in my exports file.

adleviton avatar Jun 28 '21 18:06 adleviton

@adleviton the fact that "System/Volumes/Data" is prepended in the export file is fine, and this is the desired behaviour and not related to this issue.

ionutantohi avatar Jun 28 '21 19:06 ionutantohi

@ionutantohi after spending more time with this issue, I see what you mean. I'm experiencing the issue as you describe ... not able to mount shared folders from an external drive in vagrant.

adleviton avatar Jun 28 '21 19:06 adleviton

I also tried using an external drive formatted with AFPS, and still received mount.nfs: access denied by server while mounting ...

adleviton avatar Jun 29 '21 19:06 adleviton

Here is a fix that works for laravel/homestead box

Fix added in the Homestead.yaml file

folders:
    -
        map: /Volumes/DATA
        to: /home/data
        type: "nfs"
    -
        map: /Volumes/DATA/dev
        to: /home/vagrant/code
        type: "nfs"
        nfs_export: false

This corresponds to the Vagrantfile fix of @bluerhinos above

vagrant 2.2.16 - VirtualBox 6.1.22 - BigSur 11.4 - Laravel/Homestead 12.3

JmRy avatar Jul 03 '21 15:07 JmRy

is there any update on this?

kvonspiczak avatar Aug 02 '21 09:08 kvonspiczak

My projects are not on an external drive, they are in my home directory (which vagrant was turning into /System/Volumes/Data/Users/myname/Documents/). But I had this problem of "nfsd has no read access to [directory]" after upgrading OSX from Mojave to Big Sur.

I was also getting an error relating to /etc/exports unless I removed the previous vagrant lines from the file manually.

In the end I fixed both issues by going to System Preferences > Security & Privacy > Full Disk Access, click padlock and unlock, then add /sbin/nfsd to the list.

robme avatar Aug 12 '21 11:08 robme

This issue is on external drive/volume, including another volume created from the internal drive. For instance, I have one disk on my laptop, and I created another volume Dev. Then there will be access denied error if I mount /Volumes/Dev/<directory name>. But if mount the whole drive /Volumes/Dev, it goes through.

Full Disk Access in Security & Privacy doesn't help. I'm guessing if we could grant Network Volumes access to /sbin/nfsd under Files and Folders settings of Security & Privacy, that might resolve the problem. But unfortunately the + button under that list is always grey out. I have not figured out a method to test it out.

➜ ~ ll /Volumes
total 64 drwxr-xr-x 8 macuser staff 256B 10 Aug 18:23 Dev lrwxr-xr-x 1 root wheel 1B 11 Aug 07:57 Macintosh HD -> / ➜ ~ ll /System/Volumes/Data/Volumes total 64 drwxr-xr-x 8 macuser staff 256B 10 Aug 18:23 Dev lrwxr-xr-x 1 root wheel 1B 11 Aug 07:57 Macintosh HD -> /

Hailong avatar Aug 12 '21 11:08 Hailong

@Hailong You need to click the little padlock at the bottom left in order to change the Privacy settings.

robme avatar Aug 12 '21 12:08 robme

@robme For the record, the issue you had is not related to this issue.

ionutantohi avatar Aug 12 '21 12:08 ionutantohi

@ionutantohi I know it's not the same issue but it is related - I get this exact error after upgrading. This is the ticket that turns up in searches and everyone links to, so I added what worked for me in case it helps anyone who isn't using external volumes.

robme avatar Aug 12 '21 13:08 robme

@Hailong You need to click the little padlock at the bottom left in order to change the Privacy settings.

@robme There are two different list on the Security & Privacy dialog. We can add new item to the Full Disk Access list, but it doesn't resolve this issue. We can't add new item to Files and Folders, which I'm guessing may help. Because we can see Terminal app is there, and there is a Network Volumes permission under it.

Here is a document about managing the Privacy policies with MDM, https://support.apple.com/en-ca/guide/mdm/mdm38df53c2a/web, and it supports Network volumes in the payload.

I wish if someone's computer is enrolled in a MDM solution could have a try.

Hailong avatar Aug 12 '21 14:08 Hailong

@jcrubrik ionutantohi already mentioned that mounting the whole partition works. But one reason I can see it's not ideal is that, the root folder of volume has several system hidden folders in it, and they are owned by root user, for example:

✗ ls -la /Volumes/Dev/ 
total 16
drwxr-xr-x     8 devuser      staff    256 10 Aug 18:23 .
drwxr-xr-x     7 root         wheel    224 13 Aug 06:52 ..
drwx------     4 root         wheel    128  9 Aug 23:04 .Spotlight-V100
d-wx--x--t     3 root         wheel     96  9 Aug 23:04 .Trashes
drwx------  1365 root         wheel  43680 13 Aug 15:59 .fseventsd
drwxr-xr-x     5 devuser      staff    160 11 Aug 10:26 docker

Hailong avatar Aug 13 '21 21:08 Hailong

An update for those which are monitoring this issue. It seems that this issue is fixed on macOS Monterey with the latest software stack:

macOS: Monterey 12.5.1 (21G83) vagrant: 2.3.0 VirtualBox: 6.1.38 r153438 (Qt5.6.3)

I tested mounting from external drive but also from another volume(partition), and seems to work.

One hint about why this is working now might sit in exports file.

On Big Sur the exports looked like this

# VAGRANT-BEGIN: 501 b6e79ee8-05e0-4042-b64e-3fdcef77ecf8
"/System/Volumes/Data/Volumes/Docs/projects" -alldirs -mapall=501:20 192.168.1.80
# VAGRANT-END: 501 b6e79ee8-05e0-4042-b64e-3fdcef77ecf8

But on Monterey is like this:

# VAGRANT-BEGIN: 501 fa0f3967-b8c6-4652-86a4-1bdfe6f65147
"/Volumes/Docs/projects" -alldirs -mapall=501:80 192.168.1.80
# VAGRANT-END: 501 fa0f3967-b8c6-4652-86a4-1bdfe6f65147

Notice that the path is no longer prefixed with /System/Volumes/Data/

I don't know why the path is no longer prefixed or if it should. The thing is that all is working again.

ionutantohi avatar Sep 05 '22 08:09 ionutantohi