Frequently, one or more fileservers will become inaccessible (down for maintenance, on a remote and temporarily disconnected network, or accessed via a congested link).
Administrators also often find it necessary to relocate data from one file server to another - to resolve capacity issues and balance the load.
These factors combine to pose challenges to older "static" management methods of filesystem mount tables (the fstab files on Unix systems).
Automounter utilities address these challenges and allow sysadmins to consolidate and centralize the associations of mountpoints (directory names) to the exports.
When done properly, users can transparently access files and directories as if all of their workstations and other nodes attach to a single enterprise-wide filesystem.
For situations like this, automounter utilities generally support some means of "mapping" or "interpolating" variable data into the mount arguments.
Using the dynamic variation features in their automounter, they might then configure all their systems so that any administrator on any machine in their enterprise could access available software updates under /software/updates.
Some software (written in scripting languages such as Perl or Python) can be installed and/or run on any supported platform without porting, recompilation or re-packaging of any sort.
In all of these cases, automounter utilities allow the users to access files and directories without regard for the actual physical location.
Solaris 2.0, first released in 1992, implemented its automounter with a pseudofilesystem called autofs, which communicates with a user-mode daemon that performs mounts.
[8][9] While automounter utilities (and remote filesystems in general) can provide centrally managed, consistent and largely transparent access to an organization's storage services, they also can have their downsides: