MOUNT - Logically mount a file system

Description

Use the MOUNT command to logically mount, or add, a mountable file system to the file system hierarchy. You can unmount any mounted file system using the UNMOUNT command. For descriptions of the valid MOUNT parameters for the zFS file system, see Mount in z/OS File System Administration.

For options that are specific to the temporary file system (TFS), see Mounting the TFS in z/OS UNIX System Services Planning.

You must have mount authority before you can issue the MOUNT command. For more information, see Mounting file systems in z/OS UNIX System Services Planning. The TSO MOUNT and UNMOUNT commands perform privileged operations if the user has read access to the BPX.SUPERUSER resource in the FACILITY class.

filesystem(file_system_name)

Specifies the name of the file system to be added to the file system hierarchy.

file_system_name

For the z/OS® UNIX file system, file_system_name is the fully qualified name of the z/OS UNIX file system data set that contains the file system. It cannot be a partitioned data set member.

The file system name that is specified must be unique among previously mounted file systems. The file system name that is supplied is changed to all uppercase characters. You can enclose it in single quotation marks, but they are not required.

If file system('''file_system_name''') is specified, the file system name is not converted to uppercase.

FILESYSTEM, BIND, RBIND, MOVE, and MAKE[PRIVATE | UNBINDABLE | RPRIVATE | RUNBINDABLE] are mutually exclusive, but one must be specified. FILESYSTEM is optional for file systems types. PFSes that support not specifying a file system name are TFS, UFS, and PROC. When a file system name is not provided to PFSes that support the name as optional, a file system is dynamically created as *PPPXXXXXXXX where PPP is the name of the PFS in caps and XXXXXXXX is the file system’s device number in hexadecimal.

MOUNTPOINT(pathname)

Specifies the path name of the mount point directory, the place within the file hierarchy where the file system is to be mounted. This operand is required.

pathname

Specifies the path name of the mount point. pathname must be enclosed in single quotation marks. The name can be a relative path name or an absolute path name. A relative path name is relative to the working directory of the TSO/E session (usually the HOME directory). Therefore, you should usually specify an absolute path name. It can be up to 1023 characters long. Path names are case-sensitive, so enter the path name exactly as it is to appear.

When you specify the path name, remember the following rules:

1. The mount point must be a directory. Any files in that directory are inaccessible while the file system is mounted.
2. Only one file system can be mounted to a mount point at any time.

TYPE(file_system_type)

Specifies the type of file system that will perform the logical mount request. The system converts the TYPE operand value to uppercase letters. This operand is required.

file_system_type

This name must match the TYPE operand of the FILESYSTYPE statement that activates this physical file system in the BPXPRMxx parmlib member. The file_system_type value can be up to 8 characters long.

MODE(RDWR|READ)

Specifies the type of access the file system is to be opened for.

RDWR

Specifies that the file system is to be mounted for read and write access. RDWR is the default if MODE is omitted.

READ

Specifies that the file system is to be mounted for read-only access.

The z/OS UNIX file system allows a file system that is mounted with the MODE(READ) option to be shared as read-only with other systems that share the same DASD.

PARM('parameter')

Specifies a parameter string to be passed to the file system type. The parameter format and content are specified by the file system type.

Refer to the following documentation for the appropriate file system-specific options:

• For zFS-specific options, see Mount in z/OS File System Administration.
• For NFS-specific options, see Mount processing parameters in z/OS Network File System Guide and Reference.
• For TFS-specific options, see Mounting the TFS in z/OS UNIX System Services Planning
• For UFS-specific options, see Mounting a union file system in z/OS UNIX System Services Planning.

TAG(NOTEXT|TEXT,ccsid)

Specifies whether the file tags for untagged files in the mounted file system are implicitly set. File tagging controls the ability to convert a file's data during file reading and writing. Implicit, in this case, means that the tag is not permanently stored with the file. Rather, the tag is associated with the file during reading or writing, or when stat() type functions are issued. Either TEXT or NOTEXT, and ccsid must be specified when TAG is specified.

When the file system is unmounted, the tags are lost.

NOTEXT

Specifies that none of the untagged files in the file system are automatically converted during file reading and writing.

TEXT

Specifies that each untagged file is implicitly marked as containing pure text data that can be converted.

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.

SETUID|NOSETUID

Specifies whether the SETUID and SETGID mode bits on executables in this file system are respected. Also determines whether the APF extended attribute or the Program Control extended attribute is honored.

SETUID

Specifies that the SETUID and SETGID mode bits be respected when a program in this file system is run. SETUID is the default.

NOSETUID

Specifies that the SETUID and SETGID mode bits not be respected when a program in this file system is run. The program runs as though the SETUID and SETGID mode bits were not set. Also, if you specify the NOSETUID option on MOUNT, the APF extended attribute and the Program Control extended attribute are not honored.

WAIT|NOWAIT

