Chapter 6: Automounter


The automounter is an automatic way of NFS mounting file systems on demand rather than mounting everything possible at boot time. The tables used by the automounter, describing what file systems or directories have to be mounted where, are known as maps. These are not to be confused with NIS maps, but can themselves serve as the source for NIS maps and be distributed by NIS.

The automount daemon, started at boot time on every host, reads its automounter maps and fools the kernel into thinking that those file systems are NFS mounted. The automount daemon then filters every file reference to see if there is a match between the file's directory path and one of the automounter's map entries. If there is, then the automounter will, if necessary, issue the NFS mount command with appropriate access privileges.  If no one actually does any work 'in' the automounted NFS file system for a (default) period of 5 minutes, then the automount daemon unmounts the NFS until the next reference.

If the automount daemon has to do an NFS mount it mounts the file system under its own temporary local physical file structure /tmp_mnt and then creates a symbolic link which points to the correct subdirectory of /tmp_mnt to complete the illusion. Example

/data/geophys is referenced and the automounter creates a physical local directory called /tmp_mnt/data/geophys on which it hangs (NFS mounts) the remote machines physical directory /local/data/geophys. Finally, it creates a local symbolic link, /data/geophys, which points to /tmp_mnt/data/geophys.

Solaris 2.4 ( and above) systems use a new and more flexible system, which creates mount points according to the automounter maps, thus eliminating the /tmp_mnt step), and also handles direct maps better. IRIX 6.2 has a version of autofs but unfortunately this does not handle command-line map invocation which is needed for our implementation, so the older version has to be used.

The NERC automounter mount points

In the NERC filesystem there are mount points called

/nerc ( with subdirectories bin,etc, scripts and man)

which are created by the automounter and owned by it. These correspond to the auto.nerc, auto.users, and auto.packages<arch> maps.On some sites there are also mount points


which correspond to auto.scratch, auto.working maps.

Automounter Maps

The automount daemon maps are formed from  sources living in /nerc/<domain>/yp on the NIS master, along with passwd, group and the others. They are 'made' in the same way as other maps, e.g. make auto.packagessolaris. In rare cases the maps can
be formed wholly or partly from local files, such as /etc/auto.packagessolaris.

Master Map

auto.master (or auto_master on Solaris) is the default map which the automount daemon looks for at boot time to tell it what other maps should be consulted for a given 'key'. Here 'master' has nothing to do with the NIS master but means the 'master map' for that workstation.

The following lines appear in the NERC auto.master map ( except at SOC which is different!).

# key map [mount options] (lines beginning with # are comments)

/users auto.users -rw,hard,noquota,timeo=10,intr
/data -rw,hard,noquota,timeo=10,intr
/- auto.nerc -ro,soft,noquota,timeo=10,intr

The three columns are, from the left, the key directory reference which will cause automount to search the map in the second column and make any NFS mounts using the mount options in the third column. These mount options vary from site to site and from architecture to architecture ( to a certain extent).

The first two lines are entries for indirect maps and the third line is for a direct map - see discussion below.

Note: in the present implementations of the automounter only one direct map is allowed. As the NERC system requires two, one for auto.nerc and another for auto.packages<arch>, the second is referenced in the automounter invocation file as an inline command and not included in the auto.master file where it would logically belong. See the discussion of automounter invocation at the end of this chapter.

Indirect Maps

Indirect maps hold entries for subdirectories of the 'key' directory which caused the particular indirect map to be consulted. and auto.users are indirect maps.


This relates user ids to their physical login directory location in the NIS domain.

 An example of auto.users:

#automounter map for user directories

ncs -rw wlfiles:/local77/users/ncs
ncssys -rw wlcomms:/local22/users/ncs
dr -rw wlcomms:/local22/users/dr
chem -rw wlfiles:/local22/users/chem

In the passwd file all users have home directories /users/<group>/<id> or /users/<id>. When they log on the reference to /users triggers the automounter to look in the auto.users map for the <group> or <id> key. The former method is preferred in the Southern Area, the latter in the Northern Area, but they may both occur in the same auto.users. For example, when a chemistry user 'fred' logs on, with home directory /users/chem/fred, the auto.users table directs the automounter to mount /local22/users/chem from wlfiles on the host where he has just logged in. A user 'dr' on the other hand has his own separate mount /local22/users/dr from wlcomms.

