nfsd refusing mounts after upgrading to 11.3 Big Sur?

I tried Console but as you said, its very verbose and I was unable to pick out any kernels from the chaff of all it's many messages.

I posted here as a first step before contacting Apple Support.

I appreciate that NFS is a corner case and likely little tested but as Anton has pointed out, I'm not the only one encountering this issue so hopefully it will be identified and fixed. My use is for a home Plex server so it's annoying but not life threatening & I have started looking at moving to SMB but that has it's own issue(*).

I'm downloading 11.13.1 because you never know, I might just get lucky and Apple will have fixed the issue.

Thank you and Anton for commenting. I'll look into the GitHub link after updating.

• With SMB the problem I'm seeing is that I've created a media user & shared the folder but Ubuntu want's a workgroup in addition to a username+password, "." isn't accepted and I haven"t been able to figure out what is needed yet.

There is no issue with the volume hosted by the Drobo on the MacMini. It's a 8D (not a 6D as I mistakenly said earlier) so it uses Drobo Dashboard to mount the volumes on the Drobo & I see the files on the Macmini.

The problem is that Big Sur seems to have changed something and now all mount requests are getting permission denied and I haven't been able to find any error messages from nfsd explaining why.

Normally/previously, adding the following line to /etc/exports and performing a "nfsd update" would authorize 192.168.100.55 to mount /Volumes/Drobo/Media.

/Volumes/Drobo/Media 192.168.100.55

As I stated in my first post, the client 192.168.100.55 sees that /Volumes/Drobo/Media is exported (using showmount).

Hello All,

Upgrading to 11.13.1 didn't solve anything (except the Safari vulnerabilities it corrected).

However, Etresoft's reference to the GitHub.com post did.

The Github article mentions that Apple corrected a local privilege escalation in APFS with "improved state management". This "improved state management " seems to have borked nfsd's ability to export subdirectories of all external volumes (Like my Drobo) directly - even though Drobo doesn't use APFS. The workaround is to export the volume root (/Volumes/Drobo in my case) and mount that somewhere on your NFS clients first, after which Apple's nfsd may allow you to mount subdirectories.

In my case, even though I was only exporting folders inside /Volumes/Drobo & not /Volumes/Drobo itself, everything was already mounted RO everywhere and I don't mind having the Drobo's other contents available to clients. So, I just simplified /etc/exports to just export /Volumes/Drobo, added -ro to the export options, mounted that to /Drobo on the clients and replaced /mymedia with a symlink to /Drobo/Media on the Plex VM.

People using Automount and those who only export parts of external volumes for security reasons won't be so lucky. Hopefully Anton and others seeing this will be able to work around the bug too.

Thanks for your help Anton & Etresoft!

Hi Damian,

Hopefully the workaround of exporting & using the volume root (/Volumes/Drobo fo me) is sufficient for your situation too. If not, and you check if you can mount folders inside the volume after mounting the volume root (First mount /Volumes/Drobo and then see if /Volumes/Drobo/Media) works I'm sure that confirming that it kludges around the problem would help others.

Hi Damian,

You never detailed exactly what your "shares" and your volumes are so I can't really answer. In addition, the subject is NFS so it's exports & not shares. According to the Github discussion, the mount of the volume root needs to be done before you can mount a subfolder of an external volume. According to tests I've performed, the NFS mount will only work on the external volume's root (until Apple fixes the bug).

In my case, my external volume is /Volumes/Drobo. Before this bug, I was exporting /Volumes/Drobo/Media to my Plex server and /Volumes/Drobo/Backups/_Isos to my ESXis. By only exporting specific folders & not the volume root I was limiting the files on my Drobo that are made available to NFS clients. In my case, as I said earlier, I don't really need to hide the rest of /Volumes/Drobo from my Plex server or the ESXis so I just changed my export to /Volumes/Drobo & it works on both Plex & ESXi.

There was one question I had; Once you export and mount /Volumes/Drobo, can you then mount /Volumes/Drobo/Media? The answer is no.

I just tested mounting /Volumes/Drobo (OK) and then attempted to mount /Volumes/Drobo/Media (KO) on my Plex VM. I assume that /Volumes/Drobo/Media was refused because it's not explicitly exported from the Mac. However given that /Volumes/Drobo/Media is a subset of /Volumes/Drobo the export fails with:

bash-3.2# nfsd checkexports

exports:2: /Volumes/Drobo/Media conflicts with existing export /Volumes/Drobo

You'll need to detail your exports & mounts explicitly if you want us to help you kludge around the bug.

Your volume roots are /Volumes/Backup and /Volumes/Film as you suspected.

If you change the exports from /Volumes/Backup/Film to /Volumes/Backup and then attempt to mount those on your NFS clients somewhere, you can then use a symlink to point to Film inside wherever you mounted it and make Kodi happy again.

In my case I was exporting/mounting /Volumes/Drobo/Media to /mymedia on my Plex. After exporting /Volumes/Drobo on the Mac I was able to mount it to /Drobo on the Plex. On the Plex NFS client I removed the old /mymedia mount point and created a symlink from /Drobo/Media to /mymedia so that Plex would see the files and directories in the expected /mymedia/* location . To make the symlink I used "ln -s /Drobo/Media /mymedia". You should be able to do something very similar for your two volumes.

On Plex you have to Empty trash explicitly from a volume to make missing files disappear from the index. I assume that Kodi is like Plex in that it doesn't remove temporarily absent files automatically from its databases either so unless you do so explicitly, your Kodi isn't going to delete your library.

Yeah this bug is a pain and one could wish that Apple had caught all the bugs but using obsolete and vulnerable MacOS versions is it's own larger danger. This is a pretty exceptional time for Apple updates because with Big Sur they are weeding out all the 32 bit code (which is A BIG DEAL). Future updates are extremely unlikely to see changes as big. I work in network security and am thus conscious of the severe risks you run in in not upgrading so now that you know the workaround I'd counsel against avoiding upgrades. Wait a month to let others debug, sure but don't let yourself get hacked because you're still using vulnerable MacOS versions.

[Edited by Moderator]

Ah, sorry to hear you had issues with Kodi. I can unfortunately relate, having had to rebuild my Plex library last year. It did get me to rename all my media files so that Plex would recognise them all automatically instead of having to manually re-match many files. I'd advise learning what action you took on Kodi that made the temporarily missing files a problem, to avoid future issues.

NFS is a UNIX origin protocol. MacOS uses SMB after deprecating AFS because almost everyone prefers SMB but as I've been administering Unix servers for almost 30 years & it's the best way to share files with VMWare ESXi servers, using it for my Plex was just easier.