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
No comments:
Post a Comment