AUTO.MASTER(5)

💖 NAME 💖

auto.master — the Master Map for the automounter, the one that autofs consults. bestie this is literally the blueprint 🗺️✨

---

🌸 DESCRIPTION 🌸

okay so, the auto.master map is the thing that gets consulted to set up all the automount-managed mount points — it happens whenever the autofs(8) script is invoked or when the automount(8) program is run. and every single line does two jobs: it describes a mount point, and it points at an autofs map that describes the file systems to be mounted under that mount point. two jobs, one line, main character energy 💅

The default location of the master map is /etc/auto.master — that's home base. but you can give an alternate name on the command line when you're running the automounter, and you can also change the default master map by setting the MASTER_MAP_NAME configuration variable in /etc/sysconfig/autofs. 🎀 Now here's the cute twist: if the master map name has no path, then the system Name Service Switch configuration gets consulted, and each of the sources is searched in line with the rules given in the Name Service Switch configuration. slay, it goes looking for you. 🔍

Access to mounts in maps is governed by a key. that's the whole vibe. 🔑

---

🦋 direct maps

For direct maps the mount point is always specified as:

/-

and the key used within the direct map is the full path to the mount point. also, the direct map may have multiple entries in the master map — go off, honestly. 👑

🧚 indirect maps

For indirect maps, access happens by using this path scheme:

/mount-point/key

where mount-point is one of the entries listed in the master map. and the key? it's a single directory component, and it gets matched against entries in the map given in the entry (See autofs(5)). periodt. 💫

---

🌈 plus map inclusion

ngl, you can also include a map from its source as if it were itself present in the master map — you just drop in a line of this exact form:

+[maptype[,format]:]map [options]

and automount(8) will process the map according to the specification described below for map entries. 🫶 But bestie, listen: plus map inclusion is only permitted in file map sources. and indirect map entries must be unique in the master map — so second and subsequent entries for an indirect mount point are just… ignored by automount(8). first one wins, sorry to the latecomers 💀

---

NOTE: autofs currently does not collapse multiple slashes in paths, so it's genuinely important to make sure the paths you use in maps are correct. if there are unnecessary multiple slashes in a path, it can lead to unexpected failures — like being unable to expire automounts 😭 not the vibe. the one exception? a trailing slash at the end of the automount point path in the master map — that one will be removed if present. 🍓

✨ FORMAT ✨

okay bestie so a master map entry has three fields separated by an arbitrary number of spaces or tabs — yes, arbitrary, go off. Lines beginning with # are comments. The first field is the mount point (the one from above), the second field is the name of the map to be consulted for the mount point, and the third field is options to be applied to all entries in the map.

The format of a master map entry is:

mount-point [map-type[,format]:]map [options]

• mount-point — base location for the autofs filesystem to be mounted. For indirect maps this directory will be created (as with mkdir -p) and is removed when the autofs filesystem is umounted.
• map-type — type of map used for this mount point. The following are valid map types:
  • file — the map is a regular text file.
  • program — the map is an executable program, which is passed a key on the command line and returns an entry (everything besides the key) on stdout if successful. Optionally, the keyword exec may be used as a synonym for program to avoid confusion with amd formated maps mount type program.
  • yp — the map is a NIS (YP) database.
  • nisplus — the map is a NIS+ database.
  • hesiod — the map is a hesiod database whose filsys entries are used for maps.
  • ldap or ldaps — the map is stored in an LDAP directory. If ldaps is used the appropriate certificate must be configured in the LDAP client.
  • multi — this map type allows the specification of multiple maps separated by --. These maps are searched in order to resolve key lookups.
  • dir — this map type can be used at + master map including notation. The contents of files under given directory are included to the master map. The name of file to be included must be ended with .autofs. A file will be ignored if its name is not ended with the suffix. In addition a dot file, a file which name is started with . is also ignored.
• format — format of the map data; currently the formats recognized are sun, which is a subset of the Sun automounter map format, hesiod, for hesiod filesys entries and amd for amd formated map entries. If the format is left unspecified, it defaults to sun for all map types except hesiod unless it is a top level amd mount that has a configuration entry for the mount point path, in which case the format used is amd.
• map — name of the map to use. This is an absolute UNIX pathname for maps of types file, dir, or program, and the name of a database in the case for maps of type yp, nisplus, or hesiod or the dn of an LDAP entry for maps of type ldap.
• options — any remaining command line arguments without leading dashes (-) are taken as options (-o) to mount. Arguments with leading dashes are considered options for the maps and are passed to automount(8).

The sun format supports the following options:

