Now you can mount a shared NFS directory from a client computer. The commands and configuration files are similar to those used for any local filesystem. In the previous section, you configured an NFS server; for the moment, stay where you are, because computers that serve as NFS servers are also NFS clients.
Before doing anything elaborate, you should test the shared NFS directory from a Linux or Unix client computer. But first, you should check for the list of shared NFS directories. If you're on an NFS server and want to check the local list, the command is easy:
# showmount -e
If you don't see a list of shared directories, review the steps described earlier in this chapter. Make sure you've configured your /etc/exports file properly. Remember to export the shared directories. And your NFS server can't work if you haven't started the NFS daemon on your computer.
If you're on a remote NFS client computer and want to see the list of shared directories from the enterprise5 computer, run the following command:
# showmount -e enterprise5
If it doesn't work, there are three more things to check: firewalls, your /etc/hosts or DNS server, and SELinux settings. If you have a problem with your /etc/hosts or DNS server, you can substitute the IP address of the NFS server. You'll see output similar to the following:
Export list for enterprise5 /mnt/inst *
Now if you want to mount this directory locally, you'll need an empty local directory. Create a directory such as /mnt/remote if required. You can then mount the shared directory from the enterprise5 computer with the following command:
# mount -t nfs enterprise5:/mnt/inst /mnt/remote
This command mounts the /mnt/inst directory from the computer named enterprise5. This command specifies the use of the NFS protocol (-t nfs), and mounts the share on the local /mnt/remote directory. Depending on traffic on your network, this command may take a few seconds, so be patient! When it works, you'll be able to access files on /mnt/inst as if it were a local directory.
When you start NFS as a client, it adds a few new system processes, including these:
rpc.statd Tracks the status of servers, for use by rpc.lockd in recovering locks after a server crash
rpc.lockd Manages the client side of file locking; the current RHEL 5
You can also configure an NFS client to mount a remote NFS directory during the boot process, as defined in /etc/fstab. For example, the following entry in a client /etc/fstab mounts the /homenfs share from the computer named nfsserv, on the local /nfs/home directory:
## Server: Directory Mount Point Type Mount Options Dump Fsckorder nfsserv:/homenfs /nfs/home nfs soft,timeout=100 0 0
Alternatively, an automounter, such as autofs or amd, can be used to mount NFS filesystems dynamically as required by the client computer. The automounter can also unmount these remote filesystems after a period of inactivity. For more information, see Chapter 4.
Without a timeout, NFS mounts through /etc/fstab can be troublesome. For example, if the network or the NFS server is down, the lack of a timeout can hang the client. (I discussed this issue in more detail earlier in this chapter.) A hang is a big problem if it happens during the boot process, because the boot may never complete, and you would have to restore your system by booting into some runlevel where networking is not started, such as 1, single, or emergency.
NFS supports diskless clients, which are computers that do not store the operating system locally. A diskless client may use a boot floppy or a boot PROM to get started. Then embedded commands can mount the appropriate root (/) directory, swap space, set the /usr directory as read-only, and configure other shared directories such as /home in read/write mode. If your computer uses a boot PROM, you'll also need access to DHCP and TFTP servers for network and kernel information.
Red Hat Enterprise Linux includes features that support diskless clients. While not listed as part of the current Red Hat exam requirements or related course outlines, I would not be surprised to see such requirements in the future. Red Hat is working on a new tool on this subject. For more information, see the Cobbler project at http://cobbler.et.redhat.com/.
Consider using the soft option when mounting NFS filesystems. When an NFS server fails, a soft-mounted NFS filesystem will fail rather than hang. However, this risks the failure of long-running processes due to temporary network outages.
In addition, you can use the timeo option to set a timeout interval, in tenths of a second. For example, the following command would mount /nfs/home with a timeout of 30 seconds (timeo uses tenths of a second):
# mount -o soft,timeo=300 myserver:/home /nfs/home