Make your own free website on Tripod.com

SunService Tip Sheet: Sun Automounter


INFODOC ID: 11990

SYNOPSIS: AUTOMOUNTER PSD/FAQ
DETAIL DESCRIPTION:

SunService Tip Sheet for the Sun Automounter

Revision: 1.5
Date: June 18, 1996

Mail to: brian.hackley@east.sun.com

Table of Contents:

1.0: About the Automounter
2.0: Debugging the Automounter
  2.1: Testing NFS
  2.2: Turning on Automounter Debugging
  2.3: Testing New Maps Under Solaris
3.0: Common How Tos
  3.1: How to Set Up a SunOS Automount Client Using Files
  3.2: How to Set Up a SunOS Automount Client Using NIS
  3.3: How to Set Up a Solaris Automount Client Using Files
  3.4: How to Set Up a Solaris Automount Client Using Naming Services
  3.5: How to Modify Automount Maps Under NIS
  3.6: How to Modify Automount Maps Under NIS+
  3.7: How to Create New NIS Automount Maps
  3.8: How to Create New NIS+ Automount Maps
  3.9: How to Make Changes to SunOS Automounters
  3.10: How to Make Changes to Solaris Automounters
  3.11: How to Upgrade Automount from SunOS to Solaris
  3.12: How to use cachefs With the Automounter
4.0: Some Frequently Asked Questions
  4.1: Miscellaneous Questions
  4.2: Automount Startup Errors
  4.3: Automount Runtime Errors
  4.4: Automount Shutdown
  4.5: /home Problems
  4.6: /net Questions
  4.7:  How do I tell automount NOT to use a certain map?
5.0: Patches
  5.1: SunOS Patches for Automount
  5.2: Solaris Patches for Automount
6.0: Known Bugs & RFEs
  6.1: Bugs
7.0: References
  7.1: Important Man Pages
  7.2 Sunsolve Documents
  7.3 Sun Educational Services
  7.4: Solaris Documentation
  7.5: Third Party Documentation
  7.6: RFCs
8.0: Supportability
9.0: Additional Support

 1.0: About the Automounter

This Tip Sheet documents a wide variety of information concerning the
automounter, as implemented in the SunOS and Solaris operating
systems. It is intended as both an introduction to the automounter,
and as a guide to the most common problems. There are many more
complete references to automounter, a few of which are noted in
sections 7.4 and 7.5.

Before trying to run the automounter, you must already have a good
understanding of NFS in general. SunService does have another Tip
Sheet discussing general NFS topics.

The following terms are important to an understanding of the
automounter:

THE AUTOMOUNTER is a program which automatically does mounts and
unmounts of designated NFS partitions. It has MAPS which list what
directories it controls in this manner. Automounted directories start
out unmounted, are mounted when someone tries to access them, and
eventually timeout, and are unmounted, when people stop using them.

There are two types of automounter maps: direct and indirect. A DIRECT
MAP lists a set or unrelated mount points which may be spread out
across the filesystem. A complete path (ie, /usr/local/bin or
/usr/man) is listed in the map as a mount point. An INDIRECT MAP sets
aside a directory, and mounts everything in the map into that
directory (ie, the auto.home map sets aside /home, and everything in
the auto.home map is mounted under that directory).

Automounter maps are typically distributed via a naming service, such
as NIS or NIS+, so that changes can be made in one central location.

Automount between SunOS and Solaris only has one real difference: the
files and maps have dots (.s) in them under SunOS (ie auto.master,
auto.home), while the files/maps have underscores (_s) in them under
Solaris (ie auto_master, auto_home). This change was made so that the
automount maps could work correctly under NIS+.

2.0 Debugging the Automounter

 General Information on Debugging the automounter

Automounter problems usually manifest as an inability to cd into a
directory that should be automounted.

You should first of all look through your files and maps, making sure
that they are all connected correctly, and have the right info. For
example, if auto.direct is not getting read right, you should verify
that auto.master references it. On Solaris, you might need to check
the nsswitch.conf as well, to make sure that the automounter is using
the right naming service. Consult Sections 3.1 through 3.4 for
examples of proper setups.

In addition, if you are having problems with some new automounter
info, you may need to restart automounter (see Section 3.9 and 3.10
for more info). If all of this seems correct, the following sections
describe some additional techniques that may be used to debug the
automounter

 2.1: Testing NFS

