NFS versions 2 and 3 used the mount protocol to define the initial "mount point" and its associated file handle. File locking was done with the Network Lock Manager protocol. NFS version 4 uses a well-defined port as an anchor. This allows the hookup (no longer called "mount") to occur implicitly, because the concept of a "Root" file handle, in combination with the port, allows the equivalent of a mount to take place on the server side.

In NFS versions 2 and 3, a client application would request to mount a file system object; the NFS client would then issue a "mount" protocol operation to the server, providing usage attributes, and specifying a file system object that is exported by the server. This mount command would specify to the server the name of the object to be mounted. The server would then provide a handle to the client for use in accessing objects related to this mount point.

In NFS version 4, this mount protocol is no longer used. Instead, the server provides a name space to the objects that are exported by the server. Standard non-mount operations such as LOOKUP and READDIR are changed by the NFS version 4 protocol to accomplish this. These changes are transparent to the client application. The NFS Client translates the mount request into the proper NFS version 4 operations that accomplish this access.

In NFS versions 2 and 3, objects in the server file system are accessed by a filehandle. This filehandle is given to the client in response to a mount or lookup operation, and is provided by the client when attempting to access objects in that file system. The NFS version 4 protocol specifies a pair of operations, PUTROOTFH and PUTPUBFH, that allow the client to request a starting point in the exported (or public, respectively) file system.

The NFS version 4 protocol also uses a COMPOUND procedure in which many operations can be sent in a single request. For this purpose, a filehandle is known within the COMPOUND structure as one of two items: a "current filehandle" and/or a "saved filehandle". NFS Version 4 operation PUTFH allows the client to provide a previously returned (by operation GETFH) filehandle, and operations SAVEFH and RESTOREFH allow the client to manipulate the current and saved file handles within the compound procedure. Further operations within the COMPOUND RPC will make use of the handles, once established by these "filehandle manipulation" operations. Refer to the NFS version 4 protocol (RFC3530) for usage of the current and saved file handles.

For NFS version 4, when the client receives a mount command from an application, the client translates the command into a PUTROOTFH operation followed by a series of LOOKUP operations. If this series of LOOKUPs deviates from a path that would lead to an exported object, the LOOKUP that starts this deviation will be rejected with NFSERR_NOENT.

The elimination of the mount/unmount operations from the NFS version 4 protocol means that the NFS client can not tell the NFS server when an application unmounts a file system. As a result, the NFS server keeps the file system mounted until the mount point times out. Therefore, those unmounted file systems will still appear in the mount list produced by a Modify mvsnfs,LIST=MOUNTS operator command.