Provided by: autofs5_5.0.4-3.1ubuntu5_i386 bug

NAME

       autofs - Format of the automounter maps

DESCRIPTION

       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.

FORMAT

       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

   key
       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.

   options
       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.

   location
       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.
       :/dev/sda1).

EXAMPLE

       Indirect map:

         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

FEATURES

   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).

   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:

         *         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.

   Variable Substitution
       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
       name):

         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
       to automount(8).

   Executable Maps
       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
       key.

       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.

   Multiple Mounts
       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
       default mount-options.

   Replicated Server
         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

UNSUPPORTED

       This  version  of  the automounter supports direct maps stored in FILE,
       NIS, NISPLUS and LDAP only.

SEE ALSO

       automount(8), auto.master(5), autofs(8), mount(8).

AUTHOR

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

                                  14 Jan 2000                        AUTOFS(5)