If you are having problems with an automounter directory, you should
always try and mount the partition by hand, to verify that the problem
is related to automounter, and not NFS in general.

To do this, look in your auto.* maps, and see what remote partition
your automounter is trying to access. Then, run mount to access it:

  # mkdir /tmpmnt
  # mount remotemachine:/partition /tmpmnt

If this generates errors, your problems is with NFS. SunService has a
seperate NFS Tip sheet which describes common NFS problems, and how to
debug them.

If this mount works fine, the problem is with automounter

 2.2: Turning on Automounter Debugging

automounter also has built in debugging, which can be used to examine
exactly what the automounter is doing. It is best to kill automount
and restart it with the debug flags, so that you can see everything
from the start:

  SunOS:
  # automount -v -TT

  Solaris 2.3:
  # automountd -vTT
  # automount -v

  Solaris 2.4 and 2.5 in a /bin/sh or /bin/ksh to redirect to a file:
  # automountd -vTT 2> /var/automount-debug-file

If you do not wish to kill the automounter, you can instead enable
some debugging with the following commands:

  # ls /net/=2
  # ls /net/=v

[The above "ls"es may not work in some cases. If this occurs, you
should simply restart automount as noted above.]

After debugging has been enabled, output will start appearing on your
console (Solaris 2.3 or earlier) or in your current window (Solaris
2.4). You will see lots of instances of mounts and unmounts, but
should look, in particular, for errors that are recorded when you try
and access the trouble automount directory.

 2.3: Testing New Maps Under Solaris

Under Solaris, if you are having problems with a brand new map, you
can run automount with the -v flag. This will tell you what automount
is doing as it tries to create autofs mount points for new maps:

  # automount -v

You can also look in the /etc/mnttab file for your automount map
definitions.  TIP:  if you don't see the map definition in
/etc/mnttab (or /etc/mtab for SunOS), there is something wrong
with it.

Here is the map definition for an indirect map entry
from the master file for /autohome1   auto.home1:

auto.home1      /autohome1      autofs  ignore,indirect,dev=28c0002     81842871

...and here is an example mount using that map:

ace:/home1/ace  /autohome1/ace1 nfs     dev=2880002     818428801

3.0 Common How-Tos

 3.1: How to Set Up a SunOS Automount Client Using Files

Under SunOS, the automounter is centered around the file
/etc/auto.master. This file must contain a number of lines in the
following format:

  directory     mapname options

Where: directory is the directory to mount an indirect map in, or /-
for a direct map  mapname is the file which contains the map  and
options are any standard NFS options which should be used for the
entire map. An example of an auto.master file follows:

  %% cat /etc/auto.master
  /-    /etc/auto.direct        -ro
  /home /etc/auto.home

In this example, /etc/auto.direct will be a direct map, which mounts a
number of filesystems readonly, while /etc/auto.home will be a
indirect map, which mounts filesystems under the /home directory.

A typical map contains a number of lines as follows:

  mountpoint    [options]       remotemachine:/remotelocation

The [options] can be omitted if only the standard options should be
used. montpoint will be a full path for a direct mount (/usr/local) or
just a directory name for an indirect mount (joe).

For example, the auto.direct map may read:

  %% cat /etc/auto.direct
  /usr/man      -soft   server:/usr/man
  /usr/local            server:/export/sunos/usr/local

This would create automount points for /usr/man and /usr/local, and
/usr/man would be mounted soft.

While the auto.home map (or any indirect map) would look something
like this:

  %% cat /etc/auto.home
  joe           server:/export/home/joe
  fred          server:/export/home/fred

This would create automount points for /home/joe and /home/fred.

Please note that automount will use an auto.master NIS map by default.
Thus, to force automounter to use local files, you must start is as
follows:

  # automount -f /etc/auto.master &

You will also want to modify the automount startup in /etc/rc.local.

 3.2: How to Set Up a SunOS Automount Client Using NIS

To force your automounter to read in NIS maps, you must change the way
that the mapname is referenced in your auto.master file. If the
mapname is listed without any "/"s, NIS maps will be automatically
checked. The following auto.master file says to get the direct listing
from the auto.direct NIS map, and the /home listing from the auto.home
NIS map:

  # cat /etc/auto.master
  /-    auto.direct     -ro
  /home auto.home

(Compare this to Section 3.1, where the mapname column of the
/etc/auto.master map contains "/"s, directing the automounter to a
local path.)

