automount — Configure the automount facility

Format

automount [–aeqs] [master_file_name]
automount –f filesystem_name

Description

automount is used to configure the automount facility. The automount facility can automatically mount file systems at the time they are accessed, and also unmount them later. You can use a single automount policy to manage both HFS and zFS file systems. For information about setting up the automount facility, see z/OS UNIX System Services Planning.

automount requires superuser authority.

Run automount from the /etc/rc script with no arguments. This action processes the installation's default automount configuration file. When run with no arguments, automount reads the /etc/auto.master file to determine all directories that are to be configured for the automount and the file names that contain their configuration specifications.

Note: The /etc/auto.master file contains the directory or directories that the automount facility will monitor. It also contains an associated MapName file that contains the mount parameters. The name of the map file can be specified as an MVS™ data set name. The data set name must be specified as a fully qualified name and can be uppercase or lowercase. Single quotation marks are not needed.

If the automount policy is loaded, you will get a return code of 0. A nonzero return code indicates that the policy was not loaded.

The automount file system (*AMD/) is mounted with an automove attribute of either AUTOMOVE or UNMOUNT. The automove attribute is set to UNMOUNT only when its parent file system has its automove attribute set to UNMOUNT. When the automove attribute is set to UNMOUNT, the owning system of the automount file system is identical to the owning system of the parent.

If you run automount with the [master filename] argument, that file name is used instead of /etc/auto.master.

Tip: zFS is the preferred file system and continued use of HFS is discouraged. New file systems should be created as zFS file systems.

Options

–a

Indicates that the policy being loaded is to be appended to the existing policy rather than replace the existing policy. For example:

/usr/sbin/automount -a

–a is mutually exclusive with –q.

–e

Displays recent error information from automount attempting to create a new zFS or HFS file system. Typically, one allocation error value and reason code is displayed for the last allocation error, if there was one. If a zFS file system could not be created, you will see message text or error and reason codes (or both) for each automount-managed directory where the zFS file system was to be created.

–f

Displays the information of the job that last accessed the specified file system. The file system name must be specified and it is treated as case-insensitive. All automount managed file systems that match is reported. The information includes file system name, mount point, state, timer, UID, PID, and job name. The state has two values: duration and delay. The timer is the minutes that remain for the specified file system to be in this state.

–q

Displays the current automount policy. –q is mutually exclusive with –a.

–s

Checks the syntax of the configuration file. No automount is performed.

Examples

The following example shows how automatic unmount can be avoided for a directory:
```
name       wjs
duration   nolimit
```
Keywords that are not specified on a specific entry are inherited from the generic entry, if present. If the generic entry is not present, or if keys are not specified, the defaults are used. If the file system key cannot be resolved, the entry is considered invalid. The filesystem attribute for a specific entry must already exist, and will never be created using the inherited allocany values.
The following example is a /etc/auto.master file that is used to specify /u as automount-managed and the specifications for that directory in /etc/u.map:
```
/u       /etc/u.map
```

Files

automount uses these files:

/etc/auto.master

Specifies a list of directories to be configured, along with their MapName files.

Each line in this file contains two path names that are separated by at least one space: the directory name to be managed and the path name of the MapName file. Both of these path names must be absolute.

The path name of the managed directory is used as a file system name prefixed with *AMD/. This restricts the length of the path name of a managed directory to 40 characters. If path names need to be longer, you can use symbolic links to resolve all or part of the path name.

