Hack57.Automount NFS Home Directories with autofs

Hack 57. Automount NFS Home Directories with autofs

Let users log in from any machine and be in familiar territory.

If you administer an environment that supports large numbers of users who occasionally need access to any one of a wide array of hosts on your network, you might find it a bit tiring having to answer support calls every time your users try to log into a machine only to find that their home directories are nowhere to be found. Sure, you could run over and edit the /etc/fstab file to NFS-mount the remote home directories and fix things using that machine's NFS client, but there are a couple of downsides to handling things in this way.

First, your /etc/fstab file will eventually grow quite large as you add more and more mounts. Second, if a user leaves your department, you'll be left with the choice of either dealing with failed mount requests in your logfiles (assuming you removed the user's home directory at the time of departure) or running around and editing files on all of the machines that have the entry causing the error. Which machines have the offending entry? Well, you'll just have to look, won't you? This is not a position you want to find yourself in if you maintain large labs, clusters, and testing or development environments.

One thought might be to mount a directory from an NFS server that holds the /etc/fstab file. This is asking for trouble, since this file is in charge of handling not only NFS mounts, but the mounts of your local devices (read: hard drives). In the end, you're sure to find that centralizing this file on an NFS share is impossible, since the local machine needs to mount the hard drives before it can do anything with the network, including mounting NFS shares.

A good solution is one that allows you to mount NFS shares without using /etc/fstab. Ideally, it could also mount shares dynamically, as they are requested, so that when they're not in use there aren't all of these unused directories hanging around and messing up your ls -l output. In a perfect world, we could centralize the mount configuration file and allow it to be used by all machines that need the service, so that when a user leaves, we just delete the mount from one configuration file and go on our merry way.

Happily, you can do just this with the Linux autofs daemon. The autofs daemon lives in the kernel and reads its configuration from "maps," which can be stored in local files, centralized NFS-mounted files, or directory services such as NIS or LDAP. Of course, there has to be a master configuration file to tell autofs where to find its mounting information. That file is almost always stored in /etc/auto.master. Let's have a look at a simple example configuration file:

 /.autofs file:/etc/auto.direct --timeout 300 /mnt file:/etc/auto.mnt --timeout 60 /u yp:homedirs --timeout 300 

The main purpose of this file is to let the daemon know where to create its mount points on the local system (detailed in the first column of the file), and then where to find the mounts that should live under each mount point (detailed in the second column). The rest of each line consists of mount options. In this case, the only option is a timeout, in seconds. If the mount is idle for that many seconds, it will be unmounted.

In our example configuration, starting the autofs service will create three mount points. /u is one of them, and that's where we're going to put our home directories. The data for that mount point comes from the homedirs map on our NIS server. Running ypcat homedirs shows us the following line:

 hdserv:/vol/home:users 

The server that houses all of the home directories is called hdserv. When the automounter starts up, it will read the entry in auto.master, contact the NIS server, ask for the homedirs map, get the above information back, and then contact hdserv and ask to mount /vol/home/users. (The colon in the file path above is an NIS-specific requirement. Everything under the directory named after the colon will be mounted.) If things complete successfully, everything that lives under /vol/home/users on the server will now appear under /u on the client.

Of course, we don't have to use NIS to store our mount mapswe can store them in an LDAP directory or in a plain-text file on an NFS share. Let's explore this latter option, for those who aren't working with a directory service or don't want to use their directory service for automount maps.

The first thing we'll need to alter is our auto.master file, which currently thinks that everything under /u is mounted according to NIS information. Instead, we'll now tell it to look in a file, by replacing the original /u line with this one:

 /u file:/usr/local/etc/auto.home  --timeout 300 

This tells the automounter that the file /usr/local/etc/auto.home is the authoritative source for information regarding all things mounted under the local /u directory.

In the file on my system are the following lines:

 jonesy -rw hdserv:/vol/home/users/& matt -rw hdserv:/vol/home/usrs/& 

What?! One line for every single user in my environment?! Well, no. I'm doing this to prove a point. In order to hack the automounter, we have to know what these fields mean.

The first field is called a key. The key in the first line is jonesy. Since this is a map for things to be found under /u, this first line's key specifies that this entry defines how to mount /u/jonesy on the local machine.

The second field is a list of mount options, which are pretty self-explanatory. We want all users to be able to mount their directories with read/write access (-rw).

The third field is the location field, which specifies the server from which the automounter should request the mount. In this case, our first entry says that /u/jonesy will be mounted from the server hdserv. The path on the server that will be requested is /vol/home/users/&. The ampersand is a wildcard that will be replaced in the outgoing mount request with the key. Since our key in the first line is jonesy, the location field will be transformed to a request for hdserv:/vol/home/users/jonesy.

Now for the big shortcut. There's an extra wildcard you can use in the key field, which allows you to shorten the configuration for every user's home directory to a single line that looks like this:

 * -rw hdserv:/vol/home/users/& 

The * means, for all intents and purposes, "anything." Since we already know the ampersand takes the value of the key, we can now see that, in English, this line is really saying "Whichever directory a user requests under /u, that is the key, so replace the ampersand with the key value and mount that directory from the server."

This is wonderful for two reasons. First, my configuration file is a single line. Second, as user home directories are added and removed from the system, I don't have to edit this configuration file at all. If a user requests a directory that doesn't exist, he'll get back an error. If a new directory is created on the file server, this configuration line already allows it to be mounted.