If you are used to later versions of Windows, you certainly know how nice it is to be able to access files on remote systems without having to explicitely mount them each time. Occassionally, I get comments from Windows fans that the lack of this feature in Linux is one of it’s major shortcoming. Well, that would be true, if Linux was missing this functionality. In fact, this feature has been available for UNIX longer than Windows NT has been around and has been with Linux from the beginning. This is called “automount” or “automounter“.

In order to be able to mount a remote filesystem using automount, you would first need to be able to mount it using normal NFS. That is to say that there are no flags that you can set on the remote side (where the filesystem is being exported) that says either to explicitly allow or deny access via automount. The remote filesystem simply makes a resource available and you access it with whatever tool you see fit. Therefore, for the purpose of this discussion, we are going to simply assume that in each case, the remote host has given us permission to access that filesystem. For more details, see the previous section on NFS configuration.

The amd program provides you with the ability to mount NFS filesystems only when you need them, automatically. They are automatically mounted by automount, hence the name. Actually, conventional NFS mounted filesystems can also be mounted automatically in the sense that you can configure them in /etc/fstab and they are automatically mounted as the system boots. Automount filesystems, on the other hand, are first mounted when a user tries to access files or directories under the mount point. Also, if the files or directories are not accessed within a specific time, (five minutes by default) they are unmounted, thereby saving network resources. When booting you could also save time since the system might be waiting to connect to a remote machine that possibly could be down.

Keep in mind that the server side is oblivious to the fact that the request is coming from automount. As far as it knows it is just your normal every day NFS mount, therefore automounter can be used with systems that don’t know about it.

The basic configuration unit with the automounter is one or more files called “maps.” These map the filesystems you want to access to the directory where you want to mount them (the mount points). These map files are fairly easy to configure and can be edited with any text editor. All automount connections are based on references in a map file.

The amd program is command-line based, so you can specify the name of the map file directly. An example map file would look like this:

/defaults opts:=rw;type=nfs jmohr_home rhost:=jmohr;rfs:=/home

The first line specifies default parameters that are used during the mount. In this case, we say that the filesystem should be read-write (opts:=rw) and of type nfs (type=nfs). The next line specifies the directories to be mounted. The syntax for these lines is:

directory rhost:=<remote_host>;rfs:=<remote_filesystem>

where directory is the name of the directory on the local machine where the filesystem should be mounted, <remote_host> is the name of the machine from which you are mounting the filesystem and <remote_filesystem> is the name of the remote filesystem.

To start amd the general syntax is:

/usr/sbin/amd -a <temp_dir> — /<real_dir> <map_file>

Here, <temp_dir> is the name of a temporary directory where the remote filesystems are actually mounted. This directory is created by amd and should be removed if you start amd automatically through the rc scripts. A common convention is to define this directory as /amd. The two dashes (–) is a common construct and tell amd that there are no more option to process. The /<real_dir> indicates the directory where the users will see the filesystems mounted. Finally, <map_file> is the name of the map file where amd should get its configuration information.

To run amd using the example configuration file, we might start it like this:

/usr/sbin/amd -a /amd — /usr/jmohr/homes /etc/amd.junior

Here we mount the remote filesystems under /amd and the users see them under /usr/jmohr/homes. So, if my home directory on junior was /usr/jmohr/homes/jimmo every time I log into junior, amd kicks in and mounts the /home directory from jmohr.

Don’t think of automount as your only means of mounting NFS filesystem just because of it’s advantages. If you are constantly accessing certain filesystems, then you gain nothing by making them automounted. In fact, you might lose something since each time the connection is made, you need to wait. If mounted in the conventional manner, then you only need to wait once. If you have filesystems that are accessed regularly, but others that are accessed only on occasion, you simply mount some at boot and the rest via automount.

A common use of automount is with NIS. NIS is used to distribute configuration files from the NIS server across the net to the NIS clients. Why not include the automount maps in the set of files that is being distributed? This could be useful if you wanted to have all the documentation on a single machine to save space and access to the doc is made through automount. Since doc is not being constantly access, this saves the problem of having the filesystem containing the doc be continually mounted.

