AUTH_SYS and KRB mounts with NFS41 nConnect

Products

• VMware vSphere ESXi 8.0

Issue/Introduction

This KB lists constraints in mounting the datastores with different security mechanisms and nConnect.

 

Environment

VMware vSphere ESXi 8.0 U3

Cause

• Each NFS41 client instance is represented by a client ID and each NFS41 server instance is identified by a server_owner which is a combination of server_major and server_minor and uniquely identifies a server in a cluster.
• When NFS41 client mounts a share, it creates a session per server_owner and associates the TCP connection with the session. Each session is associated with client ID.
• Server keeps the state of the authentication mechanism for the existing client and the session and rejects any new security mechanism for the existing client with NFS4ERR_CLID_INUSE error.

Example:
1.  Mount Datastore1 from IP1 and with security type AUTH_SYS and nConnect value of 2

• This creates a session between the client and the server instance with security Type AUTH_SYS
• Any subsequent connection to the same server with a different security mechanism will not be honored by the server. It fails the request with protocol error  NFS4ERR_CLID_INUSE 

2.  Mount Datastore2 from IP1 and with security type KRB5/KRB5I and nConnect value of 2

• The previous mount from Step 1 has already established  a session for this clientID and server instance.  Datastore2 will reuse the same TCP connection.

3.  If user tries to mount Datastore3 from IP1 with security type KRB5/KRB5I and nConnect value 2, server fails the mount with the error, NFS4ERR_CLID_INUSE

• The previous mount from Step 1 has associated the session with security type  AUTH_SYS.
• Datastore3 will reuse the existing TCP connection from step 1.
• As mentioned in Step 1, any attempt to create new connection with a different security mechanism(KRB5*) will fail i.e. EXCHID request will get NFS4ERR_CLID_INUSE error from server. Datastore3 gets mounted but with only one connection
• Behavior would be same if the cluster is initially created with KRB* and the new request is for AUTH_SYS

Resolution

To workaround this behavior all requests for connection should have the same security mechanism with which the cluster is created

Additional Information

Support for nConnect feature added in ESXi's NFS41 client