In order to get a SunOS client to start automount, using the NIS maps,
all you need to do is either create an auto.master map in NIS, and
distribute it (See Section 3.5), or create a local map, as noted
above. Other maps should be created on the NIS master, with the same
format as is described in Section 3.1 (see Section 3.5 for how to
modify those NIS maps).

Afterwards, simply reboot the machine, or start up automount:

  # automount &

[As a note, you may also read in NIS maps by putting a +mapname entry,
ie +auto.home, in a local file  this is usually done to set up a
unique automounter on a certain machine. The references in Section 7.0
should be used if you wish to implement a more complex set up, such as
this.

 3.3: How to Set Up a Solaris Automount Client Using Files

Follow the instructions in Section 3.1, but be aware that under
Solaris, the names of the files are expected to contain "_"s instead
of "."s. ie:

  /etc/auto_master
  /etc/auto_direct
  /etc/auto_home

So, using only files, your auto_master should look something like
this:

  # cat /etc/auto_master
  /-    /etc/auto_direct        -ro
  /home /etc/auto_home

The other files would follow with the same format as described in
Section 3.1.

When everything is set up, you can get automount starting by rebooting
the machine, or running:

  # /etc/init.d/autofs start

 3.4: How to Set Up a Solaris Automount Client Using Other Naming Services

If the /etc/auto_master file contains mapnames without "/"s,
additional naming services are consulted, according to the order
listed in the nsswitch.conf. For example, the following
/etc/nsswitch.conf line would say to check first files, then NIS:

  automount:  files nis

In addition, the local files may say to read other naming services, by
listing the entry "+mapname".

Following is an extremely typical automount setup for Solaris:

  # cat /etc/auto_master
  +auto_master
  /net            -hosts          -nosuid
  /home           auto_home

[The +auto_master line says to first check naming services (NIS/NIS+)
for an auto_master map. Afterwards, it includes a special net map,
which is described in the man page, and also a /home indirect map,
which is read from the naming services.]

  # cat /etc/auto_home
  +auto_home

[This file says to just go out to naming services. It is necessary
because "files" is one of the options listed in the nsswitch.conf.]

  # ypcat auto_master
  [any additional auto_master entries are listed here]
  # ypcat auto_home
  ...
  [the full auto_home map is here]

[Thus you will need to setup all of your normal maps in NIS or NIS+,
as is described in Sections 3.5 and 3.6.]

Of special note here is this: If NIS is listed as the naming service,
and automountd can't find an auto_map, then it will try instead to
lookup auto.map, since that is the older NIS standard. So, the above
would work fine if you were using NIS, and the actual NIS map was
auto.home.

When everything is set up, you can get automount started by rebooting
the machine, or running:

  # /etc/init.d/autofs start

 3.5: How to Modify Automount Maps Under NIS

The auto.master and auto.home maps are automatically part of NIS. To
distribute these maps, simply edit the files /etc/auto.master and
/etc/auto.home on the master, using the format described in Section
3.1, and then make the maps to distribute them:

  # cd /var/yp
  # make

Section 3.7 describes how to create new NIS maps.

 3.6: How to Modify Automount Maps Under NIS+

The auto_master and auto_home tables are automatically part of NIS+.
They may be modified, using the format described in Section 3.1. The
auto_home table may be modified via admintool, nistbladm or nisaddent
(admintool is suggested). The auto_master table may be modified via
nistbladm or nisaddent. nisaddent is probably the best options for
making this modification.

To make a modification with nisaddent, you should first dump your map
to a text file:

  # /usr/lib/nis/nisaddent -d -t auto_master.org_dir key-value > /etc/auto_master.nisplus

Then, you can edit the file with your favorite editor. Remember to use only tabs between the fields, not embedded spaces:

  # cat /etc/auto_master.nisplus
  +auto_master
  /net            -hosts          -nosuid
  /home           auto_home

Afterwards, run nisaddent again to replace the NIS+ map with your text file:

  # /usr/lib/nis/nisaddent -r -f /etc/auto_master.nis -t auto_master.org_dir
key-value

Section 3.8 describes how to create new NIS+ maps

 3.7: How to Create New NIS Automount Maps

The following example explains how to create an auto_direct map under
NIS. Other new maps can be created with similar syntax.

In order to create an auto.direct map, you need to make a new entry in
/var/yp/Makefile for auto.direct, mimicking the already existing
auto.home entry:

  auto.direct.time:  $(DIR)/auto.direct
        -@if [ -f $(DIR)/auto.direct ]  then                 sed -e "/^#/d" -e s/#.*$$// $(DIR)/auto.direct                   $(MAKEDBM) - $(YPDBDIR)/$(DOM)/auto.direct                  touch auto.direct.time                  echo "updated auto.direct"                  if [ ! $(NOPUSH) ]  then                 $(YPPUSH) auto.direct                          echo "pushed auto.direct"  \
                else                 :                   fi         else                 echo "couldn't find $(DIR)/auto.direct"          fi

NOTE: all INDENTED $lines in the Makefile entry MUST be indented
with the TAB key, without any imbedded spaces!!

In addition, auto.direct must be added to the all: line, near the top
of the Makefile:

  all: passwd group hosts ethers networks rpc services protocols         netgroup bootparams aliases publickey netid netmasks c2secure         timezone auto.master auto.home auto.direct

And, finally, near the bottom, the following line must be added:

  auto.direct: auto.direct.time

[Be very careful if you just copy the above lines -- Makefile entries
MUST begin with TABS, not spaces  if you text copy the above, you will
end up with spaces at the beginning of each line, and make will fail.]

When this is all done, you may create an /etc/auto.direct map, put the
appropriate files in it, and then do a Make:

  # cd /var/yp
  # make

After you have done the first make, you will probably gets some errors
like the following:

  "can't bind master to send ypclear message to ypserv for map ..."

This occurs because NIS is confused due to the maps not existing on
the slave machines. To resolve this, you must manually copy the map to
the slaves. This can be done by copying /var/yp/`domainname`/auto.direct.*
from the master to /var/yp/`domainname` on each of the slaves, using
either rcp or ftp.

Afterwards, do a second make:

  # cd /var/yp
  # make

 3.8: How to Create New NIS+ Automount Maps

The following example explains how to create an auto_direct map under
NIS+. Other new maps can be created with similar syntax.

STEP ONE: create a new auto_direct table, on the master server:

   # nistbladm -c automount_map key=S value=S auto_local.org_dir.`domainname`.

STEP TWO:  set the group ownership of the table:

   # nischgrp admin.`domainname`. auto_local.org_dir

STEP THREE:  set the correct permissions.

   # nischmod n=r, o=rmcd,g=rmcd, w=r auto_local.org_dir

STEP FOUR:  create a text file, and read it into NIS+, just as is
described in section 3.6:

  # cat /etc/auto_local.nisplus
  /usr/local/bin        server:/usr/local/bin
  /usr/local/lib        server2:/usr/local/lib
  # /usr/lib/nis/nisaddent -r -f /etc/auto_local.nisplus     -t auto_local.org_dir key-value

STEP FIVE:  verify the data is in the map:
  # niscat -m auto_local.org_dir

  (your data should display)

NOTE:  You will also want to add an entry to your NIS+ auto_master map, as is
described in 3.6.

 3.9: How to Make Changes to SunOS Automounters

Many changes to the Automounter will take place at once. There are two
exceptions: if an automounted filesystem (or group of filesystems) is
changed, that change will not take place until the filesystem (or the
filsystem group) is unmounted and remounted  if a change is made to
the auto.master map, or to a direct map, those changes will not take
place until the automounter is restarted.

If you want to make sure that your new changes are available, your
best option is to reboot the client machine running automounter.

 3.10: How to Make Changes to Solaris Automounters

As with the SunOS automounter, the Solaris automounter will not see
changes to already mounted partitions, the auto_master file, and
direct maps. (See Section 3.9).

You must still wait for already mounted partitions to get umounted in
orderto see changes on them.

However, you can force auto_master and direct map changes to get
immediatelly recognised by running automount from the command line:

  # automount -

 3.11: How to Upgrade Automount from SunOS to Solaris

To upgrade your Automounter from SunOS to Solaris, you must first
change your map names from using dots to underscores. ie:

  auto.direct -> auto_direct
  auto.home -> auto_home

Make sure you change all references inside the files as well.

Another common problem involves the /home directory. SunOS machines
often used it as a normal directory, while Solaris typically uses it
as an automounter point.

If you prefer to use /home as a normal directory, disable the /home
automounting, by removing /home lines from all of your auto_direct
files:

  # cat /etc/auto_master
  +auto_master
  /net            -hosts          -nosuid
  # /home           auto_home

[make sure to modify NIS or NIS+ maps too, if necessary]

If you prefer to use /home as an automount point, move everything in
/home to a new directory (/export/home) and then set up an auto_home
map which references that directory:

  # cat /etc/auto_home
  joe   machine:/export/home/joe
  fred  machine:/export/home/fred

 3.12: How to use cachefs With the Automounter

cachefs may be used with the automounter. The following example shows
a direct cachefs map being created:

  %% cat /etc/auto_master
  ...
  /-    /etc/auto_new

  %% cat /etc/auto_new
 /mydir -fstype=cachefs,cachedir=/var/mycache,backfstype=nfs  remotemachine:/dir

NOTE:  we put the "-fstype..." options into the auto_new map because a
bug exists at 2.3 and 2.4 where any "fstype" options in the master map
are ignored.  This bug is fixed in 2.5.

 3.13: How to automount into an existing directory

If you want to automount something like /tools/compilers into an
existing /tools directory, use a direct map such as:

  # cat /etc/auto_master
  ...
  /-    /etc/auto_direct

  # cat /etc/auto_direct
  ...
  /tools/compilers  -rw,hard,intr remotemachine:/opt/compilers

If you had used an indirect map (e.g. /tools /etc/auto_tools
in the master map), the existing directory would be overlaid
by /tools and disappear!  Therefore, use a direct map for
EXISTING directories that you wish to use.

4.0 Frequently Asked Questions

 Regarding this Section

Many apparent automount problems will actually be due to deeper NFS
problems. Many of these are covered in the NFS Tip Sheet. If none of
the problems listed below are familiar, you might want to see if other
NFS services are also having problems, and examine the NFS Tip Sheet

 4.1: Miscellaneous Questions

Q: Why does my entire automounter lock up under SunOS, whenever one
automounted partitions becomes unavailable?

A: This is a design limitation of the automounter under SunOS. There
is no work around for it. If you upgrade your machine to Solaris, you
will find that automount reacts much better to individual partitions
becoming unavailable.

Q1: What is this /tmp_mnt directory?
Q2: Why does SunOS use /tmp_mnt when Solaris doesn't?
Q3: How do I get rid of the /tmp_mnt directory?

A: If you are using the automounter under SunOS, whenever you do pwd
or df, you will always see that your fileystem is mounted on /tmp_mnt.
This is part of the functionality of SunOS automounter. You can work
around the pwd problem in csh with the following alias:

  # alias pwd echo \$cwd

If you wish this to be permanent, you can add the following to your
.cshrc:

  alias pwd (echo $cwd)

If the /tmp_mnt directory is causing you other problems, you should
simply mount the partition through normal NFS.

In addition, if you upgrade your machine to Solaris, you will find
that it does not have to go through the /tmp_mnt directory.

Q: Why is automount taking up lots of CPU time?

A: umount is a fairly expensive operation, and automount does it
regularly. If you find that automount is taking up too much CPU, and
you have all the listed automount and NFS patches installed, you are
probably running into the limitations of your current setup. You can
work around it by increasing the timeout value of automount (this is
the length of time before automount will unmount an unused partition).

On a SunOS machine, edit the automount line of /etc/rc.local. The
following line increases the automount timeout to 3600 seconds, or 60
minutes:

  automount -tl 3600 &&            echo -n ' automount'

On a Solaris machine, edit the automount line of /etc/init.d/autofs.
The following line increases the automount timeout to 3600 seconds, or
60 minutes:

  /usr/sbin/automount -t 3600                             # do mounts

The above two fixes are only workarounds. Your system probably will
still have some performance problems which SunService is unable to
help you resolve. Sections 8.0 and 9.0 explain your alternatives in
this case.

Q: Should I use dots or underscores in my map names!?

A: In general, use dots under SunOS and underscores under Solaris. The
following two fallbacks make this easier to do:

If an auto_map is distributed via NIS+ in YP-compatibility mode, an
auto.map will also be distributed.

If a Solaris machines looks up auto_map in NIS, and can not find it,
it will also try and look up auto.map.

In cases when neither of these apply (ie, if you have a Solaris NIS
server), your clients should use either dots or underscores, according
to what your NIS/NIS+ server uses.

Q: Should I specify mount options in the auto.master file, or the
subfile (ie auto.home)?

A: You can specify mount options in either (or both). The last option
encountered will be the one that's used. If you need a mount option to
be global for a map, you should put it in the auto.master file. If you
need it to be specific for a mount, you should put it in the subfile
(ie auto.home).

 4.2: Automount Startup Errors

Q: What does the following error mean:

  "automount: /directory/name: Not a directory"

A: This usually means that /directory/name, which is a mount point
listed in one of your auto.* files, either is a file or a symbolic
link. It must be a directory.

Q: What does the following error mean:

  "automount: Can't get my address"

A: Your current naming service does not have an entry for your
hostname. Correct this in files/NIS/NIS+/DNS as appropriate.

 4.3: Automount Runtime Errors

Q: What does the following error mean:

  "automountd: server [machine] not responding"

A: This correlates to the standard "NFS server [machine] not
responding" error. This can mean a number of things, including (1)
[machine] is down, or otherwise unavailable (2) you are experiencing
certain old NFS bugs, which are corrected by the NFS patches listed in
the NFS Tip Sheet (3) you are experiencing a NFS performance problem.
If this is a performance problem, you will usually find that
automounted partitions are very slow to access, and the "not
responding" error appears intermittently. In the case of performance
problems, SunService can do nothing further  Sections 8.0 and 9.0
explain your other options.

 4.4: Automount Shutdown

Q: How should I kill the automounter?

A: Always give automounter a "friendly kill"  never kill -9. This will
allow the automounter to clean up all those symlinks and umount those
file systems. Busy mounts are NOT left alone, after a valiant attempt
to umount. What happens is this: automount spawns a child to service
any NEW requests to the automounte and the parent spends its time
trying to umount all busy mounts.

Note: if you do a kill -9 at this point you WILL have to clean up your
mess (remove symlinks, umount old automount NFS mounts, and clear up
/tmp_mnt).

 4.5: /home Problems

Q: Why are my /home mounts not working?

A: It is common for /home mounts to fail because something has been
put in the /home directory of the problem client. Make sure that the
/home directory is totally empty before the automounter is started.

 4.6: /net Questions

Q: Can you explain the /net -hosts entry in the auto_master file?

A: The -hosts map is a special case of an indirect map, that provides
for the dynamic mounting of a host upon reference. It is usually
referenced as:

	cd /net/hostname

If you start the automounter with /net -hosts, the automounter will do
the following for you:

When you reference a pathname, e.g. ls -l /net/hostname, and the
hostname is an NFS server, the automounter will do an NFS mount of all
exported filesystems on that NFS server for you, place the physical
mount into /tmp_mnt/hostname, and let you access that NFS server thru
a symlink, /net/hostname -> /tmp_mnt/net/hostname. You access the NFS
files thru the /net/hostname symlink and do not need to worry about
managing NFS mounts.

 4.7:  How do I tell automount NOT to use a certain map?

Q:  I have a local /home directory on a certain host, that I do
    not want the automounter to overwrite.  How do I tell automount
    NOT to use a certain map?

A:  Create an /etc/auto_master, if one does not already exist.
    Move the "+auto_master" entry to the BOTTOM of the file.
    Change (or add) the /home entry so that it reads as follows:
/home -null
    This tells the automount to NOT create a /home map, which will
    allow you to use a local /home directory on the host.

    IMPORTANT:  you may NOT specify "-null" anywhere EXCEPT the
    master map!  You can exclude an entire map, but NOT
    individual entries within a map.

5.0 Patches

 5.0: Patches

The following is the list of all of the automount related patches for
4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having automount
problems, installing the patches is a good place to start, especially
if you recognize the general symptoms noted below.

In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve1.sun.com.

There are also a number of NFS patches which are described in the NFS
Tip Sheet. All of the Core NFS patches described there should be
installed as well

 5.1: Automount Patches for SunOS

100249-14 SunOS 4.1.2,4.1.3: automounter jumbo patch

  Fixes a very large number of automounter errors, including a big
  memory leak. Should be installed on any machine running automount.

102684-02 SunOS 4.1.3_U1: automounter problems when many filesystems shar

  Resolves a problem where a SunOS machine could fail to automount
  from a Solaris server with the error "RPC: can't decode results".

103467-01 SunOS 4.1.4: Automount fails with replicated filesystems

 5.2: Automount Patches for Solaris

SOLARIS 2.3:

101318-81 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)

  Resolves a very large number of autofs and nfs problems. Should
  be installed on any machine, but are an absolute necessity for
  machines running automount.