Specifies whether to wait for an asynchronous mount to complete before returning.

WAIT

Specifies that MOUNT is to wait for the mount to complete before returning. WAIT is the default.

NOWAIT

Specifies that if the file system cannot be mounted immediately (for example, a network mount must be done), then the command will return with a return code indicating that an asynchronous mount is in progress.

SECURITY|NOSECURITY

Specifies whether security checks are to be enforced for files in this file system. When a z/OS UNIX 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.

SECURITY

Specifies that normal security checking is done. SECURITY is the default.

NOSECURITY

Specifies that security checking will not be enforced for files in this file system. A 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 attributes can be turned on in files in this file system, but they are not honored while it is mounted with NOSECURITY.

SYSNAME(sysname)

For systems participating in shared file system, SYSNAME specifies the particular system on which a mount should be performed. This system will then become the owner of the file system mounted. This system must be IPLed with SYSPLEX(YES).

IBM® recommends that you omit the SYSNAME parameter or specify SYSNAME(system_name) where system_name is the name of this system.

sysname

sysname is a 1-8 alphanumeric name of a system participating in shared file system.

AUTOMOVE(indicator,sysname1,...,sysnameN)|NOAUTOMOVE|UNMOUNT

These parameters apply only in a sysplex where systems are exploiting the shared file system capability. They specify what is to happens to the ownership of a file system when a shutdown, PFS termination, dead system takeover, or file system move occurs. The default setting is AUTOMOVE where the file system is randomly moved to another system (no system list used).

Indicator is either INCLUDE or EXCLUDE, which can also be abbreviated as I or E

AUTOMOVE

AUTOMOVE indicates that ownership of the file system can be automatically moved to another system in a shared file system. AUTOMOVE is the default.

AUTOMOVE(INCLUDE,sysname1,sysname2,...,sysnameN) or AUTOMOVE(I,sysname1,sysname2,...,sysnameN)

The INCLUDE indicator with a system list provides an ordered list of systems to which the file system's ownership could be moved. sysnameN may be a system name, or an asterisk (*). The asterisk acts as a wildcard to allow ownership to move to any other participating system. It is only permitted in place of a system name as the last entry of a system list.

AUTOMOVE(EXCLUDE,sysname1,sysname2,...,sysnameN) or AUTOMOVE(E,sysname1,sysname2,...,sysnameN)

The EXCLUDE indicator with a system list provides a list of systems to which the file system's ownership should not be moved.

NOAUTOMOVE

NOAUTOMOVE prevents movement of the file system's ownership in some situations.

UNMOUNT

UNMOUNT allows the file system to be unmounted in some situations.

Follow these guidelines when unmounting the file system:

1. Define your version and sysplex root file systems as AUTOMOVE, and define your system-specific file systems as UNMOUNT.
2. Do not define a file system as NOAUTOMOVE or UNMOUNT and a file system underneath is as AUTOMOVE. In this case, the file system defined as AUTOMOVE is not recovered after a system failure until the failing system is restarted.

For more information about sharing file systems in a sysplex, see Sharing file systems in a sysplex in z/OS UNIX System Services Planning.

1. The /samples directory contains sample MOUNT commands (called mountx).
2. When the mount is done asynchronously (NOWAIT was specified and return code 4 was returned), you can determine if the mount has completed with one of the following:
   • The df shell command
   • The DISPLAY OMVS,F operator command
   • The MOUNT table option on the File Systems pull-down in the ISPF Shell (accessed by the ISHELL command)
3. In order to mount a file system as the system root file system, the caller must be a superuser. Also, a file system can only be mounted as the system root file system if the root file system was previously unmounted.
4. If you have previously unmounted the root file system, a dummy file system or SYSROOT is displayed as the current root file system. During the time when SYSROOT is displayed as the root, any operation that requires a valid file system will fail. When you subsequently mount a new root file system on mount point /, that new file system will replace SYSROOT. When a new root file system has been mounted, you should terminate any current dubbed users or issue a chdir command, using a full path name to the appropriate directory. This way, the users can access the new root file system. Otherwise, an error will occur when a request is made requiring a valid file system.
5. Systems exploiting shared file system will have I/O to an OMVS couple data set. Because of these I/O operations to the CDS, each mount request requires additional system overhead. You will need to consider the effect that this will have on your recovery time if a large number of mounts are required on any system participating in shared file system.
6. The TAG parameter is intended for file systems that don't support storing the file tag, such as NFS remote file systems.
7. Do not use the TAG parameter simultaneously with the NFS Client Xlate option. If you do, the mount will fail.
8. The UNMOUNT keyword is not available to automounted file systems.

BIND