Groups can be split across disks or machines by giving them a different key; some of the ncs users have home directories /users/ncs/<id> and others have home directories /users/ncssys/<id>. When they log on the reference to /users triggers the automounter to look at the auto.users table, and then to pick up either the mount for ncs or the one for ncssys. The 'group' in /users/<group> has no relation to the UNIX GID; it is often named the same for convenience but there is no reason why /users/ncs, /users/ncs1 and /users/dr should not all have user home directories whose GID is 1000 (ncs).

This is the map which allows users to have data directories or common data areas on physical disks other than the one containing their home directory.. This map can also be used for defining spool areas. Its form is the same as for auto.users:

#automounter map for data areas

geophys -rw kwda:/local/data/geophys

The permissions on the local files would determine who could write to them; as far as the automounter is concerned they are mounted read-write.

Direct Maps

Direct maps are like wildcard entries; any map whose 'key' is defined as /- should be searched for a match of the absolute directory path being referenced if it doesn't match any indirect map's key.

 auto.master,auto.nerc and auto.packages<arch> are direct maps.


These are the maps which are architecture dependent and relate applications packages to their physical location in the NIS domain. They allow one copy of, say, SAS to be used by all the Solaris hosts on the network instead of each having its own. Third- party packages are always installed in a central place. Sometimes it is necessary to have symbolic links back to where the originator intended the package to go - these are handled by scripts called nercinstall. The architecture-dependent maps allow there to be /nerc/packages/oracle pointing to Oracle for Suns or Oracle for Silicon Graphics depending on what architecture machine you happen to be on.  The maps are 'direct' so that all packages can be 'seen' at once by 'setup' in order to show what packages are available for a given architecture. Direct maps require a little more thought when updating than Indirect ones.

Example of auto.packages<arch> map

/nerc/packages/sas -ro,hard,intr wlfiles:/local23/packages/solaris/sas


This is the link between the logical and physical /nerc directory structure. It mounts the separate directories etc, <arch>/bin , domain, and <arch>/man from the NERC filesystem master server ( usually the NIS master) onto /nerc/etc, /nerc/bin and so on. A typical auto.nerc looks like this:

# auto.nerc NIS map

/nerc/etc -ro wlcomms:/local/master/etc
/nerc/bin -ro wlcomms:/local/master/$NERCARCH/bin
/nerc/man -ro wlcomms:/local/master/$NERCARCH/man
/nerc/wallingford -ro wlcomms:/local/wallingford/domain
/nerc/scripts -ro wlcomms:/local/master/$NERCARCH/scripts


There is also a mount point called /net which is created by the automounter for direct access to any exported (made to be accessible over NFS) filesystem on any host on the network. There is no map for this. It is used as follows:

To access a directory /local22/users on wlcomms, from anywhere else on the network, type

cd /net/wlcomms/local22/users

Assuming local22, or local22/users, is available for export the directory will be mounted on /tmp_mnt/net/wlcomms/local22/users and a link made to /net/wlcomms/local22/users. This is a rather longhand method of accessing filesystems since it requires knowledge of the hostname, but as it does not require root privileges it is useful for temporary mounts.

Some mount options used in automount

ro     Read only
rw    Read write
soft   Once a read/write to a mounted file system has failed after appropriate numbers of attempts then report failure and stop trying.
hard As 'soft' but after reporting a failure keep repeating until an interrupt is received (best used with rw systems).
intr     Allows user interrupts to stop a read/write to a file system.
32bitclients Used on 64-bit IRIX systems to allow 32-bit hosts to mount filesystems from it.

Making new automounter entries effective

When a new entry has been added to an automounter map, or an existing one changed, the map should be remade with 'make' or 'ypmake'.

Check that the new or changed partition is properly exported from the host, and that mountd is running on the host.  If this is the first time a filesystem has been exported the system will need to be rebooted to start  mountd.. Note that for Solaris 2.3 and above  this applies even when the partition is on the same host where it is to be automounted.