Blank lines and lines beginning with the characters /* are considered comments and are ignored. Line comments are not tolerated

Tip: While MVS system symbols can be used in master files such as &ZOSREL, only use static system symbols in order to avoid unexpected results. The symbols are resolved when the automount policy is loaded. If the symbol is dynamically changed after the policy is loaded, the policy must be reloaded in order to have the symbol resolved again. To display the symbol substitution, use the automount -q option.

MapName

The MapName file contains the mapping between a subdirectory of a directory managed by automount and the mount parameters.

The file is organized as a set of specifications. Each specification contains one or more lines. Each line is of the form keyword argument. Each specification must begin with the keyword name.

Blank lines and lines that begin with the characters * are considered comments and are ignored. Line comments are not tolerated.

A line can be continued by having a backslash character (\) at the end. The leading tabs and blanks in the continuation lines are ignored. The tabs and blanks before the continuation character (\) in the continued lines are not ignored. For example:

parm mynfs.ibm.com:/SY1/tmp/fs1/abcd\
efgh/myfs,\
XLAT(Y)

A generic entry can be specified as the first specification by using the name of *. The generic specification provides defaults for subsequent specific specifications. When the automount facility tries to resolve a lookup request, it attempts to find a specific entry. If a specific entry does not exist for the name that is being looked up, it attempts to use the generic entry.

The following example shows a generic entry:

name           *
type           HFS
filesystem     OMVS.HFS.USER.<uc_name>
mode           rdwr
duration       30
delay          10
parm           SYNC(60)
tag	           text,819

These special symbols provide name substitution:

<asis_name> used to represent the name exactly, as is.
<uc_name> used to represent the name in uppercase characters.
<sysname> or &SYSNAME. used to substitute the system name.

Use &SYSNAME. because <sysname> is only temporarily supported for compatibility.

You can use these symbols when specifying a file system name or file system parameter that has a specific form with the name inserted as a qualifier.

Following is a list of supported keywords. You can enter keywords using mixed case letters. Some arguments require mixed case. The allocany, allocuser, and lowercase keywords are valid on any specification, but are meaningful only on the generic entry.

Note: The filesystem attribute for a specific entry must already exist, and will never be created using the inherited allocany values.

allocany allocation-spec

Specifies the allocation parameters when using automount to allocate HFS or zFS file systems, keeping in mind that zFS is the preferred file system. Specifying the allocany keyword causes an allocation if the data set does not exist for any name looked up in the automount-managed directory.

The automount facility creates a new zFS file system as an HFS-compatible file system if the file system that was specified in the automount policy does not already exist. Space for zFS file systems is always assumed to be in units of cylinders regardless of other specifications. All other allocation keywords that can be used for HFS can be specified but will be ignored. However, the syntax must be correct. These restrictions are in place so that migration to zFS or back to HFS will require minimal changes to the automount policy. See usage note 5.

allocation–spec

A string that specifies allocation keywords. The keywords in Table 1 can be specified in the string.

Table 1. Allocation-spec keywords for allocany and allocuser
Keyword	zFS	HFS	Explanation
space	Applied	Applied	Specifies primary and optional secondary space allocations.
cyl \| tracks \| block	Applied	Applied	Specifies the unit of space in cylinders, tracks, or blocks.
vol	Applied	Applied	Specifies the serial numbers for eligible direct access volumes where the data set is to reside.
maxvol	Ignored	Applied	Number of volumes for a multivolume data set.
unit	Ignored	Applied	Specifies the unit name, device type, or unit address.
storclas	Applied	Applied	Specifies the storage class for the data set.
mgmtclas	Applied	Applied	Specifies the management class for the data set.
dataclas	Applied	Applied	Specifies the data class for the data set.
pathperm	Applied	Not supported	Specifies permission to the root directory. Requirement: In order to use the pathperm keyword, all systems in a shared file system configuration must be at least the z/OS® V2R1 level.
euid	Applied	Applied	The new data set owner is set to the effective UID and GID.

Example:

An example of allocany is as follows:

allocany         space(100,20) cyl vol(MYDISK) pathperm(777) euid

allocuser allocation–spec

Specifies the allocation parameters when using automount to allocate HFS or zFS file systems, keeping in mind that zFS is the preferred file system. Allocation occurs only if the name being looked up matches the user ID of the current user.

The automount facility creates a new zFS file system as an HFS-compatible file system if the file system that was specified in the automount policy does not already exist. Space for zFS file systems is always assumed to be in units of cylinders regardless of other specifications. All other allocation keywords that can be used for HFS can be specified but are ignored. However, the syntax must be correct. These restrictions are in place so that migration to zFS or back to HFS will require minimal changes to the automount policy. See usage note 5.

allocation–spec: A string that specifies allocation keywords. The keywords in Table 1 can be specified in the string.

charcase [lower|upper|asis]

Indicates the case for names that can match the * specification. This keyword is valid on any specification but is only meaningful on the generic entry. This keyword is mutually exclusive with the lowercase keyword.

lower: Only names that are composed of lowercase characters can match the * specification. Numbers and special characters can also be used. When this keyword is specified, uppercase characters are not allowed. This option is equivalent to lowercase yes.
upper: Only names that are composed of uppercase characters can match the * specification. Numbers and special characters can also be used. When this keyword is specified, lowercase characters are not allowed.
asis: Any name can match the * specification. This keyword is the default and is equivalent to lowercase no.

delay

The minimum amount of time in minutes to leave the file system mounted after the duration expires and the file system is no longer in use. The default is 10.

Tip: In a shared file system environment, specify a delay time of at least 10.

duration

The minimum amount of time in minutes to leave the file system mounted. The default is nolimit.

filesystem

The name of the file system to mount. This argument is case-sensitive. For the HFS file system, this argument must be specified in uppercase.

Restriction: Symbol symbolics that are used by the file system name template cannot be more than 44 characters long. Symbolics that are used for the automount (<sysname>, <asis_name>, <us_name>) are resolved within automount as part of checking the length of the file system name template.

lowercase [Yes|No]

Indicates the case for names that can match the * specification. This keyword is valid on any specification, but is only meaningful on the generic entry. It is also mutually exclusive with the charcase keyword.

Yes: Only names that are composed of lowercase characters can match the * specification (numbers and special characters can also be used). When this is specified, uppercase characters are not allowed. Yes is equivalent to charcase lower.
No: Any names can match the * specification. This is the default and is equivalent to charcase asis.

mode

The mount mode for the file system (rdwr or read). The default is rdwr.

name

The name of the directory to be mounted. This key is required and must be the first key that is specified for the entry. If the first entry specifies name *, it is treated as the generic entry for the automount-managed directory.

parm

The file system-specific parameter. This argument is case-sensitive. For example, the following parameters can be specified for an HFS file system:

parm   SYNC(t),NOWRITEPROTECT

security [Yes|No]

Specifies security checking for files in the file system. You can specify these values:

Yes

Normal security checking is done. Yes is the default.

No

Specifies that security checks will not be enforced for files in this file system. Any user can access or change any file or directory in any way.

Security auditing will still be performed if the installation is auditing successes.

The SETUID, SETGID, APF, and Program Control mode bits can be turned on in files from this file system, but are not honored while it is mounted with NOSECURITY. When a file system is mounted with the NOSECURITY option enabled, any new files or directories that are created are assigned an owner of UID 0, no matter what UID issued the request.

Tip: The installation should normally take the default (Yes).

For more information about mounting with no security and on the MOUNT statement in BPXPRMxx, see z/OS UNIX System Services Planning. Security keywords on the TSO MOUNT command are also discussed in mount — Logically mount a file system.

setuid [Yes|No]

Specifies whether the setuid and setgid mode bits are to be respected for executables run from this file system. You can specify these values:

Yes: The setuid and setgid modes are respected. Yes is the default.
No: The setuid and setgid modes are ignored.

tag (text|notext,ccsid)

Specifies whether file tags for untagged files in the mounted file system are implicitly set. Either text or notext, and ccid (coded character set identifier) must be specified when tag is specified:

text: Specifies that each untagged file is implicitly marked as containing pure text data that can be converted.
notext: Specifies that none of the untagged files in the file system are automatically converted during file reading and writing.
ccsid: Identifies the coded character set identifier to be implicitly set for the untagged file. ccsid is specified as a decimal value from 0 to 65535. However, when text is specified, the value must be between 0 and 65535. Other than this, the value is not checked as being valid and the corresponding code page is not checked as being installed.
For more information about file tagging, see z/OS UNIX System Services Planning. More information about the TAG parameter can be found in mount — Logically mount a file system.

type

The type of the file system (such as HFS, zFS, and NFS). The default is HFS.

Usage notes

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, automount 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.
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 permission is set to the value of pathperm (the default is 750). If permission is not specified, or if the value is 000, the default is used. To display the pathperm value, whether or not it is specified for allocany and allocuser, use the automount -q option. By default, automount uses the UID and GID of the user ID owning the process. If the euid keyword is specified for allocany or allocuser, the thread-level UID and GID are used instead.
The syntax of the automount master file is extended to optionally include the name of the filter utility. Each line contains:
- The path name of the directory that is to be managed.
- The path name of the map file.
- An optional path name of the conversion utility.
If a conversion utility is specified, automount runs that utility and provide the specified map file as the standard input for the utility. It processes the standard output from the utility as the automount map file and list it on its standard output. Errors that are detected by the automount facility are flagged the same as before, but line numbers will refer to the line as output from the conversion utility rather than the original map file that the utility processes.
automount recognizes the type specification in the automount map files of HFS and zFS as potentially interchangeable file system types. At the time automount applies the specification for the mount, it determines if the file system is the name of either an zFS or HFS file system and alters the type as appropriate. If the data set does not exist and if allocany or allocuser is specified, a new file system is allocated as the file system type as specified in type. Allocation is only done if allocany or allocuser is specified. If it is preferred to have new file systems allocated as zFS file systems, the automount policy should be changed to specify type zFS.
This allows automount-managed file systems to be changed from HFS to zFS without changing the file system name and without changing the automount policy. If the file system name must be changed, it is necessary to add a specific entry in the automount policy for this file system or manage it on another managed directory.
When the allocation-spec keyword TRACKS or BLOCK is specified in either the allocany or allocuser option for zFS file systems, the specified SPACE( ) units are converted to approximate CYL equivalent units before the zFS file system is allocated.
The following formulas are used to do the conversion into CYL units:
```
1 TRACKS Unit = 1/15 CYL Unit
1 BLOCK Unit = 1/180 CYL Unit
```
The conversion that is used does not consider the device type.
The /// placeholder is supported when used with the allocany or allocuser keywords in automount policy files to create new file systems.
The steps for preparing RACF® in z/OS UNIX System Services Planning z/OS UNIX System Services Planning include a suggestion to make the kernel address space trusted. If you did not make the local address space trusted, you must give the kernel access to the local data sets as described in Step 5.

If allocany and allocuser are used, the kernel address must be trusted or mount failures will occur. Also, if zFS is being used, then the zFS started task address space must also be trusted in order to properly identify the data set as ZFS. This task is described in the section on installing RACF in z/OS Distributed File Service zFS Administration.

Related information

chmount, mount, unmount