Another use is when you want each user to have the same home directory no matter where they are. Something similar to what we had in the example above. If mounted by automount and distributed via NIS, every time they logged in, no matter on what machine, they would have the same home directory. Granted, there is the problem of not being able to access their home directory if the server is down. However, the problem of not being able to access the home directory still applies when login into a single machine. For example, if the home directory was on a filesystem that wasn’t mounted.

In reality, automount behaves very similarly to traditional NFS mounts. The system knows that the specified directory is an NFS mount point. When something is accesses on the other side of the mount point, the automount daemon reacts to the request basically the same way nfsd does with a normal NFS filesystem. The automount daemon then checks the mount table (/etc/mnttab) to see if the filesystem is already mounted and mounts it if it isn’t. Once the file system is mounted, requests are handled normally.

Like other filesystems, an entry is maintained in the system mount table (/etc/mnttab) for all filesystem that have been mounted with automounter. When the timeout has expired (five minutes by default), automounter removes the entry from /etc/mnttab, but still maintains a copy in its memory. This copy is updated whenever mounting or unmounting a filesystem.

The version of amd that I installed with Caldera OpenLinux has some really nifty features. (These feature may be available in other releases, I just didn’t test them). The most exciting feature for me required me to reconsider what amd was there for.

I had always used amd (as well as the automounter of other UNIXes) to automatically mount files systems from other machines. That is, mounting them via NFS. On the surface, one thinks of UNIX system administrators as being lazy. They spend all day trying to get out of work. That is, they develop programs that save them work. Never mind that the work that is saved is much less than the work that they invested in trying to save that work.

This is not a bad thing, for two reasons. First, the mentality of most UNIX administrators is that this really isn’t an attempt to get out work. There should be a better way of doing something, so they set out to find it. Just like the great inventors and explorers of the past, they try it because “it’s there.”

The reason that this is not a bad thing is because like other kinds of inventions, the results are there for others. Once the program exists, then other administrators can use it. In keeping with the Linux mentality, you create a program that _you_ want to write, share it with others and they share theirs with you. You now have an entire tool chest of utilities that didn’t exist a year ago.

So, what does this have to do with amd? Well, how often have you wanted to access a floppy, CD-ROM or DOS partition on your machine? First, you need to find the device that it’s on, then find a place to mount it and then finally you get around to mounting it. Wouldn’t it be nice if you could access these filesystem without having to go through all of this? You can!

That’s the nice thing about amd. You can use it to mount all sorts of filesystems, including those on floppy, CD-ROMs and DOS partitions. In fact, that’s what I did. I have a handful of applications that do not run under VMWare, so I am forced to switch to Windows 95 when I want to run them. Therefore, I cannot make my entire system Linux. Often, I need to transfer data from one system to other. That means finding the device that it’s on, then finding a place to mount it and then finally getting around to mounting it.

What a waste of time!

I noticed that amd was running on my system, using the configuration file /etc/amd.localdev. Seeing that I thought, “localdev? local devices? Hmmm….” Checking in this file, I discovered that you can, in fact, mount local filesystem via amd. So, let’s take a look at the file that had on my system:

# /etc/amd.localdev : automounter map for local devices # Don’t forget to unmount floppies with “amq -u /auto/floppy” before # ejecting them, especially when they are mounted read-write !!! /defaults opts:=nodev,nosuid,ro;dev:=/dev/${key};type:=msdos; # floppy -dev:=/dev/fd0;type:=msdos opts:=rw opts:=ro floppy dev:=/dev/fd0;type:=msdos; # floppy95 -dev:=/dev/fd0;type:=vfat; opts:=rw opts:=ro floppy95 dev:=/dev/fd0;type:=vfat; cdrom type:=iso9660 c_drive dev:=/dev/sda1;type:=vfat; opts=rw d_drive dev:=/dev/sda5;type:=vfat; opts=rw e_drive dev:=/dev/sdb1;type:=vfat; opts=rw f_drive dev:=/dev/sdb5;type:=vfat; opts=rw g_drive dev:=/dev/sdb6;type:=vfat; opts=rw h_drive dev:=/dev/sdb7;type:=vfat; opts=rw * dev:=/dev/${key}

In principle the options are the similar to those for the fstab and exports files. I leave it to you to check amd(8) man-page for the details.

