vagrant
vagrant copied to clipboard
mount.nfs: access denied by server while mounting. External drive/volume. macOS 11.3
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
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
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.
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...
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!
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.
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...
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.
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.
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
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.
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 :(
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
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 thanks - that fix appears to work for me
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...
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
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 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 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.
I also tried using an external drive formatted with AFPS, and still received mount.nfs: access denied by server while mounting ...
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
is there any update on this?
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.
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 You need to click the little padlock at the bottom left in order to change the Privacy settings.
@robme For the record, the issue you had is not related to this issue.
@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.
@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.
@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
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.