z/OS UNIX System Services Planning
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


What happens when you start the automount facility from the shell?

z/OS UNIX System Services Planning
GA32-0884-00

Figure 1 shows what happens when the automount facility is started from the shell. It shows how file systems are automatically mounted. To access the shell, type OMVS from ISPF option 6.

Figure 1. Follow-up steps when using the automount facility
# df
Mounted on     Filesystem                Avail/Total    Files      Status
/              (OMVS.ROOT)               1432/89280     0          Available
# /usr/sbin/automount                   1 
FOMF0107I Processing file /etc/u.map
FOMF0108I Managing directory /u             2 
# df                             3 
Mounted on     Filesystem                Avail/Total   Files       Status
/u             (*AMD/u)                  0/8            0          Available
/              (OMVS.ROOT)               1432/89280     0          Available
# cd /u/user1                               4 
# cd /u/slekka/testdir                      4 
# cd /u/rpetri                              4 
# df                                        5 
Mounted on     Filesystem                Avail/Total    Files      Status
/u             (*AMD/u)                  0/8            0          Available
/u/rpetri      (OMVS.RPETRI)             4256/4320      0          Available
/u/slekka      (OMVS.SLEKKA)             4232/4320      0          Available
/u/user1       (OMVS.USER1)              4232/4320      0          Available
/              (OMVS.ROOT)               1432/89280     0          Available
# ls -l /u                                  6 
Total 496
drwxr-xr-x   2 RPETRI   OMVSGRP       0 Nov  2 09:59 rpetri
drwxr-xr-x   2 SLEKKA   OMVSGRP       0 Nov  1 09:47 slekka
drwx------   2 ADMIN    OMVSGRP       0 Nov  7 09:07 user1
# chown user1 /u/user1                      7 
# ls -l /u                                  8 
Total 496
drwxr-xr-x   2 RPETRI   OMVSGRP       0 Nov  2 09:59 rpetri
drwxr-xr-x   2 SLEKKA   OMVSGRP       0 Nov  1 09:47 slekka
drwx------   2 USER1    OMVSGRP       0 Nov  7 09:07 user1
#

 ===>

ESC=¢ 1=Help    2=SubCmd 3=HlpRetrn  4=Top      5=Bottom   6=TSO
      7=BackScr 8=Scroll 9=NextSess 10=Refresh 11=FedRetr 12=Retrieve
  •  1  The automount command is being issued from a superuser ID to start the automount facility from the shell.
  •  2  The automount facility scans the /etc/auto.master file first to see what MapName file or files should be read. Here, the /u directory is being managed.

    Calling the automount command twice by mistake does not cause problems regardless of whether a file system is already mounted. The automount facility reads the /etc/auto.master file and associated MapName file or files again and then picks up any changes.

  •  3  The display free space command (df) is issued. It shows that the automount facility has been started and is managing the /u directory. Notice the (*AMD/u).
  •  4  Change directory (cd) commands are issued to access directories in the three file systems that are to be mounted from the /u directory. In this case, the directories USER1, RPETRI, and SLEKKA are used to resolve the <uc_name> symbol in the /etc/u.map file. The RPETRI, SLEKKA, and USER1 directory names are translated to uppercase and substituted to build the data set names OMVS.RPETRI, OMVS.SLEKKA, and OMVS.USER1, respectively. The RPETRI, SLEKKA, and USER1 directories do not physically exist in any file system but will be created as pseudo mount points by the automount facility on which the HFS data sets OMVS.RPETRI, OMVS.SLEKKA, and OMVS.USER1 are mounted.
  •  5  Output from another df command shows that (*AMD/u) is managing the /u directory. It also shows that the OMVS.RPETRI, OMVS.SLEKKA and OMVS.USER1 data sets are now mounted at pseudo mount points /u/rpetri, /u/slekka, and /u/user1, respectively.

    When automount is actively managing a particular mount point (in this case /u) you cannot add a file to this directory (/u) or create a new subdirectory off the /u directory using the mkdir command. If you try, you will see an allocation or catalog error.

  •  6  The ls -l /u command is issued against the /u directory and the directory attributes are displayed.
  •  7  The chown is issued to change the ownership of /u/user1 directory from ADMIN to USER1.
  •  8  The ls -l /u command is issued again to show that the owner field of the /u/user1 directory is now set to USER1.

Figure 1 shows how <uc_name> works with the /etc/auto.master and /etc/u.map files from Figure 1. The OMVS.RPETRI, OMVS.SLEKKA and OMVS.USER1 data sets have already been allocated. The low-level qualifier of the data sets is the user ID which is also the directory mount point that automount will dynamically allocate. With the automount facility, if a user tries to access any directory in their file system, the data set is automatically mounted under the /u directory.

Tips: When working with the automount facility:
  • You can use specific entries for directory names when the parameters you want to use differ from the generic entry. Any parameters that are not specified are inherited from the generic entry. A specific entry defines a directory name called wjs in the name parameter of the MapName file rather than an * as shown in Figure 1.

    In this example, the duration for generic mounts is set to unmount idle file systems after 60 minutes. But in this specific mount entry, idle file systems will stay mounted indefinitely. Also, a specific file system is specified because the file system name does not conform to the format in the generic entry. All other attributes are inherited from the generic entry.

  • To display the current automount policy, issue
    /usr/sbin/automount -q
  • You can specify the allocation parameters when using automount to allocate a data set. The specifications for the automount map file have keywords that you can use to specify allocation keywords.
Note:
  1. When a new file system of the type HFS is created and allocated to a new user, the owner UID and GID are based on that user. The setting of the permission bits is 700. By default, the automount process uses the UID and GID of the user ID that owns the process. If the euid keyword is specified for allocany or allocuser, the thread level UID and GID are used instead.
  2. When a new file system of the type ZFS is created and allocated to a new user, the owner UID and GID are based on that user. The setting of the permission bits is 750. By default, the automount process uses the UID and GID of the user ID that owns the process. If the euid keyword is specified for allocany or allocuser, the thread level UID and GID are used instead.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014