The thing I want to first point out is the last line:

* dev:=/dev/${key}

As one might guess from the asterisk, this is a wild card and represents every filesystem that we have not specified previously. Since we did not specify any options, the options used are those in the /default line. The nifty part of this is the ${key} part of the device name. This is translated to mean the name of the sub-directory under /auto. For example, my C: drive is /dev/sda1. If I did cd /auto/sda1, amd would see the name of the sub-directory as sda1, then it would look for a matching device. Since it finds one, it can mount that device. Therefore, if you have mountable filesystem, you do *not* need to explicitely define them.

In this file are two lines for floppies (floppy and floppy95). The type of filesystem in the first line is msdos and this second is vfat, which allows you to mount a floppy and still have access to the long filenames. The next line is one for a cdrom. These were the lines that were originally in my amd.localdev file.

When you start amd, you tell it the name of where it should mount these filesystems. By default, on my system, this is the directory, /auto. So, when I do a cd /auto/cdrom, the cdrom is automatically mounted and I find myself in the root directory of the cdrom without going through the hassle of mounting it first.

Once I discovered this, I add the lines that look like this:

c_drive dev:=/dev/sda1;type:=vfat; opts=rw

As you might guess, this automatically mounts my DOS filesystems. I originally had them all in /etc/fstab, so they would automatically mount at boot up. Since I only use them occasionally, this didn’t make sense. I changed the entries so that they weren’t mounted automatically, all I had to do was run “mount /dev/sda1! (or whatever) and they were mounted.

Note in this case that the filesystem type is actually VFAT, and not the standard DOS FAT filesystem. Now, when I do cd /auto/c_drive, I find myself on the C: drive of my Windows 95 system. (/dev/sda1) When I do cd /auto/g_drive, I am then on the G: drive.

Being a normal Linux system administrator, this was too much for me. Not that the work was too much, I had too many entries in there that were basically all the same. In essence, the default behavior that I wanted was that I would cd into a directory under /auto and I would be on one of my Windows 95 drives. Therefore, I could change the /default like to look like this:

/defaults opts:=nodev,nosuid;dev:=/dev/${key};type:=vfat;

Note that I not only changed the filesystem type to vfat, but I also removed the options to say that this was a read-only filesystem (ro). Now when I do a cd /auto/sda1 I am on the C: drive or /auto/sdb6 I am on the G: drive.

Hmmmm. How do I know that /dev/sdb6 is the G: drive? Trying to figure that out each time is as much work as mounting it by hand. (Well, not quite.) To save me some work, I simply created a handful on links in /dev that look like this:

lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/c_drive -> sda1 lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/d_drive -> sda5 lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/e_drive -> sdb1 lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/f_drive -> sdb5 lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/g_drive -> sdb6 lrwxrwxrwx 1 root root 4 Jan 26 10:46 /dev/h_drive -> sdb7

Now, I all need to do is cd /auto/g_drive and I end up on the right drive.

One might ask what advantage this has over traditional mounts via /etc/fstab. When dealing with NFS mounts across the network, there is the issue of bandwidth and the problems that occur when the server side goes down. Since you are accessing a local drive, there are no issues of bandwidth and if the server goes down, the client goes with it.

Well, that last part is the point. If I only need to access the filesystem for a short time, it is safer to umount when I am done. By using amd, I don’t need to worry about forgetting it. After specific period of time (default: 5 minutes), the system will unmount any unused filesystems.

/etc/amd.localAutomount configuration file for local devices
/etc/exportsNFS files systems being exported
/usr/sbin/rpc.portmapPortmapper. Converts DARPA ports to RPC program number.
/usr/sbin/rpc.mountdNFS mount request server.
/usr/sbin/rpc.nfsdNFS daemon to handle client requests.
/usr/sbin/amdThe automount program.
/usr/sbin/rpc.rusersdNetwork user name server.
/usr/sbin/rpc.rwalldNetwork wall server.
/usr/bin/rpcinfoReports RPC information.
/usr/bin/rusersReports information on network users.
/usr/bin/rwallWrite to all users on the network.
/usr/bin/showmountShows information on remotely mounted filesystems.