Configuring the NFSv4 server on z/OS

Edit online

This topic describes how to configure the NFS server on z/OS.

Several data sets and files require your attention. See File samples for z/OS and z/OS UNIX for examples.

z/OS
hlq.PARMLIB(BPXPRMxx) must include the initial mount statements on z/OS and a link to the user alias table in z/OS UNIX.

hlq.PARMLIB(<dynamic vipa configuration>) must include a VIPA range definition that includes the NFS server VIPA IP address.

With NFSv4, you do not need to define SRCIP for the NFS VIPA. In a NFSv4-onlyconfiguration, you could remove the SRCIP statements for the NFS VIPA. In a mixed configuration with NFSv3 and NFSv4 you should keep the SRCIP statements for the NFS VIPA.

hlq.PARMLIB(<NFS exports>) must include the file system export statements. Allow root access for the NFS client to dedicated clients only. The use of the access and root options allows R/W root access to the listed clients and prohibits any access from any other clients. The following sample entries grant R/W root access to the three clients. Any access from any other clients is denied: 


/hfs/sapmnt -access=10.101.4.214<root>|\
                    10.101.4.215<root>|\
                    10.101.4.216<root>
hlq.PARMLIB(<NFS attributes>):
  • id2name attribute

    z/OS 2.2 introduces a new NFS server site attribute id2name. We recommend to explicitly use id2name(cache) in order to enhance NFSv4 performance by utilizing UID/GID caching and eliminating calls to RACF. This attribute affects only NFSv4. The default is id2name(callsaf).

  • nlm attribute

    In an NFSv4-only configuration, you should set this attribute to nonlm. In a mixed configuration with NFSv3 and NFSv4 you should set this attribute to nlm.

  • Remount attribute

    This attribute is required only in an NFSv3 environment or in a mixed environment with NFSv3 and NFSv4 mounts to the same NFS server. The REMOUNT attribute should be removed in pure NFSv4 environments. When removed it defaults to NOREMOUNT.

    When used, the REMOUNT attribute enables the NFS server to process NFS requests after the NFS server is restarted even though the HFS file system was remounted with a new HFS file system number (device number) after its last usage. Use of the REMOUNT attribute causes the NFS server to automatically access a remounted HFS file system even though it may have been changed before remounting. Any active client mounts are reestablished.

  • nfsv4domain(NFSv4_default_domain) attribute

    This attribute should be appropriately set. NFSv4_default_domain specifies the "pseudo" NFSv4 domain for the NFSv4 name mapping. The "pseudo" NFSv4 domain allows various NFSv4 Clients from various network domains to seamlessly access the server provided that these NFSv4 clients are also configured with the same domain.

    If the NFSV4DOMAIN attribute is not used, the server uses the system-defined domain. The participating NFSv4 client domains must match one of the server's network domains for proper NFSv4 name mapping.

    NFSv4domain attribute support is available with APAR OA30333, PTF UA52468. For further details, refer to the latest z/OS NFS Guide and Reference. There is no client support yet for the NFSV4DOMAIN server attribute so for now the NFSV4DOMAIN is not exploited in this installation.

Note: Name resolution is not supported through any global name server such as LDAP.
z/OS UNIX
/etc/ualiastable

NFSv4 since z/OS 1.10 requires user alias mapping. The same owner and group names are to be defined on both the server and client. The owner and group names must be defined to RACF® with appropriate uid and gid values on z/OS.

/etc/resolv.conf

Must include DOMAINORIGIN set to a specific domain name.

Note: The domain name must be equal on participating NFSv4 server and clients.