• -Dvariable=value — replace variable with value in map substitutions. Yep, the -Dvariable bit is exactly that flag prefix, bestie.
• -strict — treat errors when mounting file systems as fatal. This is important when multiple file systems should be mounted (multimounts). If this option is given, no file system is mounted at all if at least one file system can't be mounted.
• [no]browse — this is an autofs specific option that is a pseudo mount option and so is given without a leading dash. Use of the browse option pre-creates mount point directories for indirect mount maps so the map keys can be seen in a directory listing without being mounted. Use of this option can cause performance problem if the indirect map is large so it should be used with caution. The internal program default is to enable browse mode for indirect mounts but the default installed configuration overrides this by setting BROWSE_MODE to "no" because of the potential performance problem. This option does the same as the deprecated --ghost option, the browse option is preferred because it is used by other autofs implementations.
• nobind — this is an autofs specific option that is a pseudo mount option and so is given without a leading dash. It may be used either in the master map entry (so it effects all the map entries) or with individual map entries to prevent bind mounting of local NFS filesystems. For direct mount maps the option is only effective if specified on the first direct map entry and is applied to all direct mount maps in the master map. It is ignored if given on subsequent direct map entries. It may be used on individual map entries of both types. Preventing bind mounts of NFS file systems can no longer be done by using the "port=" option, the nobind option must be used instead.
• symlink — this option makes bind mounting use a symlink instead of an actual bind mount. It is an autofs specific option that is a pseudo mount option and so is given without a leading dash. It may be used with indirect map entries only, either in the master map (so it effects all map entries) or with individual map entries. The option is ignored for direct mounts and non-root offest mount entries.
• strictexpire — use a strict expire policy for this automount. Using this option means that last use of autofs directory entries will not be updated during path walks so that mounts in an automount won't be kept mounted by applications scanning the mount tree. Note that this doesn't completely resolve the problem of expired automounts being immediately re-mounted due to application accesses triggered by the expire itself.
• slave, private or shared — this option allows mount propagation of bind mounts to be set to slave, private or shared. This option defaults to slave if no option is given. When using multi-mounts that have bind mounts the bind mount will have the same properties as its parent which is commonly propagation shared. And if the mount target is also propagation shared this can lead to a deadlock when attempting to access the offset mounts. When this happens an unwanted offset mount is propagated back to the target file system resulting in a deadlock since the automount target is itself an (unwanted) automount trigger. This option is an autofs pseudo mount option that can be used in the master map only.
• -r, --random-multimount-selection — enables the use of random selection when choosing a host from a list of replicated servers. This option is applied to this mount only, overriding the global setting that may be specified on the command line.
• -w, --use-weight-only — use only specified weights for server selection where more than one server is specified in the map entry. If no server weights are given then each available server will be tried in the order listed, within proximity.
• -t, --timeout <seconds> — set the expire timeout for map entries. This option can be used to override the global default given either on the command line or in the configuration.
• -n, --negative-timeout <seconds> — set the timeout for caching failed key lookups. This option can be used to override the global default given either on the command line or in the configuration.
• --mode <octal_mode> — set the directory mode for the base location of the autofs mount point. If this option is given, autofs will chmod that directory with this mode.

---

🦋 BUILTIN MAP -hosts 🦋

If -hosts is given as the map then accessing a key under the mount point which corresponds to a hostname will allow access to the exports of that host. The hosts map cannot be dynamically updated and requires a HUP signal to be sent to the daemon for it to check hosts for an update. Due to possible hierarchic dependencies within a mount tree, it might not be completely updated during the HUP signal processing.

For example, with an entry in the master map of:

/net -hosts

accessing /net/myserver will mount exports from myserver on directories below /net/myserver.

NOTE: mounts done from a hosts map will be mounted with the "no-suid,nodev" options unless overridden by explicitly specifying the "suid", "dev" options in the master map entry.

🦋 BUILTIN MAP -null 🦋

Okay bestie, hear me out — -null is the map you hand over when you want automount(8) to literally just 👏 ignore 👏 a later master map entry sitting at that path. That's it. That's the whole gig. It's the "girl, not today" of map types 💅

You can use it for paths that show up in the master map or in direct mount maps (but not in direct mount maps themselves) or as a key in an indirect mount map. Like, it's flexible, it's versatile, it's giving Swiss Army knife energy 🎀

