hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.
https://www.vagrantup.com
Other
26.23k stars 4.43k forks source link

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

Open ionutantohi opened 3 years ago

ionutantohi commented 3 years ago

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 commented 3 years ago

More details about this:

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

enursed commented 3 years ago

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.

unfulvio commented 3 years ago

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 commented 3 years ago

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!

ionutantohi commented 3 years ago

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.

unfulvio commented 3 years ago

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

ionutantohi commented 3 years ago

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.

unfulvio commented 3 years ago

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 commented 3 years ago

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

vadimskrotsky commented 3 years ago

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.

JmRy commented 3 years ago

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 :(

sdh100shaun commented 3 years ago

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

bluerhinos commented 3 years ago

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

sdh100shaun commented 3 years ago

@bluerhinos thanks - that fix appears to work for me

andreassp commented 3 years ago

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

kalypso63 commented 3 years ago

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

adleviton commented 3 years ago

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.

ionutantohi commented 3 years ago

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

adleviton commented 3 years ago

@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 commented 3 years ago

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

JmRy commented 3 years ago

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

kvonspiczak commented 3 years ago

is there any update on this?

robme commented 3 years ago

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.

Hailong commented 3 years ago

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 -> /

robme commented 3 years ago

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

ionutantohi commented 3 years ago

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

robme commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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
ionutantohi commented 2 years ago

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.