On a Solaris 2.3 ( or above) system the automounter can be made to reread its maps by simply typing


and the new entry should be visible. If it is not, check that the old entry is not still mounted ( i.e. that if it is a package, the package supporter has logged off, or the licence manager daemon referring to it has been stopped).

On other systems, after checking that the affected entry is not being accessed, find the process ID of the automounter daemon and kill it. Restart it with the special NERC command on all architectures (except Solaris 2.3 and above):


If the new entry is in fact a change to an existing one, make sure that the affected partition is not mounted. If it is a package,
the package owner must log off, and any processes using the package such as licence manager will need to be killed.

Warning: if the system is busy at the time, particularly with older IRIX systems, it is entirely possible that it will hang. The only clean way to make a direct map change effective is to reboot the workstation. With SunOS systems running xdm the Openwindows system will be permanently mounted, so unless it is locally installed a reboot will certainly be necessary

Overriding the NIS Packages Map

The rc.local.automount script will differ from architecture to architecture too, but will in all cases contain a reference to the packages map. Usually this will be in the form

.... /- auto.packages$NERCARCH.....

which means that the packages map is obtained from the NIS master. Sometimes it is necessary to have the package map local to the host, to override the NIS one.

This happens for example on an ORACLE database server, where the server version of ORACLE is not the same as that seen by clients on the same architecture.

On a SunOS or IRIX system it is necessary to do this explicitly; in this case change /etc/rc.local.automount so that the section above reads

..../- /etc/auto.packages$NERCARCH

and copy the relevant portion of the NIS map to the local host;

ypcat auto.packagessun4 | grep sas > /etc/auto.packagessun4

and add


This will use only the specific local package and will pick up all other packages from the NIS map.

To do this permanently on an IRIX system the /etc/config/automount.options file must also be changed; SunOS startups have been changed by the NERC installation to invoke /etc/rc.local.automount so there is only one place to change.

On a Solaris system,  the changes to /etc/rc.local.automount are not necessary, as the automounter will look for a local map anyway before consulting the NIS one. The form of the local /etc/auto.packages<arch> map will however be the same.

 The automounter has to be killed and restarted before the local map comes into effect.



Advanced NIS maps

If the site is large and divides logically into several work groups, it is useful to make several sets of maps, each pertaining to a group. These must all be present in auto.master. In one case we have used a second level of hierarchy in the map key;

normally looks like

key options mount point
geophys -rw kwda:/local/data/geophys
and is referenced in auto.master as /data -rw,hard,intr and to get at the data, one needs to type cd /data/geophys but it is possible to have many maps, one for each group, specified in auto.master as /data/jrd auto.datajrd -rw,hard,intr
/data/chd auto.datachd -rw,hard,intr
/data/otd auto.dataotd -rw,hard,intr
/data/ncs auto.datancs -rw,hard,intr
and so on.

The maps themselves look much like ordinary data maps:

hydro1 -rw socserv3:/local4520/data/jrd/hydro1
hydro2 -rw socserv3:/local0/data/hydro2
mod1 -rw socserv3:/local4516/data/jrd/mod1
mod2 -rw sowhat:/local20/data/jrd/mod2
but to get to the data, if the map above is auto.datajrd, one would type
  cd /data/jrd/hydro1
Data organisation

It is sometimes useful to distinguish between data areas which are in constant flux and those which are static, for the purposes of doing backups or archives. New maps similar to have been created for this purpose, called auto.working and auto.scratch. The philosophy is that areas are almost static and are backed up infrequently, while auto.working areas are in constant use and should have incremental backups daily. Auto.scratch areas may or may not be backed up and are cleared out at regular intervals.

Any of these maps can be made hierarchical as described for, since they are indirect maps. This is not a principle that can be applied to package maps since they are direct.

Another use of data areas is to provide world-readable or world-writable areas under controlled conditions; for example in the /nerc/packages implementation of LaTeX it is necessary to provide an area for automatically created fonts generated as the system is used, and this is done by linking the area where LaTeX wants to put the fonts to a /data/fonts directory which is world writable and world readable. This protects the package directory itself which can be mounted read-only.

This page last update February 16th 1998 by