The issues associated with accessing symbolic links on z/OS NFS version 4 due to two file system types has been resolved in z/OS V1R11. This has been done with enhanced prefix support. See z/OS NFS File System Type Selection for more information.

When using an Exports file (Security(EXPORTS) or Security(SAFEXP) mode), both the initial path containing the symbolic link and the target path must be exported. Otherwise, the mount will fail. This is necessary because in NFS v4, the initial mount emulation (lookup) processing proceeds until the symbolic link is found. If that is not exported, that initial mount processing will fail. Once the symbolic link is discovered, the NFS client starts over with the mount emulation (lookup) processing using the target path name. If that path is not exported, then that mount processing will fail.

The NFS version 4 protocol (NFSv4) does not include a mount operation. Instead, mount requests are processed as a series of lookup operations starting from the root node. If the mount request includes a symbolic link in the path name, the fact that the node is a symbolic link is returned to the NFS Client. It is the client's responsibility to read the link to get the defined data path and then restart the lookup process starting from the root node, but using this defined data path. From the NFS Server's perspective, this is a brand new request. A side effect of this protocol defined processing sequence is that when using an Exports file, both the original path name and this symbolic link defined path name must be exported, as previously described.

By contrast, NFSv2 and NFSv3 use the Mount protocol for mount requests which sends the entire path name to the NFS Server in a single request. In this case, after that path name has been export checked, the path name is passed to z/OS UNIX System Services which resolves the entire path, including any symbolic link resolution, bypassing any separate export checking of the defined symbolic link path.

One exception to NFSv4 mount request processing that was described previously in this section is for the case when the symbolic link is the last qualifier in the path and it is followed by any processing attributes. In this case, the z/OS NFS server cannot follow the NFSv4 defined process because it would cause the processing attributes to get lost since non-z/OS NFS Clients do not understand the concept of z/OS NFS processing attributes and thus would not append them to the new lookup path. Therefore, if the z/OS NFS Server detects a lookup operation for a symbolic link which is followed by processing attributes, instead of returning the fact that this node is a symbolic link to the NFS Client, the z/OS NFS Server resolves the mount path in a similar manner to that used for NFSv2 and NFSv3 mount requests. The one difference between the NFSv4 and the NFSv2 and NFSv3 behavior is that NFSv4 performs export checking of the defined symbolic link path, while NFSv2 and NFSv3 do not.

In the event of a SYSPLEX failover where there is a need to get symlink based mounts to automatically (and transparently to the client user application) switch to a different real path when switching to a new NFS Server instance, the following procedure is recommended:

1. Execute on one NFS Client system at a time
   1. Stop any running application (for example, SAP).
   2. Unmount the file system.
   3. Remove the 'mvsmnt' attribute from the mount statement.
   4. Remount the file system.
2. Issue the z/OS NFS Server Operator UNMOUNT command to remove the symlink mounts from the MHDB
3. Stop and restart the z/OS NFS Server.