Mounting NFS partitions works much the same way as mounting local partitions. The only difference is in how the partition is addressed. On local disks, partitions are addressed by their device name, such as /dev/hda1. In NFS mounts, partitions are referenced by their hostnames and export directories. Thus, if the server named ungerer is allowing your host to mount the directory /export/SL1200/MK2 and you want to mount this to /projects/topsecret1, you would use this command:

    [root@tedford /root]# mount ungerer:/export/SL1200/MK2
    /projects/topsecret1

As you can see, it’s not necessary for your local directory to have the same name as the server’s directory.

With NFS come some additional options you can use in conjunction with the mount command’s -o option, as shown in Image 7-6.

Here’s an example of an NFS mount in the /etc/fstab file:

    denon:/export/DN2000F /proj/DN2k nfs bg,intr,hard,wsize=8192,rsize=8192 0 0

Using the autofs Service

As your site grows, you’ll find that maintaining mount tables becomes increasingly complicated. You may find it appropriate to standardize on a particular set of NFS mounts for all systems to save yourself some work, but this has the side effect of wasting system resources for both the client and server. To combat this problem, you can use the autofs service, also known as the automounter. As its name implies, it automatically mounts file systems as they are needed. When it is used in conjunction with NIS (see Linux tutorial 17), you can produce a centralized set of maps that apply to your entire site, deploying the autofs service to mount only those partitions needed by users at the time they are needed. A good example of this is home directories. Say that for a variety of technical reasons, my company currently needs to allow everyone in engineering to put their home directories on their local systems rather than having them all reside on a central server. However, we want to allow anyone to be able to log in to anyone else’s system and have their home directory available to them. If we were to use /etc/fstab for this, every new person in engineering would require a lot of people to get their /etc/fstabs updated, which is bound to be an error-prone task. Even worse, having to mount several dozen home directories every time would be a waste of resources, especially if other engineers are not logging in to other people’s machines all the time. By using the autofs service in conjunction with NIS, I can maintain a very simple /etc/fstab on each host and run the autofs daemon. When someone logs in to the system, the login program will try to access her home directory. The autofs service will intercept this request, go look up where that user’s home directory is located, mount it, and then let the login process continue. The process happens so quickly the user doesn’t realize that her home directory was just dynamically mounted for her. Once the user logs off, autofs will notice that there hasn’t been any activity on that partition for a while and automatically unmount it. Neat, huh?

And of course, conveniently, all popular distributions of Linux are currently shipping with the autofs subsystem already set up, ready to accept your configuration files.

The Slightly Bigger Picture

Let’s begin by taking a closer look at the steps taken by the autofs service so that you better understand how it works. When autofs starts, it looks for a file called /etc/auto.master. This file tells it what maps it will need to read for what directory. For example, the auto.master file might contain an entry that looks like this:

    /home auto.home

This tells autofs that for any directory accessed in the /home directory, it should consult the /etc/auto.home file to find out what partition it should mount. The auto.home file is called a mapfile. Mapfiles in this context are simply text files that map user’s names to the location of their home directories. The first column of the file contains the key, which is simply the user’s login. This value is what is used to search the mapfile. rwhite orb:/export/home/rwhite In this example, rwhite is the key. Combining the two files together (auto.master and auto.home), the autofs service will do the following when someone tries to access the directory /home/rwhite:

1. Check if /home/rwhite is already mounted.

2. If not, create the directory /home/rwhite.

3. Mount orb:/export/home/rwhite to /home/rwhite.

Don’t worry if it takes you a few minutes to wrap your head around this concept—it isn’t terribly intuitive. But once you get it and see why this feature is useful, you’ll wonder how you ever managed a network without it.