103059-01 SunOS 5.3: automountd /dev rdev not in mnttab

  This completes the fixes for this problem (except when using AFS)

SOLARIS 2.4 and 2.4x86:

101945-42 SunOS 5.4: jumbo patch for kernel
101946-35 SunOS 5.4_x86: jumbo patch for kernel

  Resolves a very large number of autofs and nfs problems. Should
  be installed on any machine, but are an absolute necessity for
  machines running automount.

atch-ID#  SunOS 5.4_x86: automounter fixes

   Fixes problems with automounter related to 4.1.3 interoperability
  and NIS+. Should be installed on any systems having troubles with
  either 4.1.3 or NIS+.

Solaris 2.5 and 2.5x86:

103048-03 SunOS 5.5: automountd fixes
 SunOS 5.5x86 automountd fixes

  Adds support for the "retry" parameter at 2.5
  Fixes 1211172 "dev ... rdev not in mnttab" problem with lofs mounts

103492-01 SunOS 5.5: autofs is not MT-safe

6.0 Bugs and RFEs

 Notes about Bugs and RFEs (Request For Enhancement)

The following bugs & RFEs reflect currently open issues with the
automounter

 6.1: Bugs

1151774 extra spaces and tabs in /etc/mnttab cause odd things to happen

  As you can guess by the problem description, the automounter will
  do odd things like unmount a directory and never mount it again.

  The workaround is to clear out ANY and ALL whitespace from the
  automount map entries, and use only the TAB key to seperate
  the elements on a line e.g.
