So you have an NFS server share known to be working, and you want to mount its share(s) on your Linux client machine. Here’s a summary. We’re using NFS4.

1. So we start out thinking that we have an NFS server 10.11.11.10. We verify it’s ready for connection, if we run this command from the client:
   showmount -e 10.11.11.10
   and receive one or more NFS folder shares, e.g.:
   /Media 10.11.11.0/255.255.255.0
2. We need a place to mount the share on this machine. So:
   mkdir /Media
3. Next we try it manually:
   mount -t nfs 10.11.11.10:/Media /Media

4. Now let’s make sure all of our NFS4-related services are enabled and running on the client.

sudo systemctl enable nfslockd.service
sudo systemctl start nfslockd.service
sudo systemctl enable nfs-idmapd.service
sudo systemctl start nfs-idmapd.service

4. We now make sure that permissions allow users of the client read/write access to the share. There are two problems here. The first is to make the shared folder and all contents read/writable by all designated users. The second is to make this happen across systems, i.e., from server to clients.

So first we set the shared folder and all contents chmoded g+rwXs, chgrped to a sharing-designated group, on the server side. We then create a new user group on both server and clients, perhaps named “sharedfiles”, add all selected users to that group on clients and server, make sure the GID is the same for the group name on all of the machines, and then reboot them all.

The GID is a numerical indicator for the group, which is more important to the local OS than the name of it. As part of the above we do need to make sure the GID is the same for our new user group, across all machines, or else the OSes will not recognize the equivalency. On each of them then, after the group is created, we do this:

groupmod -g 20000 sharedfiles

A list of current groups and GIDs is available here:

cat /etc/group

You’ll notice that 20000 places the new group long after all of the others in general. This is intentional, to avoid conflict with existing configurations.

5. Then we set up automount. We do this by adding the following line to the end of /etc/fstab:

10.11.11.10:/Media /Media nfs noauto,x-systemd.automount,intr,rsize=4194304,wsize=4194304,x-systemd.device-timeout=10,timeo=14,x-systemd.idle-timeout=1min 0 0

Items:

• NFS by itself is normally a very strong connection at a very low level, which means that unless an NFS mount is handled with care by other facilities, a client machine can freeze up very hard if its server becomes unreachable, rather different than SMB on Windows. There are at least three different methods to do this well. The above uses a facility within systemd, which this author found much easier to handle than the other two he found. If your Linux system does not use systemd, you should use one of the others, e.g., autofs, which is a layer unto itself.
• The option “intr” is instead of “hard” or “soft”. It makes NFS transactions explicitly interruptible, which helps prevent corruption if the server goes down.
• rsize and wsize can vary a lot. The number is in bytes. The above is a recent report on gigabit; if you’re on a lower-speed network you should use a correspondingly full order of magnitude smaller pair of numbers, e.g., the commonly reported rsize=8192,wsize8192.