When a mount command is issued to an ONTAP NFSv3 server from an NFS client, the following occurs:
1. RPC is made to port 111 (portmapper) of the NFS server to attempt a TCP connection through the portmapper.
2. When the RPC call has been acknowledged, portmapper issues a GETPORT call to port 111 of the NFS server data LIF to obtain which port NFS is allowed on.
3. The NFS server returns the port 2049 (nfs) to the client.
4. The client then closes the connection to port 111.
5. A new RPC call is made to port 2049 of the NFS server data LIF.
6. The NFS server returns the call successfully and the client sends an NFS NULL call to port 2049 of the NFS server’s data LIF. This action checks whether the parent volume allows access to the mount. In this case, the parent volume is mounted to /, or the SVM root.
7. The NFS NULL call is returned successfully and the client proceeds with the mount attempt.
8. Portmapper sends a GETPORT call to the NFS server’s data LIF asking for the mountd port and provides the credentials, NFS version number, and whether the mount will use TCP or UDP.
9. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This operation is carried out through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP/UDP is not allowed, the client reports the error.
10. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP or UDP connection. It also replies if the AUTH security provider is supported (AUTH_SYS or AUTH_GSS, for example).
11. When the GETPORT call passes, the client issues a V3 MNT call to the junction path specified in the mount command through port 635 (mountd) of the NFS server data LIF.
12. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
13. The NFS server returns the file handle to the client, as well as replies which AUTH types are supported by the export policy rule. If the AUTH type provided by the server matches what the client sent, the mount succeeds.
14. Portmapper from the client then sends another GETPORT call for NFS, this time providing the client’s host name. 15. The NFS server replies with port 2049 and the call succeeds.
16. Another NFS NULL call is made from the client over port 2049 of the NFS data LIF and is acknowledged by the NFS server.
17. A series of NFS packets with FSINFO and PATHCONF information is traded between the client and the NFS server.
When a mount command is issued to an ONTAP NFSv4 server from an NFS client, the following occurs:
1. The NFS client makes a TCP connection attempt to the NFS server data LIF through port 2049 (nfs). NFSv4 uses only TCP and only port 2049 for all calls.
2. The NFS server either allows or rejects the TCP connection, based on the NFS server settings.
3. When the TCP connection has been established, a V4 NULL call is made by the NFS client to the NFS server data LIF. This call is a check to see whether v4 is allowed on the NFS server through the AUTH type provided by the client (AUTH_SYS or AUTH_GSS, for example).
4. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This is done through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP is not allowed, the client reports the error.
5. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP connection, and also if the AUTH security provider is supported.
6. The NFS client then makes a compound v4 call for PUTROOTFH, GETFH, and GETATTR for the specified mount point’s parent volume. This call supplies the UID and GID of the user attempting access.
7. The cluster checks the UID and GID through SecD to verify that they exist in the provided NFSv4 domain and does a translation so that the user has access to mount the parent volume. In this case, the parent volume is /, or the SVM root.
8. The NFS server replies with the file handle of the SVM root volume and the attribute information of the parent volume.
9. The NFS server and client exchange a series of GETATTR calls to check access to the SVM root volume.
10. If the access is allowed to the user attempting access, then the client issues a LOOKUP DH call to the NFS server’s data LIF for the SVM root volume’s file handle/junction path; for example, 0x871aba87/vol1.
11. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
12. The NFS server returns the file handle to the client, as well as the attributes of that volume.
13. The NFS client and server exchange a series of GETATTR calls on the new file handle so that access is allowed for the user attempting mount access. 14. If access is allowed, the mount is successful.
1. RPC is made to port 111 (portmapper) of the NFS server to attempt a TCP connection through the portmapper.
2. When the RPC call has been acknowledged, portmapper issues a GETPORT call to port 111 of the NFS server data LIF to obtain which port NFS is allowed on.
3. The NFS server returns the port 2049 (nfs) to the client.
4. The client then closes the connection to port 111.
5. A new RPC call is made to port 2049 of the NFS server data LIF.
6. The NFS server returns the call successfully and the client sends an NFS NULL call to port 2049 of the NFS server’s data LIF. This action checks whether the parent volume allows access to the mount. In this case, the parent volume is mounted to /, or the SVM root.
7. The NFS NULL call is returned successfully and the client proceeds with the mount attempt.
8. Portmapper sends a GETPORT call to the NFS server’s data LIF asking for the mountd port and provides the credentials, NFS version number, and whether the mount will use TCP or UDP.
9. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This operation is carried out through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP/UDP is not allowed, the client reports the error.
10. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP or UDP connection. It also replies if the AUTH security provider is supported (AUTH_SYS or AUTH_GSS, for example).
11. When the GETPORT call passes, the client issues a V3 MNT call to the junction path specified in the mount command through port 635 (mountd) of the NFS server data LIF.
12. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
13. The NFS server returns the file handle to the client, as well as replies which AUTH types are supported by the export policy rule. If the AUTH type provided by the server matches what the client sent, the mount succeeds.
14. Portmapper from the client then sends another GETPORT call for NFS, this time providing the client’s host name. 15. The NFS server replies with port 2049 and the call succeeds.
16. Another NFS NULL call is made from the client over port 2049 of the NFS data LIF and is acknowledged by the NFS server.
17. A series of NFS packets with FSINFO and PATHCONF information is traded between the client and the NFS server.
When a mount command is issued to an ONTAP NFSv4 server from an NFS client, the following occurs:
1. The NFS client makes a TCP connection attempt to the NFS server data LIF through port 2049 (nfs). NFSv4 uses only TCP and only port 2049 for all calls.
2. The NFS server either allows or rejects the TCP connection, based on the NFS server settings.
3. When the TCP connection has been established, a V4 NULL call is made by the NFS client to the NFS server data LIF. This call is a check to see whether v4 is allowed on the NFS server through the AUTH type provided by the client (AUTH_SYS or AUTH_GSS, for example).
4. The cluster checks the NFS settings and verifies whether the credentials supplied are allowed to mount based on the export policy rules. This is done through an RPC call from the NAS blade to the SecD process. If SecD is not functioning properly, this check fails and the mount gets access denied. If the NFS version or TCP is not allowed, the client reports the error.
5. The NFS server replies successfully if the version provided is supported and if the mount can use the specified TCP connection, and also if the AUTH security provider is supported.
6. The NFS client then makes a compound v4 call for PUTROOTFH, GETFH, and GETATTR for the specified mount point’s parent volume. This call supplies the UID and GID of the user attempting access.
7. The cluster checks the UID and GID through SecD to verify that they exist in the provided NFSv4 domain and does a translation so that the user has access to mount the parent volume. In this case, the parent volume is /, or the SVM root.
8. The NFS server replies with the file handle of the SVM root volume and the attribute information of the parent volume.
9. The NFS server and client exchange a series of GETATTR calls to check access to the SVM root volume.
10. If the access is allowed to the user attempting access, then the client issues a LOOKUP DH call to the NFS server’s data LIF for the SVM root volume’s file handle/junction path; for example, 0x871aba87/vol1.
11. The cluster uses the junction path provided by the client and searches for the path in the Volume Location Database (vldb). If the entry exists, the cluster gathers the file handle information from the vldb.
12. The NFS server returns the file handle to the client, as well as the attributes of that volume.
13. The NFS client and server exchange a series of GETATTR calls on the new file handle so that access is allowed for the user attempting mount access. 14. If access is allowed, the mount is successful.