• An indirect mount map key can be nulled. When that happens the map key is ignored and does not result in a mount attempt (essentially the key lookup is abandoned early on — she saw the sign and turned around ✨)
• An indirect mount map top level mount point path can be nulled. When that happens no mounts from the nulled mount are performed (essentially it isn't mounted — the mount point is just vibing, empty, unbothered 🌸)
• Direct mount map path entries can be nulled. Since they must be present at startup, they are (notionally) part of the master map, so direct mount paths that use the -null map may be used in the master map to ignore subsequent direct mount map entries 🫶
• A nulled master map entry path will ignore a single subsequent matching entry. Any matching entry following that one will be treated as it normally would be. A real-world use of this? Letting local master map entries override remote ones. Local wins, periodt 👑

NOTE: if a duplicate master map entry path is seen (excluding paths of null entries) it will be ignored and noted in the log. So: the first encountered master map entry is used unless there's a corresponding null entry. First come, first served — but the null entry is the one holding the clipboard at the door 💀

---

🌈 LDAP MAPS 🌈

If the map type ldap is specified, then the mapname takes the form [//servername/]dn — where the optional servername is the name of the LDAP server to query, and dn is the Distinguished Name of a subtree to search for map entries. The old style ldap:servername:mapname is also understood (yes, retro is in, we love a legacy format 💖). Alternatively, the type can be obtained from the Name Service Switch configuration, in which case the map name alone must be given.

If no schema is set in the autofs configuration, then autofs will check each of the commonly used schemas for a valid entry, and if one is found it will be used for subsequent lookups. She'll try them all on, basically, and keep the one that fits 👗✨

There are three common schemas in use:

nisMap

Entries in the nisMap schema are nisObject objects in the specified subtree, where the cn attribute is the key (the wildcard key is /), and the nisMapEntry attribute contains the information used by the automounter. Simple, classic, no notes 🎀

automountMap

The automountMap schema has two variations that differ in the attribute used for the map key. Entries in the automountMap schema are automount objects in the specified subtree, where the cn or automountKey attribute (depending on local usage) is the key (the wildcard key is /), and the automountInformation attribute contains the information used by the automounter. Also, heads up: the cn attribute is case insensitive. So Home and home are the same girl, lowkey 🙈

The object classes and attributes used for accessing automount maps in LDAP can be changed by setting entries in the autofs configuration located in /etc/sysconfig/autofs.conf.

NOTE: if a schema is given in the configuration, then all the schema configuration values must be set. Any partial schema specification will be ignored. It's all or nothing, bestie — no half-finished looks 💅

For amd format maps a different schema is used:

amdMap

The amdmap schema contains attributes amdmapName, amdmapKey and amdmapValue, where amdmapName contains the name of the containing map, amdmapKey contains the map key and amdmapValue contains the map entry. Cute, tidy, three little attributes doing their thing 🦋

---

🔐 LDAP AUTHENTICATION, ENCRYPTED AND CERTIFIED CONNECTIONS 🔐

LDAP authenticated binds, TLS encrypted connections and certification may all be used by setting appropriate values in the autofs authentication configuration file and configuring the LDAP client with appropriate settings. The default location of this file is /etc/autofs_ldap_auth.conf ✨

If this file exists, it will be used to establish whether TLS or authentication should be used. No file, no drama.

An example of this file is:

<?xml version="1.0" ?>
<autofs_ldap_sasl_conf
        usetls="yes"
        tlsrequired="no"
        authrequired="no"
        authtype="DIGEST-MD5"
        user="xyz"
        secret="abc"
/>

If TLS encryption is to be used, the location of the Certificate Authority certificate must be set within the LDAP client configuration in order to validate the server certificate. That part is non-negotiable, bestie — you gotta check her ID at the door 🪪

If, in addition, a certified connection is to be used, then the client certificate and private key file locations must also be configured within the LDAP client. More keys, more locks, more admin girlbossery 👑

In OpenLDAP these may be configured in the ldap.conf file or in the per-user configuration. For example, it may be sensible to use the system wide configuration for the location of the Certificate Authority certificate and set the location of the client certificate and private key in the per-user configuration. The location of these files and the configuration entry requirements is system dependent, so the documentation for your installation will need to be consulted to get further information. (Yes, actual research. I know. But the manpage can't do it for you 😭)

See autofs_ldap_auth.conf(5) for more information.

---

🌸 EXAMPLE 🌸

 /-        auto.data
 /home     /etc/auto.home
 /mnt      yp:mnt.map

This will generate two mountpoints for /home and /mnt and install direct mount triggers for each entry in the direct mount map auto.data. All accesses to /home will lead to the consultation of the map in /etc/auto.home, and all accesses to /mnt will consult the NIS map mnt.map. All accesses to paths in the map auto.data will trigger mounts when they are accessed, and the Name Service Switch configuration will be used to locate the source of the map auto.data. Everything knows where to find everything. It's a whole ecosystem, and it's thriving 🌱

---

To avoid making edits to /etc/auto.master, /etc/auto.master.d may be used. Files in that directory must have a .autofs suffix, e.g. /etc/auto.master.d/extra.autofs. Such files contain lines of the same format as the auto.master file, e.g.

 /foo    /etc/auto.foo
 /baz    yp:baz.map

Drop-in files instead of editing the big one?? Obsessed. Extend without disturbing. That's main character energy fr fr 🎀✨

---

⭐ SEE ALSO ⭐

automount(8), autofs(5), autofs(8), autofs.conf(5), autofs_ldap_auth.conf(5).

---

💜 AUTHOR 💜

This manual page was written by Christoph Lameter <chris@waterf.org>, for the Debian GNU/Linux system. Edited by <hpa@transmeta.com> and Ian Kent <raven@themaw.net>.

---

And that's the page, bestie — you made it to the end, I'm so proud of you 🫶 This rendition is from 11 Apr 2006, and the page goes by AUTO.MASTER(5). Go forth and mount responsibly 💅🔥