Figure 1 contains an example exports data set. The exports
data set can be found as GFSAPEXP in the NFSSAMP library.
Figure 1. Sample
exports data set#######################################################################
# #
# z/OS Network File System Server Sample EXPORTS #
# #
# PROPRIETARY STATEMENT= #
# LICENSED MATERIALS - PROPERTY OF IBM #
# THIS MODULE IS "RESTRICTED MATERIALS OF IBM" #
# 5647-A01 #
# COPYRIGHT IBM CORPORATION 1991, 2008 #
# SEE IBM COPYRIGHT INSTRUCTIONS #
# END PROPRIETARY STATEMENT #
# Copyright IBM Corp. 1991, 2007 #
# Copyright SUN Microsystems, Inc & #
# Electronic Data Systems Corp. 1988, 1989 #
# #
#######################################################################
# @(#)exports.cntl 3.2 89/04/20 SMI EDS
#
# This file contains EXPORT and CHKLIST entries. @L81A
# This file is used for processing EXPORT entries when Server @L81A
# security option is set to EXPORT/SAFEXP, and CHKLIST entries @L81A
# when Server security option is SAF/SAFEXP modes. @L81A
# i.e. being in security(SAFEXP) mode both EXPORT and CHKLIST @L81A
# entries (directory suffixes) are to be processed. @L81A
# This file is not used for SECURITY(NONE). @L81A
#
# This data set contains entries for directories that may be
# exported to Network File System Clients. It is used by the
# server to determine which data sets and prefixes may be
# accessed by a client, and to write protect data sets on the
# server provided that the SECURITY site attribute is set
# to either SECURITY(EXPORTS) or SECURITY(SAFEXP). This file @L81C
# is not used for SECURITY(NONE). @L81C
#
# This data set contains also suffixes of directories that are @L81A
# to be exempt from SAF checking even though SAF or SAFEXP is @L81A
# specified as the security option. The directory suffixes are @L81A
# only used when SAF or SAFEXP is specified for the particular @L81A
# data type (i.e. MVS data, HFS data, data accessed using the @L81A
# public file handle) AND CHECKLIST option is specified as the @L81A
# site attribute. The directory suffixes specified here forms @L81A
# file/directory names which HAVE TO MATCH a subsequent mount @L81A
# point OR be the parent of a subsequent mount point to allow @L81A
# SAF checking to be bypassed for everything underneath that @L81A
# mount point. @L81A
# @005A
# This data set also defines how a symlink in the directory @005A
# path is resolved at the time of a NFS Client access to the @005A
# directory. @005A
#
# The mvsnfs.cntl(exports) data set is read during server startup
# processing. Subsequent changes to this data set will not take
# effect until the server is restarted or the EXPORTFS command
# is issued. However, changes to the data set do NOT affect the
# mounts processed before the server was restarted or before
# EXPORTFS was issued.
#
# Errors found in the file are sent to the system log, and the server
# continues processing for minor errors such as undefined host
# names. Termination is brought about if the EXPORTS data set
# cannot be read or if a syntax error exists. (In the case of the
# EXPORTFS command, these errors will cause the command to be
# ignored and processing will continue with the original exports
# file in effect.)
#
# Statement Syntax
#
# Entries can be up to 4096 characters long. Lines can be continued
# by placing a '+' or '\' at the end of the line. A '#' anywhere in the
# data set indicates a comment that extends to the end of the line.
#
# Wildcard symbols support @LC9A
# @LC9A
# The following wildcard symbols can be used to create regular @LC9A
# expressions within directories in the EXPORTS file. @004C
# @LC9A
# Symbol Explanation @LC9A
# @LC9A
# * Represents any length sequence (can be zero) of any @LC9A
# valid characters. @LC9A
# @LC9A
# Example /u/ab* matches /u/abcde or /u/abfg @LC9A
# IBMUSER.HO*.NAME matches IBMUSER.HOME.NAME or @LC9A
# IBMUSER.HOLD.NAME @LC9A
# @LC9A
# ? Represents any (but only one) valid character. @LC9A
# @LC9A
# Example /u/user? matches /u/user1 or /u/user2 @LC9A
# but not /u/user12 @LC9A
# @LC9A
# Y.-.¨ or @LC9A
# Y...¨ Is used to specify one symbol from the region of @LC9A
# characters. @LC9A
# Characters are regulated in EBCDIC alphabetical order. @LC9A
# Open bracket, Y, has to be hex value x'AD' @01A
# Close bracket, ¨, has to be hex value x'BD' @01A
#
# NOTE: Hex values x'AD' and x'BD' may represent @01A
# different characters depending on the @01A
# code page defined for your installation @01A
# @LC9A
# Example 1: /u/Ya-c¨de matches /u/ade or /u/bde or /u/cde @01C
# /u/Yabd¨fg matches /u/bfg or /u/dfg @LC9A
# but not /u/cfg @LC9A
# Example 2: Given the set of similar resource names @01A
#
# /user/abcdef1 /user/abddef1 @01A
#
# /user/abcdef2 /user/abedef2 @01A
#
# /user/abcdef3 /user/abfdef3 @01A
#
# /user/abcdef4 @01A
#
# with wildcard symbols support it is possible to export all
# of these names by only one row in the EXPORTS file:
#
# /user/ab[c-f]def?
#
# Be aware that with this line other datasets, for example
# /user/abfdef4, are also exported.
#
# MVS system symbols support
#
# The NFS server supports both types of MVS system symbols:
# static and dynamic.
# System-defined static system symbols already have their names
# defined to the system.
# An installation defines a default list of symbols that can be
# adjusted by the system administrator.
#
# Some examples of static MVS system symbols are:
# &SYSCLONE, &SYSNAME, &SYSPLEX, &SYSR1.
# Actual values for static symbols are constant for a running
# system.
#
# In contrast, dynamic MVS system symbols can change their
# values at any time.
# The NFS server will substitute the actual values for the
# the dynamic symbols at NFS start up and on the EXPORTFS NFS
# operator command.
# These values will be fixed in the NFS exports list until
# the next EXPORTFS command execution even if the value of any
# dynamic symbol changes.
# Some examples of dynamic MVS system symbols are:
# &SYYMMDD, &DATE, &SHHMMSS, &YR4.
#
# When used in the EXPORTS file, MVS system symbols
# (static or dynamic) should be preceded by an "&" sign and
# closed with a ".".
# Also it should not be empty (i.e. "&." is not allowed).
# The name of the MVS system symbol should not exceed 80
# characters.
#
# Examples /u/&&SYSNAME.
# IBMUSER.&&DATE..REPORT
#
# Limitations on the usage of Wildcard symbols and MVS system
# symbols in directories are described under directory_suffix.
#
# The first keyword occurrence on a line is delineated with a
# dash. Subsequent keyword occurrences on the same line must not
# have the dash but must be separated with a comma from the
# keyword that precedes it.
# No spaces may appear between the keywords; however, leading
# blanks are ignored in new or continuation lines.
#
# Entries for a directory are specified by a line of the following
# syntax:
#
# directory -ro
# directory directory_suffix -ro
# directory -rw=clients
# directory directory_suffix -rw=clients
# directory -access=clients
# directory directory_suffix -access=clients
# directory_suffix
# directory -sec=sys|krb5|krb5i|krb5p
# directory -symresolve|-nosymresolve (optional)
#
# where:
#
# directory = Prefix or file name
# directory_suffix = <nosaf>
# <hosts=clients,nosaf>
# <hosts=list_of_items,nosaf>
# where item is prefix or file name with optional client
# list:
# hfs_subdir_or_mvs_prefix
# hfs_subdir_or_mvs_prefix,hosts=clients
#
# Clients in the "hosts=" option may be specified as
# hostname or IP address.
# Only hosts from the list can have access to the mounted
# data in SAF or SAFEXP mode without MVSLOGIN.
# If the directory_suffix is used together with a directory
# Wildcard symbols and MVS system symbols within a
# directory must not be used because the checklist entry
# provides for the exact data path to be excluded from
# SAF checking.
#
# -ro = Export the directory as read only. If not specified,
# the directory is exported read/write to every one.
#
# -rw = Directory exported read/write to specified clients,
# and read only to everyone else. Separate clients
# specs by '|' (vertical bar).
#
# -access = Give access only to clients listed. Separate client
# specs by '|' (vertical bar). This can be further
# qualified with the "ro" keyword or with an "rw"
# list.
#
# -sec = Specifies the Kerberos authentication level that
# clients must have to access individual files and
# data sets on the z/OS NFS server.
#
# -symresolve = The symlink in the directory path is resolved
# at time of an NFS Client access to the
# directory. A new Export entry is created in
# memory with the real directory path.
# -nosymresolve = The symlink in the directory path is not
# resolved.
#
# The keywords "ro" and "rw" are mutually exclusive.
# The keywords "ro" and "rw" are mutually exclusive.
# The symresolve option is only for NFSv4 LOOKUP in zOS UNIX
# space when a symlink is found within an export entry.
# -symresolve and -nosymresolve are optional. If not specified,
# the server default attribute value is used.
#
# Directory suffix examples.
# 1. Example showing bypass of the SAF checking of multiple
# sub-directories for the SAME directory.
# Given that the directory tree and the exports list are as
# follows:
# Directory tree: Exports:
# /user1/. /hfs/user1<docs,test/release2,nosaf>
# temp
# docs.
# /guides
# test/.
# release1
# release2
#
# SAF checking will be bypassed for mount point and everything
# underneath that mount point, i.e. users do not need to do
# MVSLOGIN for the files/directories underneath the mount point:
# /hfs/user1/docs
# /hfs/user1/docs/guides
# /hfs/user1/test/release2
#
# SAF checking will be enforced for mount point:
# /hfs/user1
# /hfs/user1/temp
# /hfs/user1/test/release1
#
# 2. Example for SAFEXP and SAF security.
# Given that security of SAFEXP or SAF is specified and the
# exports list is as follows:
# Exports:
# WEBNFS.PDS <hosts=client1|client2,nosaf>
# USER1hosts=<PUBLIC,NOSAF>
# /hfs/user1 <tmp,hosts=client1|client2,NOSAF>
# /hfs/u/public<nosaf>
# /hfs/bin
#
# For SAF security only exports entries with NOSAF option will
# be taken into consideration. Such entries will be used only to
# bypass SAF checking and to limit access to the mount point
# with the list of hosts.
#
# The following mount requests for SAFEXP security will fail
# because it is not in the exports list:
# WEBNFS
# /hfs/u
#
# The following mount requests for SAFEXP and SAF security will
# succeed and SAF checking will be bypassed for mount point and
# everything underneath that mount point (i.e. users do not need
# to do MVSLOGIN to access mount point and everything underneath
# that mount point):
# WEBNFS.PDS
# USER1.PUBLIC.PDS
# /hfs/user1/tmp/dir1
# /hfs/u/public
# But access to WEBNFS.PDS and /hfs/user1/tmp/dir1 will be
# allowed only for client1 and client2 and will require the use
# of MVSLOGIN by users on all other hosts.
# Access to USER1.PUBLIC.PDS, /hfs/u/public will not be limited
# (will be possible for any hosts).
#
# The following mount requests for SAFEXP security will succeed
# but SAF checking will be enforced:
# USER1.SOMEPDS
# /hfs/user1
# /hfs/bin
# Access to the mount point will be possible for any hosts.
#
# The following mount requests for SAF security will succeed
# (no exports checking) but SAF checking will be enforced:
# WEBNFS
# USER1.SOMEPDS
# /hfs/u
# /hfs/bin
# /hfs/dir_which_is_absent_in_exports_list_but_exist
# Access to the mount point will be possible for any hosts.
#
# 3. Example showing usage of a directory suffix with nothing
# before it.
# Given that security of SAFEXP or SAF is specified and the
# exports list and the PUBLIC z/OS NFS site attribute are as
# follows:
# Exports:
# <WEBNFS.PDS,hosts=client1|client2,nosaf>
# </hfs/user1/tmp,hosts=client1|client2,NOSAF>
# <nosaf>
# <hosts=client1|client2,nosaf>
# PUBLIC:
# PUBLIC(WEBNFS.PDS,/hfs/user1/tmp)
#
# SAF checking will be bypassed for PUBLIC mount points and
# everything underneath these PUBLIC mount points:
# WEBNFS.PDS
# /hfs/user1/tmp
# But access to WEBNFS.PDS and /hfs/user1/tmp will be allowed
# only for client1 and client2 and will require the use of
# MVSLOGIN by users on all other hosts.
#
# The entries of the exports list will be ignored but will cause
# syntax error:
# <nosaf>
# <hosts=client1|client2,nosaf>
#
# Client suffix can be used to give the root user of the client
# root access to the exported directory.
# Client root user will have full root support on NFSv2, NFSv3,
# NFSv4 mounted directory.
# Client suffix only applies to Security EXPORTS mode. It is
# ignored in SAF and SAFEXP Security modes.
#
# Clients in the client list must be separated with '|' and may
# contain a client suffix. Client suffix can be used to give the
# root user of the client root access to the exported directory.
# Client suffix only applies to Security EXPORTS mode. It is
# ignored in SAF and SAFEXP Security modes.
# Client suffix has syntax:
#
# <root>
#
# Client and its suffix combines as:
#
# client<root> NFSS will honor client UID = 0 (trusted user).
# NFSS will give client's user with UID=0
# (trusted user) superuser access on the directory
# while other users on that client will get normal
# access to the directory the same as if the
# client suffix (i.e. <root> ) was not specified
# for that client.
#
# Clients in the client list can be specified in a number of ways
# (depending on DHCP z/OS NFS site attribute):
#
# single hostname
# You may specify a hostname regardless of DHCP Z/OS
# NFS site attribute. It may be specified without the
# domain part.
# You may specify client suffix. Example:
# host1<root>
# host1.cs.foo.edu<root>
#
# netgroup name
# Netgroup name (from the local /etc/netgroup file)
# may be given as @groupname. You may specify a
# netgroup name regardless of DHCP z/OS NFS site
# attribute.
# You may NOT specify client suffix (i.e. <root>)
# with netgroup name.
#
# single IP address
# You may specify a client by an IPv4 or IPv6 address.
# If DHCP z/OS NFS site attribute is "dhcp" such
# clients will be ignored. If NFS Server starts up in
# IPv4 mode all clients specified with IPv6 addresses
# will be ignored. If NFSS starts up in IPv6 mode all
# IPv4 addresses of clients will be translated to
# IPv4-mapped addresses.
# You may specify client suffix (i.e. <root>).
#
# IP network template
# You can export directory to all hosts on an IPv4
# and IPv6 (sub-) network simultaneously. If DHCP
# attribute is "dhcp" such IP network template will
# be ignored.
# You may NOT specify client suffix (i.e. <root>).
# For IPv4, a network template is specified by an
# IPv4 address and netmask pair as address/netmask
# where a netmask must be specified in dotted-decimal
# format, or as a contiguous mask length (for example,
# either '/255.255.252.0' or '/22' appended to the
# network base address result in identical subnetworks
# with 10 bits of host). If NFS Server starts up in
# IPv6 mode IPv4 network template will be converted
# to a template based on IPv4-mapped addresses.
# For IPv6, a network template is specified by an
# ipv6-address/prefix-length (for example, the node
# address 12AB:0:0:CD30:123:4567:89AB:CDEF and its
# subnet number 12AB:0:0:CD30::/60 can be abbreviated
# as 12AB:0:0:CD30:123:4567:89AB:CDEF/60). If NFS
# Server starts up in IPv4 mode IPv6 network template
# will be ignored.
#
# hostname template
# Machine names may contain the wildcard characters
# '*' and '?'. This can be used to make the exports
# file more compact; for instance, *.cs.foo.edu
# matches all hosts in the domain cs.foo.edu. However,
# these wildcard characters do not match the dots in
# a domain name, so the above pattern does not include
# hosts such as a.b.cs.foo.edu.
# For hostname template the domain part is mandatory.
# If DHCP z/OS NFS site attribute is "nodhcp" such
# entries will be ignored.
# You may NOT specify client suffix (i.e. <root>).
#
# If no options are specified, the default value
# allows any client read/write access to the given directory.
#
#
# If 'maplower' is specified in the default attributes, all
# entries are translated to upper case. High level qualifiers
# specified in the client mount request are translated to
# upper case.
#
# If 'nomaplower' is specified in the default attributes,
# attention must be given to the case of entries. High level
# qualifiers specified in the client mount request are not
# translated to upper case.
mvsnfs -ro
userid0.mixds -rw=fsrs001|fslab004<root>|9.43.249.211|\
9.43.249.206<root>|fe80::204:acff:fee4:b7b6|\
fe80::a00:20ff:feb9:4a65<root>|fssun??.cs.foo.edu|\
*.de.foo.net|10.20.324.151/255.255.255.240|\
10.33.324.151/28|fe80::b04:ac20:feff:a776/121|@hpnetgrp
userid1<nfs,nosaf> -rw=fsrs001
userid2.nfs.pds <nosaf> -access=fsrs001|fssun03<root>
userid3.nfs.ps -sec=krb5|krb5i|krb5p|sys
userid4.nfs.another.pds -access=fslab004
/hfs/u/newproducts -access=fsrs001,ro
/hfs/u/symlink_ent -symrersolve
/hfs/u/symlink1_ent <nosaf> -access=fslab008,symresolve
z/OS Network File System Guide and Reference
Copyright IBM Corporation 1990, 2014