Provided by: autofs5_5.0.4-3.1ubuntu5_i386
autofs - Format of the automounter maps
The automounter maps are FILE, NIS, NISPLUS or LDAP maps referred to by
the master map of the automounter (see auto.master(5)). These maps
describe how file systems below the mount point of the map (given in
the master map) are to be mounted. This page describes the sun map
format; if another map format is specified (e.g. hesiod), this
documentation does not apply.
Indirect maps can be changed on the fly and the automouter will
recognize those changes on the next operation it performs on that map.
Direct maps require a HUP signal be sent to the daemon to refresh their
contents as does the master map.
This is a description of the text file format. Other methods of
specifying these files may exist. All empty lines or lines beginning
with # are ignored. The basic format of one line in such maps is:
key [-options] location
For indirect mounts this is the part of the path name between the mount
point and the path into the filesystem when it is mounted. Usually you
can think about the key as a sub-directory name below the autofs
managed mount point.
For direct mounts this is the full path of each mount point. This map
is always associated with the /- mount point in the master map.
Zero or more options may be given. Options can also be given in the
auto.master file in which case both values are cumulative (this is a
difference from SunOS). The options are a list of comma separated
options as customary for the mount(8) command. There are two special
options -fstype= used to specify a filesystem type if the filesystem is
not of the default NFS type. This option is processed by the
automounter and not by the mount command. -strict is used to treat
errors when mounting file systems as fatal. This is important when
multiple file systems should be mounted (`multi-mounts'). If this
option is given, no file system is mounted at all if at least one file
system can't be mounted.
The location specifies from where the file system is to be mounted. In
the most cases this will be an NFS volume and the usual notation
host:pathname is used to indicate the remote filesystem and path to be
mounted. If the filesystem to be mounted begins with a / (such as
local /dev entries or smbfs shares) a : needs to be prefixed (e.g.
kernel -ro,soft,intr ftp.kernel.org:/pub/linux
boot -fstype=ext2 :/dev/hda1
windoze -fstype=smbfs ://windoze/c
removable -fstype=ext2 :/dev/hdd
cd -fstype=iso9660,ro :/dev/hdc
floppy -fstype=auto :/dev/fd0
server -rw,hard,intr / -ro myserver.me.org:/ \
/usr myserver.me.org:/usr \
In the first line we have a NFS remote mount of the kernel directory on
ftp.kernel.org. This is mounted read-only. The second line mounts an
ext2 volume from a local ide drive. The third makes a share exported
from a Windows machine available for automounting. The rest should be
fairly self-explanatory. The last entry (the last three lines) is an
example of a multi-map (see below).
If you use the automounter for a filesystem without access permissions
(like vfat), users usually can't write on such a filesystem because it
is mounted as user root. You can solve this problem by passing the
option gid=<gid>, e.g. gid=floppy. The filesystem is then mounted as
group floppy instead of root. Then you can add the users to this group,
and they can write to the filesystem. Here's an example entry for an
floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0
Map Key Substitution
An & character in the location is expanded to the value of the key
field that matched the line (which probably only makes sense together
with a wildcard key).
A map key of * denotes a wild-card entry. This entry is consulted if
the specified key does not exist in the map. A typical wild-card entry
looks like this:
The special character '&' will be replaced by the provided key. So, in
the example above, a lookup for the key 'foo' would yield a mount of
The following special variables will be substituted in the key and
location fields of an automounter map if prefixed with $ as customary
from shell scripts (Curly braces can be used to separate the field
ARCH Architecture (uname -m)
CPU Processor Type
HOST Hostname (uname -n)
OSNAME Operating System (uname -s)
OSREL Release of OS (uname -r)
OSVERS Version of OS (uname -v)
autofs provides additional variables that are set based on the user
requesting the mount:
USER The user login name
UID The user login ID
GROUP The user group name
GID The user group ID
HOME The user home directory
HOST Hostname (uname -n)
Additional entries can be defined with the -Dvariable=Value map-option
A map can be marked as executable. A program map will be called with
the key as an argument. It may return no lines of output if there's an
error, or one or more lines containing a map entry (with \ quoting line
breaks). The map entry corresponds to what would normally follow a map
An executable map can return an error code to indicate the failure in
addition to no output at all. All output sent to stderr is logged into
the system logs.
A multi-mount map can be used to name multiple filesystems to mount.
It takes the form:
key [-options] [mount-point [-options] location...]...
This may extend over multiple lines, quoting the line-breaks with `\'.
If present, the per-mountpoint mount-options are appended to the
Multiple replicated hosts, same path:
Multiple hosts, some with same path, some with another
<path> host1,host2:/blah host3:/some/other/path
Multiple replicated hosts, different (potentially) paths:
<path> host1:/path/pathA host2:/path/pathB
Mutliple weighted, replicated hosts same path:
Multiple weighted, replicated hosts different (potentially) paths:
<path> host1(3):/path/pathA host2(5):/path/pathB
Anything else is questionable and unsupported, but these variations will also work:
This version of the automounter supports direct maps stored in FILE,
NIS, NISPLUS and LDAP only.
automount(8), auto.master(5), autofs(8), mount(8).
This manual page was written by Christoph Lameter <firstname.lastname@example.org>,
for the Debian GNU/Linux system. Edited by H. Peter Avian
<email@example.com>, Jeremy Fitzhardinge <firstname.lastname@example.org> and Ian Kent
14 Jan 2000 AUTOFS(5)