/homeTAB-retry=2TABauto_homeRETURN

1220400 lofs becomes confused about where the present working directory "."

  If you use autofs to mount local file systems on a Solaris machine,
  pwd will give you the error "cannot determine current directory!"
  while df . will give you the error "cannot canonicalize .: Error 0".
  These are due to a bug in automount under 2.4. They should have no
  other adverse effects. This is fixed under 2.5, but will not be
  patched under older OSes.
  NOTE:  This will be fixed in 101945-37

1226421, 1211172, 1207102 "dev... rdev... not in mnttab"

  There are several circumstances in which the Solaris 2.3 and 2.4
  automounter encounter these bugs.  They are fixed in 2.5 (except
  if the mount is an Andrew File System AFS mount).
  To solve this problem:  upgrade any and all automount clients to
  the latest kernel jumbo patch.  If after doing this,
  you still encounter the problem, it should only occur with a lofs
  (loopback) mount, or an AFS mount.
  If that is the case, there might be a T-patch available to fix the
  error message.
  NOTE: Patch 103059-01 fixes the lofs mount problem on 2.3!
        Patch 101945-37 will fix the lofs mount problem on 2.4.

 6.2: RFEs

We still need to provide this information - under construction

7.0 References

 7.1: Important Man Pages

automount
automountd      (Solaris only)

 7.2: Sunsolve Documents

