AUTOMOUNTER PSD/FAQ
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
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.
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 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.
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
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 -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_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).
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!!
Examples...
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
/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 "/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!
Symptom:
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
joes_files_appear_here
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
directory
/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 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-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
|