Indirect maps, except for the internal hosts map, 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.
key [-options] location
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.
There are several special options
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 \ /home myserver.me.org:/home
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 autofs map:
floppy-vfat -fstype=vfat,sync,gid=floppy,umask=002 :/dev/fd0
Direct map:
/nfs/apps/mozilla bogus:/usr/local/moxill /nfs/data/budgets tiger:/usr/local/budgets /tst/sbin bogus:/usr/sbin
* server:/export/home/&
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 server:/export/home/foo.
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 SHOST Short hostname (domain part removed if present)
Additional entries can be defined with the -Dvariable=Value map-option to automount(8) .
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.
key [ -options ] [[/] location [/relative-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 default mount-options. This behaviour may be overridden by the append_options configuration setting.
Multiple replicated hosts, same path: <path> host1,host2,hostn:/path/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: <path> host1(5),host2(6),host3(1):/path/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: <path> host1(3),host:/blah
key location-list
A mount location-list can use the cut operator, ||, to specify locations that should be tried if none of the locations to the left of it where selected for a mount attempt.
A mount location consists of an optional colon seperated list of selectors, followed by a colon seperated list of option:=value pairs.
The selectors that may be used return a value or boolean result. Those that return a value may be to used with the comparison operators == and != and those that return a boolean result may be negated with the !.
For a location to be selected for a mount attempt all of its selectors must evaluate to true. If a location is selected for a mount attempt and succeeds the lookup is completed and returns success. If the mount attempt fails the proceedure continues with the next location until they have all been tried.
In addition some selectors take no argumenets, some one argument and others optionally take two arguments.
The selectors that take no arguments are:
- arch
The machine architecture which, if not set in the confugration, is obtained using uname(2) .- karch
The machine kernel architecture which, if not set in the confugration, is obtained using uname(2) .- os
The operating system name, if not set in the confugration, is obtained using uname(2) .- osver
The operating system version, if not set in the confugration, is obtained using uname(2) .- full_os
The full operating system name, if not set in the confugration this selector has no value.- vendor
The operating system vendor name, if not set in the confugration this selector has the value "unknown".- byte
The endianess of the hardware.- cluster
The name of the local cluster. It has a value only if it is set in the configuration.- autodir
The base path under which external mounts are done if they are needed. Most mounts are done in place but some can’t be and this is the base path under which those mounts will be done.- domain
The local domain name. It is set to the value of the configuration option sub_domain. If sub_domain is not given in the configuration it is set to the domain part of the local host name, as given by gethostname(2) .- host
The local host name, without the domain part, as given by gethostname(2) .- hostd
The full host name. If sub_domain is given in the configuration this is set to the contatenation of host and sub_domain deperated by a .. If sub_domain is not set in the configuration the value of domain is used instead of sub_domain.- uid
The numeric value of the uid of the user that first requested the mount. Note this is usual the same as that used by amd but can be different within autofs.- gid
The numeric value of the gid of the user that first requested the mount. Note this is usual the same as that used by amd but can be different within autofs.- key
The string value of the key being looked up.- map
The string value of the map name used to lookup keys.- path
The string value of the full path to the mount being requested.- dollar
Evaluates to the string "$".
The key string to be looked up is constructed by prepending the prefix, if there is one.
The resulting relative path string is matched by first trying the sting itself. If no match is found the last component of the key string is replaced with the wilcard match cahracter ("*") and a wildcard match is attemted. This process continues until a match is found or until the last match, against the wilcard match key alone, fails to match a map entry and the key lookup fails.
Many of the option values are set as macro variables corresponding to the option name during the map entry parse. So they may be used in subsequent option values. Beware though, the order in which option values is not necessarily left to right so you may get unexpected results.
Assuming we have the autofs master map entry:
/test file,amd:/etc/amd.test
And the following map in /etc/amd.test:
/defaults type:=nfs;rhost:=bilbo apps rfs:=/autofs util rhost:=zeus;rfs:=/work/util local rfs:=/shared;sublink:=local
In the first line we have an NFS remote mount of the exported directory /autofs from host bilbo which would be mounted on /test/apps. Next another nfs mount for the exported directory /work/util from host zeus. This would be mounted on /test/util.
Finally we have an example of the use of the sublink option. In this case the filesystem bilbo:/shared would be mounted on a path external the automount directory (under the direcory given by configuration option auto_dir) and the path /test/local either symlinked or bind mounted (depending on the setting autofs_use_lofs) to the "local" subdirectory of the external mount.