Automounter
| Industry | Computer software |
|---|---|
| Founded | 1982 |
| Founder | Vinod Khosla, Andy Bechtolsheim, Scott McNealy, Bill Joy |
| Products | Automount software (initial implementation) |
| Website | www |
An automounter refers to a software utility that mounts filesystems automatically when a user program attempts to access them. Commonly running as a daemon on Unix systems, it tracks access within designated directories and dynamically enables access to local or remote storage devices.
By employing automounters, systems optimize resource usage and minimize dependencies among servers sharing filesystems. In extensive enterprise environments with numerous file servers and thousands of workstations or nodes, only a limited number of remote filesystems are typically active per node simultaneously. Postponing mounts until necessary enhances system robustness, adaptability, and overall efficiency.
File servers can become unavailable due to maintenance activities, network disruptions, or load distribution strategies. Automating the mounting process eases client-side reconfiguration during such events.
These factors restrict the effectiveness of static approaches like the fstab file on Unix platforms. Automounter tools allow system administrators to centralize mapping between mount points and exports, providing users with seamless access to a unified filesystem across the organization.
Additionally, automounters support configuring multiple read-only repositories, enabling clients to select mounts based on criteria such as server availability, workload, or network proximity.
Home directories
In organizations where user home directories are distributed across several file servers, automounter services are deployed on all internal nodes—usually protected behind a firewall. Upon user login at any node, their home directory is mounted automatically at a shared mount location like /home/user. This setup facilitates effortless file access throughout the enterprise, particularly in UNIX environments where users connect remotely via tools such as ssh, telnet, rsh, or graphical protocols including X11 and VNC.
/net
A frequently used default path for automounted filesystems is
/net/hostname/nfspath, where hostname identifies the remote host and nfspath corresponds to the NFS-exported directory. This naming scheme eliminates the need for explicit entries for each exported path within a central automounter map. Nonetheless, this functionality was disabled by default in macOS after it was discovered to permit bypassing Gatekeeper security measures.
In many setups, individual workstations or compute nodes do not contain every software package users might require. Systems are often provisioned with a minimal or standard software image. Occasionally, users need access to legacy software versions for purposes such as bug resolution or regression testing.
Organizations generally maintain centralized repositories or "depots" containing these software packages for on-demand installation. These repositories may also house complete system images used during initial operating system deployment or recovery procedures.
Certain software applications demand significant storage space or evolve rapidly; in such cases, they might be installed and executed directly from file servers.
Automounts with dynamic variables
File servers frequently provide access to data and scripts throughout a networked environment. Nevertheless, certain files—particularly executables and shared libraries—need to correspond precisely to the hardware or operating system versions in use.
To handle this, automounter tools allow "mapping" or embedding variable elements within mount parameters. For instance, an enterprise supporting both Linux and Solaris platforms might maintain software repositories on a centralized file server under export paths such as depot:/export/linux and depot:/export/solaris. Each of these contains folders tailored to the supported OS versions.
By leveraging dynamic automount capabilities, system administrators can set up all machines so users access software updates via a uniform path like /software/updates. Solaris clients will locate Solaris-specific packages there, while Linux clients will find RPMs, DEBs, or other relevant packages matching their OS variant. Additionally, mappings can be refined by architecture; for example, Solaris users on SPARC systems retrieve appropriate exports distinct from those accessed by Solaris users on x86 hardware. Cross-platform scripting languages such as Perl or Python can be stored in a shared /software/common export since they execute without recompilation across different systems.
Certain organizations also deploy location-aware dynamic mappings, directing users to connect with nearby file servers that hold replicated resources for improved efficiency.
Automounter solutions thus provide transparent access to files regardless of their physical storage location, enabling both users and administrators to locate resources predictably without dealing with underlying complexities.
Software
Tom Lyon created the initial automount software at Sun Microsystems, with automounting introduced in SunOS 4.0 in 1988. Subsequently, Sun Microsystems licensed this technology to various commercial UNIX vendors. The release of Solaris 2.0 in 1992 featured an automounter based on a synthetic filesystem named autofs, which interacts with a user-space daemon to manage mounts. This design has since been adopted by other Unix-like operating systems such as AIX, HP-UX, and Mac OS X versions 10.5 and above.
In December 1989, Jan-Simon Pendry launched Amd, an automounter inspired by the SunOS implementation, also referred to as the Berkeley Automounter.
Linux developed its own autofs-based automounter; version 5 is largely compatible with Solaris’s automount approach.
FreeBSD formerly utilized Amd but introduced a new automounter resembling Solaris's starting with version 10.1. This newer implementation has been adapted for use in DragonFly BSD and NetBSD as well.
Several operating systems support automatic mounting of external devices such as FireWire or USB drives and removable media including CDs and DVDs. This differs from network automounting as it involves mounting local media upon user connection or insertion. Linux employs the user-space tool udev for this purpose; some functionalities previously handled by HAL are being integrated into udev. OpenBSD uses hotplugd(8) to execute scripts triggered by device attachment or removal, facilitating mounting actions. macOS relies on diskarbitrationd to automatically mount volumes. In FreeBSD, the automounter can manage removable media similarly to network shares.
Disadvantages and caveats
Although automounter tools provide centralized, uniform, and mostly seamless access to corporate storage resources, they come with several significant limitations:
- Delays in access may arise as the automounter processes mapping resolutions and mounts network shares.
- Directories might be unmounted after timeouts, resulting in lag during future access attempts.
- The association between mount points and exports generally depends on directory services such as LDAP or NIS, adding extra layers of dependency and potential points of failure.
- Achieving a consistent enterprise-wide strategy that balances frequently accessed and infrequently used resources—combining local replication with automounting—can be challenging.
- When migrating data between file servers, obsolete mounts may persist on former locations, sometimes necessitating host system reboots to clear them.
- Managing intricate mapping setups can lead to considerable administrative burden and confusion among users.
- Users might fail to recognize differences in access behavior between local and network filesystems, which can cause problems like unsafe locking practices on NFS vulnerable to race condition issues.