Running Linux, 5th Edition - Matthias Kalle Dalheimer [314]
Configuring Your System as an NFS Client
A few words of warning about NFS. First of all, the client is not very happy when the servers for remote filesystems go down or the network connection fails. When the NFS server is unreachable for any reason, your system prints warning messages to the console (or system logs) periodically. If this is a problem, use the standard umount command (introduced in Chapter 10) to unmount any remote filesystems offered by the affected servers.
Another detail to watch out for when mounting NFS filesystems is the user IDs (uids) and group IDs (gids) of the files on the remote filesystem. In order to access your own files via NFS, the user and group IDs for your own account must match those on the NFS server. One easy way to check this is with an ls -l listing: if the uid or gid does not match any local user, ls displays the uid/gid of files as numbers; otherwise, the user or group name is printed.
If IDs do not match, you have a few ways to remedy this problem. One is to simply change the uid of your user account (and the gid of your primary group) to match those on the NFS server (say, by editing your local /etc/passwd file). This approach requires you to chown and chgrp all your local files after making the change. Another solution is to create a separate account with matching uid/gid. However, the best approach may be to use NIS to manage your user and group databases. With this solution, you do not create your user and group accounts locally; instead, they are provided to you by an NIS server. More on this later.
Another NFS caveat is the restriction of root permissions on NFS-mounted filesystems. Unless the NFS server explicitly grants your system root access on NFS-mounted filesystems, you will not have total access to files when logged in as root on your local system. The reason for this is security: allowing unlimited root access to files on a remote-mounted NFS filesystem opens itself up to abuse, especially when the NFS server and the NFS client are maintained or owned by different people.
NFS clients can make use of exported NFS resources in a number of ways:
Automatic boot-time mounting through the /etc/fstab file
Manual mounting from a shell command line
Automated mount via the automount daemon
Discussion of the automount daemon is beyond the scope of this chapter; refer to Chapter 10 for further information. The next sections contain a simplified overview of the two other methods.
Using /etc/fstab NFS client entries
Configuring your system to mount remote filesystems over NFS is a breeze. Assuming that you have TCP/IP configured and that hostname lookup works correctly, you can simply add a line to your /etc/fstab file such as the following:
# device directory type options dump fsckorder
allison:/usr /fsys/allison/usr nfs defaults 0 0
This line is similar to fstab for partitions on a local system, but the name of the remote system appears in the first column, and the mount type is nfs. This line will cause the remote /usr on the machine allison to be mounted at boot time at the directory mount point /fsys/allison/usr.
As with regular filesystem mounts, be sure to create the mount-point directory (in this case, /fsys/allison/usr) before letting the system mount the remote directory. The line in the /etc/fstab example allows your system to mount the directory /usr from the machine allison on the network.
The mount can be specified with various options. Two commonly used options are soft and hard. The soft mounting option means that when a file access request fails, the NFS client will report an error to the process that makes the request. Some application handle that error report gracefully, and some do not. The hard mounting option means that the NFS client will hang when the NFS server ceases to respond to file access requests. You should