MacOS has a built in NFS client, but the defaults in the latest MacOS versions prohibit it from working as it should. As Apple encourages the use of the SMB protocol, they seem to have stopped paying attention to NFS, which is a shame considering in the real world, NFS performance blows SMB away, especially with lots of small files. Doubly so with Samba’s implementation.
I am writing this up, as I just got myself 100TB of nice space on a Ubiquiti UNAS Pro 8. In migrating various drives of data from single drives onto the NAS, the performance has been absolutely abysmal. I logged on to the NAS, and noticed that the filesystem is mostly idle, but the samba daemon is pegged at 100%. Ubiquity did a good job of tuning it as best they can, but in doing my research, it seems the general consensus is that Samba’s small file performance is particularly bad.
Also, the UNAS is running Debian 11, which (as of the time of this writing) is two major releases behind, and a somewhat out of date version of Samba. Hopefully they will update it to a more recent version at some point.
So I decided to try using NFS instead. This is where the issue on the Mac raised its ugly head. Despite the correct settings for the export on the NAS, the Mac still obtusely refused to mount the volumes with a generic unhelpful error message. There seemed to be very little help online in any of the forums. But, after a lot of trial and error, the fix turned out to be incredibly simple, and Apple could fix it with a single configuration line.
The key NFS option you need to use on the MacOS client to make the mount successful is resvport.
To make this the default for all mounts (as it should be by default from Apple), you can add a line to /etc/nfs.conf:
nfs.client.mount.options = resvport
I also recommend using the nfc option to normalize Unicode characters. From the man page:
nfc Convert name strings to Unicode Normalization Form C (NFC) when sending them to the NFS server.
This option may be used to improve interoperability with NFS clients and servers that typically
use names in the NFC form.
Another Option Is To Use Automount
MacOS also supports the use of automount to mount volumes on demand instead of all the time. Once you have verified that you can mount a volume as above, you can configure automount to hand mounts in the future.
Edit the file /etc/auto_master and add the line
/shares /etc/auto.shares --timeout=60
This tells it to use the directory /shares and any shares defined in the file /etc/auto.shares will be mounted inside. After 60 seconds of not using the share, it will silently disconnect (but will reconnect immediately on the next access)
Create the file /etc/auto.shares and add a line similar to
MyShare -fstype=nfs,nfc,resvport,intr,async,rsize=1048576,wsize=1048576,vers=3 technonas.tek:/var/nfs/shared/MyShare
The settings for the fstype seem to work well for me, and I am getting near-wire speeds from the NAS (at least for reads). Tune it for your environment. If you are using stock linux instead of the UNAS, you can either remove the vers=3 option and let it negotiate the best connection automatically, or change it to vers=4. The UNAS (currently) only supports v3.