Improve NFS documentation for macos mounts

[msdos]

Creating a feature request

Is your feature request related to a problem? Please describe:

• This is an improvement, not a problem.

Describe the solution you'd like:

• Since macOS uses a non standard port to connect to NFS shares and not everyone knows about this caveat it would be a nice addition to documentation in https://dietpi.com/docs/software/file_servers/#nfs about this issue. More information about this issue, with a solution and a full explanation: https://askubuntu.com/questions/952374/why-am-i-getting-permission-denied-when-connecting-to-my-nfs-share/952398#952398

Additional context

• Not exactly an issue, but a hint: I needed to provide not only the ip but the full path in macOS Finder Connect to Server feature (nfs://192.168.0.100/mnt/dietpi_userdata) to connect to DietPi nfs share. I think this can be a nice addition as well ("If connection fails, try to provide full path to common nfs shares of DietPi" or something along those lines). I needed to chmod -R 777 /mnt/dietpi_userdata as well on the server since the mount is uid/gid 1000 but on macOS is a different user. Don't know it there's a better solution to this case to be able to multiple machines on the same network to write on the nfs share.

[MichaIng]

I wonder whether the info about the insecure flag is (still) true, as I never heared of anyone having issues with macOS and NFS before. And it sounds, well "insecure" ...
EDIT: Okay seems to be true, still wondering why I never heared about it. "insecure" only refers to the port range, to allow the usage of ports >1024.

Do you face this full path issue with a fresh NFS server install via dietpi-software where fsid=0 is present in /etc/exports? This flag sets this share as root for clients and, AFAIK, is not interpreted at the client but set so at the server. So either all clients have this share with root path or none. Without this flag, it is normal that one needs to pass the full path, as long as the client does not auto-detection.

Aside of granting everyone full R/W access, you could create the same users (the same user IDs) on the server and grant them access in particular. The user ID counts: When accessing with a user from the client system to the share, on the server it has the same (filesystem) permissions as the user with the same ID on the server, or none (aside of "others" permissions), if it does not exist.