An entry for a directory is specified, as follows:

>>-directory--+--------+---------------------------------------->
              '-dirsuf-'   

>--+- -ro----------------------------------------------------------+-->
   |      .-|-----------------.                                    |   
   |      V                   |                                    |   
   +--rw=---client-+--------+-+------------------------------------+   
   |               '-clisuf-'                                      |   
   |          .-|-----------------.                                |   
   |          V                   |                                |   
   '--access=---client-+--------+-+-+----------------------------+-'   
                       '-clisuf-'   |      .-|-----------------. |     
                                    |      V                   | |     
                                    +-,rw=---client-+--------+-+-+     
                                    |               '-clisuf-'   |     
                                    '-,ro------------------------'     

>--+--------------------+--------------------------------------><
   |       .-|--------. |   
   |       V          | |   
   '--sec=---secvalue-+-'   

>>-+---------------+-------------------------------------------><
   +--symresolve---+   
   '--nosymresolve-'   

where

directory

For MVS data sets, the MVS high-level qualifier, partitioned data set name, or alias to a user catalog; the name must conform to MVS data set naming conventions. The name may be preceded by the MVS prefix.

For z/OS UNIX file systems, the entire UNIX directory path name, starting from the root. The name may be preceded by the HFS prefix.

If no prefix is specified, the implicit prefix algorithm is used for determining which file system type this entry applies to. If both implicit options are active, and are valid for this entry, then the entry will be assumed to apply to both file system types. No existence check is performed to refine the file system type selection to a single option.

For both MVS data sets and z/OS UNIX directories, wildcard symbols can be used to create regular expressions, and MVS system symbols can also be used to create regular expressions for MVS data sets.

dirsuf

Suffix for a directory to be exempt from SAF checking, even though SAF or SAFEXP is specified as the security option. This parameter emulates an entry in the NFS checklist data set prior to z/OS V1R8. Prior to z/OS V1R8, the Checklist used a one-to-one correspondence policy, that is, one checklist entry should generate one real path that was to be exempted from SAF checking. In z/OS V1R8 and later, the former checklist one-to-one correspondence policy remains unchanged; MVS system symbols and wildcard symbols must not be used in a directory if dirsuf is used together with a directory. The suffix is ignored if the checklist site attribute is not specified, or the security site attribute is not set to SAF or SAFEXP. The directory suffix can have the following values:

blank

If the security site attribute is set to SAF or SAFEXP, SAF checking is performed for this directory and its sub-directories.

<nosaf>

If the security site attribute is set to SAF or SAFEXP, SAF checking is not performed for this directory and its sub-directories. This value emulates the checklist function prior to z/OS V1R8.

<sub-directory list,nosaf>

If the security site attribute is set to SAF or SAFEXP, SAF checking is performed for this directory. However, for the specified sub_directory_list, and its sub-directories, SAF checking is not performed.

sub-directory list

A list of sub-directories separated by commas, and optionally client host lists.

sub-directory[,hosts=client_list]

sub-directory

Name of a sub-directory to which the nosaf function is to be applied. The directory name is appended to the front of each sub-directory name to generate to full name of the directory item for which no SAF checking is to be performed.

A sub-directory entry can also refer to a specific member of an MVS PDS or PDSE for which no SAF checking is to be performed: sub_directory(member).

client_list

List of client host names to which the nosaf function is to be applied. If no client_list is specified, then the function applies to all clients.

Note: The hosts=client_list specification in the directory suffix expands the checklist functionality beyond that available in prior releases. This parameter allows you to limit the checklist applicability to a subset of hosts, only those specified in the client_list.

-ro

Export the directory as read only. If not specified, the directory is exported as read/write.

-rw=client[clisuf][|client…]

The directory is exported as read/write to specified clients, and read-only to everyone else. Use a vertical bar (|) to separate client names. Client names may be specified as shown in Client id specification.

-access=client[clisuf][|client.…] [[,rw=client[|client…]] | [,ro]]

Gives access only to clients listed. Client names may be specified as shown in Client id specification.

If neither rw nor ro is specified for the -access parameter, then the clients listed have read/write access and the rest of the clients have no access.

If the rw parameter is specified for the -access parameter, the associated clients have read/write access to the directory, and the clients specified in the access list but not in the rw list have read-only access.

If the ro parameter is specified for the -access parameter, the clients in the access list have read-only access to the directory, and the rest of the clients have no access.

Use a vertical bar (|) to separate client names.

client

Name of the client to which the specification applies. Client names may be specified as shown in Client id specification.

clisuf

The client suffix can be specified to give root access to the root user of the specified client. The client suffix can have the following values:

blank

If no MVSLOGIN has been done, the id of root users from the client system are converted to id=nobody (-2) before access permissions are checked. This means that there is a good chance that root users will be denied access to the directory while other users from that client have access.

<root>

If no MVSLOGIN has been done, root users from the client system are given root access to this directory and its subdirectories (that is, the user is treated as a trusted user).

-sec=secvalue

Specifies the acceptable level of network transmission security access that a client's RPC request must provide. If a client attempts to access an object in the directory using a network security level that is not specified on the sec parameter, the access is denied.

krb5

Provides Kerberos V5 based integrity on the RPC credentials (but not data), when the RPC authentication flavor is RPCSEC_GSS. It uses the DES_MAC_MD5 integrity algorithm and the RPCSEC_GSS service of rpc_gss_svc_none.

krb5i

Provides Kerberos V5 based integrity on both the RPC credentials and data, when the RPC authentication flavor is RPCSEC_GSS. It uses the DES_MAC_MD5 integrity algorithm and the RPCSEC_GSS service of rpc_gss_svc_integrity.

krb5p

Provides Kerberos V5 based integrity and privacy on both the RPC credentials and data, when the RPC authentication flavor is RPCSEC_GSS. It uses the DES_MAC_MD5 algorithm for integrity and 56 bit DES for privacy. The RPCSEC_GSS service used here is rpc_gss_svc_privacy.

sys

Specifies that the AUTH_SYS authentication flavor can also be used to access this file system. Note that the AUTH_SYS authentication flavor does not provide any integrity or privacy protection.

Use a vertical bar (|) to separate security levels.

If the sec parameter is provided, it further restricts the network transmission protection of specific export entries, in the domain of the file system wide network transmission protection, which is controlled by the mvssec, hfssec, or pubsec site attributes. When this parameter is not specified, the allowed security levels are governed by the mvssec, hfssec, and pubsec site attributes.

-symresolve

The symbolic link (symlink) in the directory path is resolved at time of z/OS NFS Client access to the directory. New Export entry is created in memory with a real directory path.

Note:

1. Only absolute paths are supported; symlinks pointing to relative paths are not supported.
2. If the path of a symlink is changed, an EXPORTFS command must be run to allow z/OS NFS Server to re-interpret the new symlink path at the next mount.
3. For effects of using the showmount command, see Using commands on the z/OS NFS client

-nosymresolve

The symlink in the directory path is not resolved.