Administration Guide

Using automount for other file systems

If you have configured your SP with automounter support, you can use the automount daemon to provide automounting control for other file systems in your network. Each file system you want managed by automount requires an automount map file and an entry in the /etc/auto.master map file identifying the file system and its map file.

You must make sure the directory you are controlling with the automount daemon exists as a local directory on each processor and is not a symbolic link to another directory. Otherwise, the automount daemon will not start successfully.

The process to add additional file systems requires you to stop and start the automount daemon on all nodes. To do so, all activity with files and directories currently controlled by the automount daemon must be stopped. This includes all activity in users' home directories if the automount daemon is controlling the /u file system. You should plan to add all additional file systems to the automounter at a time when this would not adversely affect your system schedule or disrupt users.

The examples in this section illustrate the process for adding additional file systems and show how to provide automount support for automounting the /vol file system.

The steps in this process are:

Create an automount map file
Update the master map file
Add the map to the file collections
Distribute the map to the boot-install servers and nodes
Stop and restart the automount daemon

Step 1: Create an automount map file

The easiest way to create an automount map file is to copy an existing one and modify it for the new file system. The map can reside in any directory you like. The map for the /u file system is /etc/auto/maps/auto.u. It may be convenient for you to keep all of your automount map files in this maps directory.

Example

On the control workstation, copy the existing auto.u map and name it auto.vol, keeping it in the same directory. Enter:
```
cp /etc/auto/maps/auto.u /etc/auto/maps/auto.vol
```

Replace the map entries with the directory and host information for /vol as shown here:

inst.images  images1:/inst.images
techlib      filesrv1:/share/&
local        $HOST:/afs/site.edu/share/local

This example results in the following mounts for AIX 4.3.0 and earlier levels:

If a user issues cd /vol/inst.images, inst.images is mounted from images1 linking /vol/inst.images>/tmp_mnt/vol/inst.images
If a user issues cd /vol/techlib, /share/techlib is mounted from filesrv1 linking /vol/techlib>/tmp_mnt/vol/techlib
If a user issues cd /vol/local, automount simply creates a symbolic link because the directory is accessible from the local host. The result is /vol/local>/afs/site.edu/share/local.

This example results in the following mounts for AutoFS systems:

If a user issues cd /vol/inst.images, inst.images is mounted from images1 at the local mount point /vol/inst.images
If a user issues cd /vol/techlib, /share/techlib is mounted from filesrv1 at the local mount point /vol/techlib
If a user issues cd /vol/local, a local mount is made from /afs/site.edue/share/local to the mount point /vol/local.

Step 2: Update the master map file

Add an entry to the automount master map file /etc/auto.master so that when the automount daemon is restarted it will also control the file system being added. The entry may contain default mount options for all the directories listed in the automount map file.

Example

Add the following entry to /etc/auto.master:

/vol /etc/auto/maps/auto.vol -ro,soft,rsize=4096,wsize=4096

This will tell the automount daemon to use the /etc/auto/maps/auto.vol file when controlling access to directories within the /vol file system. The specified mount options will be used for each directory mount.

Step 3: Add the map to the file collections

If you are using file collections to distribute your map files, add the new map so that it can be distributed and managed by the file collection programs. If you have placed your map file in the /etc/auto/maps directory, you do not need to do anything for this step. The user.admin file collection already distributes all files in the /etc/auto/maps directory. However, if you have not placed your map file in the /etc/auto/maps directory, you will need to add the map to a file collection that is resident on all the systems you require. The user.admin collection is a good choice because it is resident on the control workstation, boot-install servers, and all processor nodes. See SP file collection summary for a complete list of file collections provided by the SP.

Example

Add auto.vol to the user.admin file collection so that it can be distributed to all boot-install servers and nodes. To do this, edit the file collection list file /var/sysman/sup/user.admin/list and add the following entries to request an upgrade of this new map and to refresh the daemon after the upgrade:

upgrade ./etc/auto/maps/auto.vol
execute /etc/amd/refresh_amd (./etc/auto/maps/auto.vol)

Note:: This step is not necessary for this example since the map file resides in the /etc/auto/maps directory and will already be automatically distributed. The details are provided here to illustrate how to update the file collection if the map file resides in some other directory.

Step 4: Distribute the map to the boot-install servers and nodes

If you are using file collections to distribute your map files, check to see if you have a scan file for the file collection containing the new map.

Example

If you are using the user.admin file collection to distribute your map, check if the file /var/sysman/sup/user.admin/scan exists on the control workstation or any boot-install servers. If the scan file does exist, you will need to update it. On each processor that has a scan file for the collection, enter:

supper scan user.admin

You can wait for the scheduled supper update to update the file collection as specified in the crontabs file on each processor node. Or, if you want to distribute the map immediately, use a remote command to run the supper update command first on each boot-install server and then on each node.

Example

To distribute the user.admin file collection with the new map file immediately, run the following command first on each boot-install server and then on each node:

supper update user.admin

Step 5: Stop and restart the automount daemon

In order for the automounter to recognize the update to the /etc/auto.master file and handle the new file system, the automounter must be stopped and restarted. The daemon must be stopped at a time when no users are accessing files or directories under automount control. Plan this step for a time that is not disruptive to your users.

The cleanest and safest way to stop and restart the automounter is to reboot all the systems where this new map will reside.

If it is not possible to reboot the systems, then do the following to stop the automount daemon on AIX older systems:

Issue the mount command with no parameters to get the process ID of the automount daemon and to see if there are any active mounts on the /tmp_mnt directory. This is the directory the automount daemon uses as its mount point.
Stop all processes that are accessing files or directories controlled by the automount daemon.
Stop the automount daemon with the following command using the process ID returned by the mount command:
```
kill -term process_id
```
Note:
It is important to issue the kill -term command (kill -15) and not kill -kill (kill -9) to allow the automount daemon to properly clean up its mounts and directories.

To stop AutoFS on systems with AIX 4.3.1 or later:

Issue the mount command with no parameters to see if there are any active mounts for automounter controlled directories.
Stop all processes that are accessing files or directories controlled by the automounter.
The automounter daemon is controlled by the System Resource Controller (SRC). Issue the following command to stop the AutoFS system:
```
stopsrc --g autofs
```

Restart the automount daemon by running the following command:

/etc/auto/startauto

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]