Accesses part of the file system hierarchy somewhere else. After a bind mount, accessing SOURCEPATH and MOUNTPOINT result in the same contents. A bind mount can also be used to access the contents of a file from two locations such that reading from SOURCEPATH or MOUNTPOINT results in the same contents. Also, you can create a new mount point by bind mounting a directory to itself. A bind mount will result in a dynamically created file system name of *BINDXXXXXXXX where XXXXXXXX is the file system’s device number in hexadecimal.

FILESYSTEM, BIND, RBIND, MOVE and MAKE[PRIVATE | UNBINDABLE | RPRIVATE | RUNBINDABLE] are mutually exclusive, but one must be specified.

RBIND

The bind option does not cross mount points. It does not automatically allow access to file systems mounted underneath it. With the rbind option, all sub-mounts are recursively mounted underneath the bind mount.

FILESYSTEM, BIND, RBIND, MOVE and MAKE[PRIVATE|UNBINDABLE|RPRIVATE| RUNBINDABLE] are mutually exclusive, but one must be specified.

MOVE

Move an existing mount point pointed to by SOURCEPATH to a new location MOUNTPOINT. The file system is not unmounted. Only the location of the mount point has changed.

FILESYSTEM, BIND, RBIND, MOVE and MAKE[PRIVATE|UNBINDABLE|RPRIVATE|RUNBINDABLE] are mutually exclusive, but one must be specified.

This option is disabled.

MAKE[PRIVATE|UNBINDABLE|RPRIVATE|RUNBINDABLE]

Makes a mount point either private or unbindable. A private mount point does not affect other mount namespaces. Private is the default. An unbindable mount point prevents bind mounts from occurring on that file system. An unbindable mount point is also a private mount point. The rprivate and runbindable options will recursively mark any sub-mounts as private or unbindable.

FILESYSTEM, BIND, RBIND, MOVE and MAKE[PRIVATE | UNBINDABLE | RPRIVATE | RUNBINDABLE] are mutually exclusive, but one must be specified.

SOURCEPATH(pathname)

Specifies the source path name for the mount. For BIND and RBIND, this is the location that will now be accessible by MOUNTPOINT. For MOVE, this is the new location for MOUNTPOINT. This operand is required with BIND, RBIND and MOVE.

pathname must be enclosed in single quotation marks. The name can be a relative path name or an absolute path name. A relative path name is relative to the working directory of the TSO/E session (usually the HOME directory). Therefore, you should usually specify an absolute path name. It can be up to 1023 characters long. Path names are case-sensitive, so enter the path name exactly as it is to appear.

File system recovery and TSO MOUNT

File system recovery in a shared file system environment takes into consideration file system specifications such as AUTOMOVE | NOAUTOMOVE | UNMOUNT, and whether or not the file system is mounted read-only or read/write.

Generally, when an owning system fails, ownership over its AUTOMOVE mounted file systems is moved to another system and the file is usable. However, if a file system is mounted read/write and the owning system fails, then all file system operations for files in that file system will fail. This is because data integrity is lost when the file system owner fails. All files should be closed (BPX1CLO) and reopened (BPX1OPN) when the file system is recovered.

For file systems that are mounted read-only, specific I/O operations that were in progress at the time the file system owner failed may need to be re-attempted. Otherwise, the file system is usable.

In some situations, even though a file system is mounted AUTOMOVE, ownership of the file system may not be immediately moved to another system. This may occur, for example, when a physical I/O path from another system to the volume where the file system resides is not available. As a result, the file system becomes unowned (the system will issue message BPXF213E when this occurs). This is true if the file system is mounted either read/write or read-only. The file system still exists in the file system hierarchy so that any dependent file systems that are owned by another system are still usable.

However, all file operations for the unowned file system will fail until a new owner is established. The shared file system support will continue to attempt recovery of AUTOMOVE file systems on all systems in the sysplex that are enabled for shared file system. Should a subsequent recovery attempt succeed, the file system transitions from the unowned to the active state.

Applications using files in unowned file systems must close (BPX1CLO) those files and reopen (BPX1OPN) them after the file system is recovered.

File systems that are mounted NOAUTOMOVE will become unowned when the file system owner exits the sysplex. The file system will remain unowned until the original owning system restarts or until the unowned file system is unmounted. Since the file system still exists in the file system hierarchy, the file system mount point is still in use.

An unowned file system is a mounted file system that does not have an owner. The file system still exists in the file system hierarchy. As such, you can recover or unmount an unowned file system.

File systems associated with a 'never move' PFS will be unmounted during dead system recovery. For example, TFS is a 'never move' PFS and will be unmounted, as well as any file systems mounted on it, when the owning system leaves the sysplex.

As stated in the usage notes, the UNMOUNT keyword is not available to automounted file systems. However, during dead system recovery processing for an automounted file system (whose owner is the dead system), the file system is unmounted if it is not being referenced by any other system in the sysplex.

Return codes

0

Processing successful.

4

Processing incomplete. An asynchronous mount is in progress.

12

Processing unsuccessful. An error message has been issued.