There are a number of Sunsolve documents concerning the automounter.
The ones listed below are simply those which contain some amount of
information which is not already in this document.

7.2.1: Sun Infodocs

2090   How Does One Customize the Automounter Setup?

7.2.2: Sun SRDBs

3033   automounter gobbling cpu time
3073   Compiler embeds/tmp_mnt automounter in  .stab entries
4087   Using automounter with PCNFS 3.5

 7.3: Sun Educational Services

[pending

 7.4: Solaris Documentation

_NFS Administration Guide_, part #801-6634-10

  Information on autofs setup and administration under Solaris.

_Network and Administration_

  Manual for SunO

 7.5: Third Party Documentation

_Managing NFS and NIS_, bu Hal Stern, published by O'Reilly &
Associates, ISBN #0-937175-75-7

  A definitive source of information for the automounter under SunOS.

 7.6: RFCs

There are no automounter RFCs.

8.0 Supportability

 8.0: Supportability

SunService is not responsible for the initial configuration of your
automount environment. In addition, SunService can not diagnose your
NFS performance problems, or suggest NFS tuning guidelines.

We can help resolve problems where automount is not behaving
correctly, but in such cases the contact must be a system
administrator who has a good understanding of the automount
environment.

9.0 Additional Support

 9.0: Additional Support

For initial configuration, or NFS performance tuning guidelines,
please contact your local SunService office for possible consulting
offerings. Sun's Customer Relations organization can put you in touch
with your local SunIntegration or Sales office. You can reach Customer
Relations at 800-821-4643.

PATCH ID: n/a
PRODUCT AREA: Gen. Network
PRODUCT: Automounter
SUNOS RELEASE: any
UNBUNDLED RELEASE: n/a
HARDWARE: any