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

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

The automounter can best be debugged using a simple strategy:

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

The automounter leaves much information in /etc/mnttab, /etc/mtab
on SunOS 4.X.  There will be an entry for each indirect map
specified in the master map, and also for each direct map entry.

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

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:
  # 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    

...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/        -ro
  /home /etc/auto.home
In this example, /etc/ 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 map may read:
  % cat /etc/
  /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
  # 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 NIS map, and the /home listing from the auto.home
NIS map:
  # cat /etc/auto.master
  /-     -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

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:
So, using only files, your auto_master should look something like
  # 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
  /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
[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, since that is the older NIS standard. So, the above
would work fine if you were using NIS, and the actual NIS map was
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 >
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
  /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
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 map, you need to make a new entry in
/var/yp/Makefile for, mimicking the already existing
auto.home entry:  $(DIR)/
        -@if [ -f $(DIR)/ ]  then \
                sed -e "/^#/d" -e s/#.*$$// $(DIR)/ \
                  $(MAKEDBM) - $(YPDBDIR)/$(DOM)/  \
                touch  \
                echo "updated"  \
                if [ ! $(NOPUSH) ]  then \
                $(YPPUSH)  \
                        echo "pushed"  \
                else \
                :   \
                fi \
        else \
                echo "couldn't find $(DIR)/"  \

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

In addition, 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
And, finally, near the bottom, the following line must be added:
[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/ 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`/* 
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 -v

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.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
  # cat /etc/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 

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

Q:  Solaris automounter, can't seem to mount a directory in certain 
    cases.  Other times it can.  Why so erratic?  How can we fix this?

A:  This is a case where either automount debug mode, or snoop will show
    that the mount failed, and that the automounter never retried 
    the mount.  Try adding a retry=2 to the map entry for slow servers,
    so that the automounter will retry the mount 2 times if the first
    mount fails.  CAUTION:  this can "hold up" other automount
    requests for 15 seconds per retry specified, on some versions of 
    Solaris.  Do not make this value much larger than 2!!  

    Of an auto_master:
    /home	auto_home	-retry=2

    Of an auto_direct:
    /var/mail -actimeo=0,retry=2 mailgate:/var/spool/mail

    Of an auto_home:
    testhack:	-retry=2	testserv:/export/home/testhack
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

 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 "/net -hosts" or "/nfs -hosts".
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.

4.8  I Can NFS Mount a Directory, but Automounter Can't!


cd /home/joe fails with "not found".

You try to see if you can NFS mount it, and you find
that an NFS mount works and you can access the directory:

mount server:/export/joe /mnt
ls /mnt

Solutions to check:

1.  Are your automount maps correct?  Check the /etc/mnttab
    see if the automount entry appears for the automount
    map.  This example looks for an INDIRECT map auto_home:

$ grep home /etc/mnttab
auto_home /home autofs ignore,indirect,dev=28c0003 842531300
                ^^^^^^        ^^^^^^^^
*** The "autofs" entry is the automount map - if you don't see
    the map entry, fix your auto_master and/or auto_home map
    per the config guidelines elsewhere in this tips sheet.

server:/export/joe /home1/joe nfs dev=2880002 842531353
*** This is the NFS entry.  You WON'T see this if the NFS mount
    attempt by automount failed! 

    This next example looks for a DIRECT map entry from auto_direct:

auto_direct /test/stuff autofs ignore,direct,dev=28c0001 842531300
                        ^^^^^^        ^^^^^^

2.  OK, so your automount maps are correct, you can NFS mount
    the directory by hand, so why didn't the automounter do the mount?

    The most likely reason is this:  unlike the "mount" command,
    the automounter sends out ONE MOUNT REQUEST OVER THE NET.
    If there isn't a response in 15 seconds, the automounter
    gives up (we're talking
SOLAR/net/osseast.east/sunsolvehome/data/patches/103049: No such file or
/net/osseast.east/sunsolvehome/data/patches/103493: No such file or directory
/net/osseast.east/sunsolvehome/data/patches/103154: No such file or directory
/net/osseast.east/sunsolvehome/data/patches/104056: No such file or directory
/net/osseast.east/sunsolvehome/data/patches/103929: No such file or directory
IS 2.X here -- forget SunOS 4.X
    we think it will hang until the mount completes).

    You can use the NFS mount option of "retry=N" to give the
    automounter some retry attempts.  DON'T MAKE "N" VERY LARGE
    because the automounter will hang.  This will give the
    automounter "N" more retries at the mount (spaces 15 secs
    apart.  I would recommend 2 or 3 at most (45 to 60 secs
    hang of the automount if the server is really down).

    I would make the change in the MASTER map.  Here is
    an example to make all mounts of /home have retry=3:

/home auto_home -retry=3

    This is how it will appear in the /etc/mnttab:
auto_home /home autofs ignore,indirect,retry=3,dev=28c0002 842531300
                ^^^^^^        ^^^^^^^^^^^^^^^^

     Here is how you would modify just 1 entry in the auto_direct
     map for a slow server for the /test/stuff directory:

/test/stuff -retry=3 slowhost:/export/junk/stuff

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


101318-82 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-45 SunOS 5.4: jumbo patch for kernel  
101946-39 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.

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  

 SunOS 5.5x86: autofs is not MT-safe  

103153-11 SunOS 5.5: fsck, ufs & lofs patch  

 SunOS 5.5x86: fsck, ufs & lofs patch  

Solaris 2.5.1 and 2.5.1x86:

104055-01 SunOS 5.5.1: automountd doesn't umount the hsfs filesystem  
 SunOS 5.5.1x86: automountd doesn't umount the hsfs filesystem  

103928-01 SunOS 5.5.1: lo_sync() should not flush the underlying filesystem  
 SunOS 5.5.1x86: lo_sync() should not flush the underlying filesystem 

Paid Advertisements: