################################################ # # # ## ## ###### ####### ## ## ## ## ## # # ## ## ## ## ## ### ## ## ## ## # # ## ## ## ## #### ## ## ## ## # # ## ## ###### ###### ## ## ## ## ### # # ## ## ## ## ## #### ## ## ## # # ## ## ## ## ## ## ### ## ## ## # # ####### ###### ####### ## ## ## ## ## # # # ################################################ The following paper was originally published in the Proceedings of the USENIX Summer 1993 Technical Conference Cincinnati, Ohio June 21-25, 1993 For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: office@usenix.org 4. WWW URL: https://www.usenix.org The Autofs Automounter Brent Callaghan, Satinder Singh SunSoft Inc. Abstract Prior to the introduction of the automounter in 1987, NFS mounts were administered separately on each workstation. The automounter has provided administrators with a tool to construct a filesystem namespace that can be shared across an organization. While the automounter is widely used, its success has been tempered by problems inherent in its implementation. This paper describes a new implementation of the automounter based on a new filesystem. This new automounter not only fixes the problems, but provides some interesting opportunities for future development. 1.0 Introduction An automounter is a service that automatically mounts filesystems upon reference. This service is particularly useful for accessing NFS filesystems. An automounter automatically mounts filesystems without requiring the workstation user to become superuser and use the mount command. To a user, all filesystems appear to be immediately, and con- tinuously available. There are two automounters in wide use. The first to become available was the automounter in SunOS 4.0. This auto- mounter is available to ONC licensees and is available in many Unix system platforms including those from Sun, IBM, DEC, HP and SGI. The Amd automounter is included in BSD 4.4 and has been ported to almost every Unix system. While these automounters have different command and map syntax, they share a fundamental property: they are implemented as NFS servers [2, 5, 6]. The server is a daemon process on the client that is NFS mounted at directories where its services are required. At each mountpoint the kernel communicates with daemon just as it would with a remote NFS server to the extent that it will print "server not responding" messages if the daemon is busy or dies. The daemon receives NFS messages from the kernel for any filesystem activity directed at these mountpoints. This allows the daemon to interpose its services [1]. Each mountpoint is associated with a map that determines what names appear under the directory and describes the filesystems they correspond to. On receiving a request for a filesystem that is not yet mounted, the daemon uses the map information to mount the filesystems in another directory (/tmp_mnt or /a) and returns a symbolic link to this mountpoint in response to the NFS request. While the filesystem is mounted continues to return the symbolic link in response to NFS requests. After a period of inactivity, the daemon can choose to unmount the filesystem. It is beyond the scope of this paper to describe all automounter features or the syntax of its maps. Please refer to references [1 - 6] at the end of the paper for this information. 1.1. Problems While implementing an automounter as an NFS service is an attractive way to provide a valuable service without requiring any kernel changes, it, this presents some serious problems: Symbolic links A single automount daemon can service many mountpoints. At each mountpoint the daemon associates a map, and emulates either a symbolic link (direct map) or a directory of symbolic links (indirect map). The symbolic links point to a directory where the automounter performs NFS mounts - /tmp_mnt or /a. The automounter unmounts what it considers to be "idle" mounts - those that have not been active - or that can be unmounted (not busy). As long as all references to these mounts are made through the daemon mountpoint, the dae- mon can replace the mounts as necessary. However, if a process invokes the getwd() function to obtain the path of the current directory while in an automounted filesystem, it will obtain a "/tmp_mnt/..." path. If this "back door" path is cached and used sometime later, there is no guarantee that the filesystem will still be mounted there. The automounter cannot detect references to empty mount- points unless they are made through the automounter's mountpoint. A common victim of this behavior is the at com- mand. It uses the pwd command to record the current directory so that it can be cd'ed to for subsequent invocation of the script. The symbolic links also confuse users because "/tmp_mnt" frequently appears as a prefix to the current directory. Various workarounds have been proposed for this problem. The most common was for the getwd() function to strip prepended "/tmp_mnt/" from paths. This workaround didn't take into account the effect of the automounter's -M flag that allowed users to specify a directory other than "/tmp_mnt/". It is also questionable whether the semantics of getwd() should be changed this way. The symbolic links present a problem for relative references between separate automounter mounts. For instance given the two directories /home/bob and /home/carol it seems reasonable that Bob should be able to "cd ../carol" but this will fail if Carol's directory isn't already mounted. Adding Automounter Mountpoints The set of automounted mountpoints can be specified only when the automounter is started. If a new mountpoint is added to the master map, the automount daemon must be killed and restarted.The automounter can be terminated with a SIGTERM signal. It catches this signal, attempts to unmount itself from its mountpoints and also to unmount mounts in /tmp_mnt. If all these unmount attempts succeed, then restart is possible. However, this interruption in auto- mounter service is very disruptive. Performance A pathname that passes through an automounter mountpoint prompts the kernel to contact the automounter and retrieve the symbolic link that points into "/tmp_mnt/". While these symbolic links are returned more quickly than they would be from a remote NFS server, there is still considerable overhead in generating remote procedure calls and context switching between the kernel and automounter. Multiple Threads The automounter daemon is single-threaded. While performing a mount for one process, other processes must wait until the mounting task is complete. As an RPC client, the automounter is subject to network timeouts that may deny service to all processes for inconvenient periods of time that users perceive as a "hang". A single-threaded auto- mounter is also prone to deadlock. If in servicing a mount request the daemon or a child process stumbles into another automounter mountpoint then deadlock is certain. Much code in the current automounter is devoted to detecting and avoiding simple deadlock situations. The Amd automounter provides higher availability by forking mount attempts and by using it's own asynchronous RPC's. Since fork is a heavyweight operation, it exacts a price in performance. Asynchronous RPC's provide a way to avoid blocking on explicit RPC calls, but synchronous RPC calls embedded in system libraries are still a risk. 1.2. In-place Mounting Several of these problems could be fixed by having the daemon perform mounts at the point of reference instead of using a symbolic link to redirect references to another mountpoint. Without the symbolic links, there would be no "back door" path and performance would improve since the daemon would not need to service requests for the sym- bolic links while the filesystem is mounted. We examined this alternative implementation, but could not resolve a serious deadlock problem. Any filesystem operation on a directory that requires the daemon to perform a mount must be blocked until the mount is complete - but in order to perform a mount the daemon risks blocking at the same direc- tory. We could not think of a way around this problem within the context of the daemon as an NFS server. The remaining sections describe our re-implementation of the ONC automounter based on a new kernel virtual file- system. 2.0 The Autofs Filesystem The autofs is a virtual file system [8] (VFS) that supports automounting with the support of an external daemon. Since it is required to support only a small subset of VFS operations, it is a minimal VFS. The autofs filesystem intercepts requests to access directories that are not present and calls an external daemon auto- mountd to mount the requested directory. The automountd locates the filesystem, mounts it within the autofs and replies. On receiving the reply, the autofs allows the blocked request to proceed. Subsequent references to the mount are redirected by the autofs - no further participation is required by the automountd. 2.1. An Autofs Mount The automount command adopts a new role of mounting and unmounting autofs mounts. The automountd daemon is completely independent. The automount command reads the master map auto_master that contains a list of the autofs mounts. It compares this list with the list of autofs mounts from the list of mounted filesystems in /etc/- mnttab and adds or deletes autofs mounts as necessary. It will also remount existing autofs mounts if mount infor- mation has changed e.g. the name of the map or the default mount options. An autofs mount requires the following information: 1. The name of the map to be associated with the mountpoint, e.g. the autofs mount on /home uses a map called "auto_home". 2. The address of the user-level daemon for remote procedure calls. 3. An indication as to whether the automatic mounting is to be direct - or indirect. 4. Default options to be used for mounting e.g.ro,nosuid An autofs mount appears in the mount table with a filesystem type of "autofs" e.g. auto_home /home autofs ignore,indirect 2.2. Automatic Mounting The autofs maintains an illusion of continuously available filesystems. When it receives a request to access a non- present filesystem through a getattr or lookup operation, it calls the automountd which mounts the requested filesys- tem. Upon receiving a successful reply the autofs directs the getattr or lookup to the new mount. While the mount is in place, further accesses are directed to the new mount without contacting the daemon. The autofs supports the notion of direct and indirect mounts implemented by the old automounter. 2.3. Direct Mounts This is the simplest and most intuitive form of automatic mount. With zero offset (see section 2.5. ) daemon mounts overlay the autofs mountpoint. On receiving a request to access its mountpoint, the autofs calls the automountd giving its path and a direct map name, e.g. /usr/man server:/export/man The daemon mounts over the autofs mountpoint and replies. On receiving the reply, the autofs redirects the blocked request to the new mount. When the mount is unmounted, the autofs mount is exposed again. 2.4. Indirect Mounts At an indirect mountpoint the autofs provides a directory of automatic mounts. On receiving a request to lookup a name in this directory, the autofs calls the automountd with the subdirectory name and map name, e.g. brent server:/export/home/brent The daemon looks up the name in the map, mounts the corresponding filesystem and replies to the autofs which redi- rects the blocked request to the new mount. While the filesystem is mounted accesses are directed by autofs to the mountpoint - communication with the daemon is not required. A readdir request on the autofs directory will return only a list of existing mounts. The names of potential mounts cannot not be displayed. This restriction prevents unintentional mounts e.g. "ls -l /home/*" would otherwise cause every home directory to be mounted. This requirement continues to be an obstacle for file browsers. 2.5. Offset Mounts The automountd may need to mount several directory levels below the direct or indirect mountpoint. In this case the mount is offset by some number of directory levels from the directory that triggered the automatic mount. The autofs is required to provide as many directory levels as necessary to account for the offset. For example: assume the follow- ing automount map entry: kinky /usr/local/bin kinky:/usr/local/bin If used with an indirect mountpoint of /net then /net/kinky/usr/local/bin would refer to kinky:/usr/local/bin. The mount is on /net/kinky/usr/local/bin. It requires that the autofs provide the directories along the path kinky/usr/local/- bin/. Offset mounts may be required for direct or indirect mounts. The automountd is responsible for constructing the required directories within the autofs filesystem. The autofs supports the mkdir, rmdir, lookup, and getattr opera- tions to allow creation of these offset paths. 2.6. Multiple Mounts To satisfy a mount request, the daemon may need to mount more than one filesystem. A common example of this is the automounter's /net facility. It attempts to mount all the exported filesystems from a server when /net/servername is referenced. The daemon may be quite busy building offset paths and doing mounts before it responds to the autofs request. Note that some of these mounts may be hierarchically related - one within the other. 2.7. Deadlock Issues The autofs is required to block access to absent filesystems until the required mounts are completed by the auto- mountd. The automountd signals completion with its reply. In order to satisfy an autofs request, the automountd may be required to make directories and perform mounts within the autofs without itself being blocked. The autofs must not block requests from the daemon. How does the autofs identify requests that should not be blocked? The automountd modifies pathnames by appending a space. This space acts as a flag to the autofs indicating that the request should not be blocked. This solution satisfies the requirements in the previous paragraph. The trailing space on the name of a mountpoint is invisible in /etc/mnttab entries since it is parsed as whitespace. The following scenario demonstrates this process: 1. A process attempts to look up the path /net/terra/export/ws/usr/src/uts 2. The autofs mount at /net intercepts the lookup of terra and passes it on to the automountd as a mount request. 3. The automountd looks up terra in the hosts map and finds through the mount protocol that terra exports "/usr", and "/export/ws". Thus two mounts are required on the client. 4. For each mount the daemon performs a mkdir to create the required mountpoint and invokes the NFS mount pro- gram to perform the mount, e.g. (underscore represents a trailing space) mkdir /net/terra/usr_ mount /net/terra/usr_ mkdir /net/terra/export/ws_ mount /net/terra/export/ws_ Any process that uses a path that passes through /net/terra without a trailing space will be blocked by the autofs at /net/terra until the mounts are complete. 5. The daemon responds to the autofs that the mounts were successful. 6. The autofs unblocks the process(es) at /net/terra and allows lookups to proceed into the new mounts. With these "special" paths, blockage avoidance is inherited from the daemon by a delegated mount or unmount pro- cess. It is also a capability that is unique to each thread within the daemon if deadlock between threads via access to other autofs mountpoints is to be avoided. A similar process occurs for unmounting described in section 3.3. Although this solution to the deadlock problem is inelegant, in practice it works very well. Space terminated paths are not well supported by Unix and are generally not used. The space terminated path is significant only while a mount- ing operation is in progress. 2.8. Performance Improvement Since it takes time to perform a mount, the first access to any automounted filesystem will take slightly longer if the filesystem is not already mounted. NFS-based automounters impose an additional naming overhead while the system is mounted since the kernel must request a symbolic link from the automountd daemon to locate the filesystem in the /tmp_mnt directory. This daemon involvement through symbolic links incurs an overhead in kernel/usr context switching and data movement. Since the autofs automounter does its mounts in-place, the daemon is involved only when a filesystem needs to be mounted. Once it is mounted paths to the filesystem can be evaluated entirely within the kernel - the daemon is not required. This provides a performance improvement for naming operations. Evaluating a stat system call 10,000 times with a path that traverses an automounter mountpoint shows a significant improvement in elapsed time. Automounter NFS based Autofs based Clock Time (sec) 32.9 1.8 System Time (sec) 17.0 1.5 3.0 The Automountd The autofs is a very simple filesystem. It exists only to catch references to filesystems and provide a directory struc- ture in which mounts can be made. The bulk of the automounter implementation remains in the automount daemon. This section describes the features of the automount daemon. 3.1. The RPC Protocol The autofs uses a simple RPC protocol to communicate with the automountd. The protocol has two procedures: mount - to look up a name and perform mounts, and unmount - to request a set of filesystems be unmounted. The mount procedure conveys the following information to the daemon: 1. The name to be looked up. To the daemon this is just a simple string. In the case of a direct mount the string is the pathname of the autofs mountpoint e.g. "/usr/man". For an indirect mount it is the name of a directory entry e.g. "brent". 2. The map name, e.g. "auto_home". 3. Default mount options. A string of mount options that will be used for the mount - unless overridden by mount options provided in the map entry. 4. The path of the autofs mount, e.g. "/home". The response to this call is just an integer. If zero it indicates success (one or more mounts were done) - otherwise failure and the value is an errno (no such name in map, or mount unsuccessful). The unmount call conveys a linked list of device identifiers to the daemon. These correspond to filesystems to be unmounted. Unmount also responds with a simple integer to indicate success or failure. 3.2. Statelessness The daemon requires no preexisting information in order to service a mount or unmount request. All the information it needs is contained in the mount or unmount request from the kernel. A stateless daemon can be killed/restarted with no net loss in quality of service. This was a useful feature during development when we frequently killed the daemon and started a new version. Another feature of this statelessness is that the daemon need not be notified of changes in autofs mountpoints or maps. 3.3. Auto Unmounting To avoid an ever-increasing number of mounts, periodic unmounting is required. An unmount thread in the autofs checks the autofs mounts every 5 minutes. Filesystems that have not been referenced for 5 minutes are candidates for unmounting. Since there is no reliable way of knowing whether a filesystem is busy, the unmount thread sends an unmount request to the automountd with a list of the filesystem device identifiers that correspond to filesystems com- prising a mounted hierarchy. The daemon attempts to unmount each of the filesystems and if any unmount fails because the filesystem is busy, the daemon remounts any prior successfully unmounted filesystems and responds with a failure notification to the unmount thread in the kernel. The unmount thread will retry the unmount later. 3.4. Safe Unmounting The automounter has the ability to treat multiple mounts as a single unit. Several filesystems can be mounted and unmounted together. The mounts may be hierarchical. To unmount a hierarchy of mounts the automounter starts at the deepest mounts in the hierarchy and proceeds upward toward the root - since a filesystem with a sub-mount cannot be unmounted until the sub-mount is first unmounted. If any of the unmounts fails the automounter is required to remount any sub-mounts that succeeded and restore the hier- archy to its original state. This procedure is unsafe because a process working within the hierarchy may choose an inopportune moment to reference one of the filesystems that is temporarily unmounted and fail with a missing file error. In a future implementation of the autofs we would like to add a new VFS operation that can be used to check whether the filesystem is busy - without attempting an unmount. At the root of each mount hierarchy it must first block access to lookups to prevent processes from entering a hierarchy during the activity check. After determining which filesys- tems comprise the hierarchy, the unmount thread would call VFS_BUSY to obtain a count of active references to the filesystem. If the reference count is equal to the number of immediate sub-mounts then the filesystem could be con- sidered to be "not busy". If all filesystems in the hierarchy were "not busy" the autofs could send an unmount mes- sage to the daemon containing the filesystem identifiers for the filesystems to be unmounted. Since there is a guarantee that there are no open files or active processes in the hierarchy, this unmounting procedure would be safe. 3.5. Local Mounts The old automounter took the opportunity to "cheat" and point its symbolic links at existing mounts whenever it could. If, in a map entry, the automounter noticed that the server name was the same as its local host, then it would point its symbolic link at the indicated local directory. Since an autofs-based automounter doesn't use symbolic links, it needs to reference local directories some other way. The automountd uses a loopback mount (lofs) to do this. Unlike a symbolic link loopback mounts are much less visi- ble and can be evaluated more quickly than a symbolic link. 3.6. Filesystem Independence The old automounter could mount only NFS filesystems. The autofs automounter can mount any kind of filesystem. Two changes to the map syntax were required to support this: 1. A new mount option fstype was provided to allow the filesystem type to be given. If the option is not given then "nfs" is assumed as the filesystem type. 2. The previously the map syntax now assumed that mount information took the NFS-specific form server:/path. Filesystem type-specific information can now be any string, though due to avoid map parser ambiguity a string that begins with a slash must be escaped with a colon to distinguish it from a mountpoint specification, e.g. cdrom -fstype=hsfs,ro :/dev/sr0 This provides the automounter with enough information to invoke the filesystem-specific mount command e.g. given an fstype of "hsfs" the automounter will execute the command "/usr/lib/fs/hsfs/mount" passing the mount options (with "fstype=hsfs" removed) and the device path following the colon. 3.7. Executable Maps Given a name, the automounter locates the required mount information by lookup in a name service (NIS or NIS+) or by searching an ASCII file. A more dynamic name-to-location mapping is provided by an executable map. If the map is a local file and has its execute bit set, then the automounter will popen the file (execute it) and provide the name to be looked up as an argument. The output on stdout is taken as the content of the map entry. The following executable map duplicates the functionality of the -hosts map that we normally use under /net. It takes a server name as an argument and returns a map entry that mounts all the exported filesystems from the server. #!/bin/sh SERVER=$1 # If it's our own host just do a # loopback mount of the root if [ `uname -n` = $SERVER ]; then echo "-fstype=lofs :/" exit fi # Get the server's export list, turn it into # a map entry, and sort it so the mounts are # done in the right order showmount -e $SERVER | awk `NR > 1 {print $1"\t'$SERVER':"$1 " \\"}' | sort The next script provides a name space that can be used to locate an entry in any NIS automounter map. It takes a name of the form key.mapname e.g. /nis/brent.auto.home is a path to my home directory. #!/bin/ksh # Parses names of the form key.nismap KEY=${1%%.*} MAP=${1#*.} /usr/bin/ypmatch $KEY $MAP | sed "s/&/$KEY/g" The sed substitution for "&" is required here to substitute the parsed key since the automounter's substitution would insert the entire key used for the lookup. 4.0 Hierarchical Autofs Mounts Since the autofs daemon can mount any type of filesystem, an automount map may contain entries that mount autofs filesystems. The maps that correspond to these autofs mounts may contain entries that refer to additional autofs mounts. This is best explained with an example. Assume that an organization comprising many departments wishes to organize a shared namespace under a "/org" directory that is visible to all users. Each department separately admin- isters its own automounter map for its portion of the namespace. The master map needs just a single entry for /org. # Directory Map Name /org auto_org The auto_org map looks like this: finance -fstype=autofs auto_finance marketing -fstype=autofs auto_marketing legal -fstype=autofs auto_legal research -fstype=research auto_research eng -fstype=autofs auto_eng and the engineering department's map "auto_eng" looks like this: releases bigiron:/export/releases tools mickey,minnie:/export/tools source -fstype=autofs auto_eng_source projects -fstype=autofs auto_eng_projects This map structure would be of interest only to administrators. A user interested in the "blackhole" project within engineering might use the path: /org/eng/projects/blackhole Beginning with the autofs mount at /org, the evaluation of this path would dynamically create additional autofs mounts at /org/eng and /org/eng/projects. Since the autofs mounts are created only when needed, changes to maps require no action to become visible at the user's workstation. The automount command needs to be run only when changes are made to the master map, or to a direct map. Hierarchical autofs mounts provide a framework within which large shared filesystem namespaces can be organized. Together with a name service like NIS+ [7] that supports information sharing across administrative domains, the maintenance of the shared namespace can be effectively decentralized. 5.0 Summary The autofs provides the kernel support necessary for automatic mounting. It is easier to use, more efficient, more robust, and more flexible than the current user-level NFS server implementation. The autofs automounter is com- pletely compatible with existing automounter maps. Acknowledgments Chris Silveri is responsible for the concept of a kernel-based filesystem to support automatic mounting. References [1] B.N. Bershad and C.B. Pinkerton, "Watchdogs - Extending the UNIX File System", Winter 1988 Usenix Conference Proceedings. [2] Brent Callaghan, Tom Lyon. "The Automounter", Winter 1989 Usenix Conference Proceedings. [3] Brent Callaghan. "The Automounter - Using it Effectively", 1990 Sun User Group Conference Pro- ceedings. [4] Brent Callaghan, "The Automounter - Solaris 2.0 and Beyond", 1992 Sun User Group Conference Proceedings. [5] Jan-Simon Pendry, "Amd - An Automounter", Technical Report, Department of Computing, Imperial College, London, England, 1989. [6] Ron Minnich, "The AutoCacher: A File Cache Which Operates at the NFS Level", Winter 1993 Usenix Conference Proceedings. [7] Chuck McManis, "Naming Systems: A Replacement for NIS", September 1991 Sun UK User Group Conference Proceedings. [8] S.R. Kleiman, Vnodes: An Architecture for Multiple File System Types in Sun UNIX", Summer 1986 Usenix Conference Proceedings. Author Information Before coming to SunSoft, Brent Callaghan worked for 6 years as a system programmer at the University of Auckland, New Zealand, and two years as a contractor at AT&T Information Systems in Lincroft, New Jersey. For 6 years he has worked on a variety of projects within the NFS group at Sun with an emphasis on automounting. His E-mail address is brent@eng.sun.com. Satinder Singh is a Member of Technical Staff at Sun Microsystems. He holds a Bachelors degree in mechanical Engineering from Banaras Hindu University, India and a Masters in Computer Science from Stanford University. His E-mail address is satinder@eng.sun.com. Figure 1. The smiley face represents a mountpoint of the automounter's daemon. Beneath this mount- point the automounter maintains a directory of sym- bolic links that point to NFS mounts beneath the /tmp_mnt directory. On receiving a lookup for a link which does not exist, the automounter consults the indirect map associated with the directory and uses the information from the map entry do to an NFS mount in /tmp_mnt. Figure 3. The automount command is used to keep autofs mounts syn- chronized with the master map, adding, deleting or modifying au- tofs mounts as necessary. At system start-up the command is run to cre- ate the initial set of autofs mounts. The command can be run anytime thereafter to reflect modifications to the master map. Figure 4. Direct mounts. A direct mount with no offset (see section 2.5. ) overlays the autofs mountpoint. This appears in the system mount table (/etc/mnttab) as two mounts at the same directory. These mounts must be performed with an "overlay" flag to override a SVID re- quirement that mounts cannot be stacked. Figure 5. Indirect mounts. The autofs filesystem is required to support a di- rectory of mountpoints. A readdir re- quest will show just filesystems that are already mounted. A lookup request for a name that is not in the directory but is in the map will cause the name to be added to the directory when the mount is complete. Figure 6. An offset mount requires one or more directories be created within the autofs filesystem to cre- ate a path to the mountpoint. Figure 7. Several filesystems may need to be mounted as a hierarchy. The automount dae- mon creates the offset paths as necessary to construct mountpoints within the autofs file- system. The daemon responds with a success- ful mount complete message if at least one of the filesystems has been mounted. This facil- ity is most commonly used with /net mounts that attempt to reproduce an NFS server's exported hierarchy on the client. Figure 8. Mount hierarchies are problematic for un- mounting. A process may have a file open within some filesystem within the hierarchy that may keep the filesys- tem "busy" and not unmountable. If an unmount at- tempt succeeds elsewhere in the hierarchy, it's mountpoint will appear to the process to be empty - until the automounter discovers the busy filesystem and re- mounts the filesystems that successfully unmounted. Figure 2. A single automount daemon provides a filesystem mount and unmount service to a number of autofs filesystems. Within an autofs directory, references to filesystems that need to be mounted are conveyed as remote procedure calls to the automount daemon which mounts requested filesystems on or beneath the autofs directory. After a period of inactivity the autofs requests the daemon unmount the filesystems it previously mounted.