Network File System (NFS) Version 4 Protocol
Extracted elements (30)
NFSv4 eliminates the MOUNT ancillary protocol in favor of built-in PUTROOTFH and PUTPUBFH operations that set the current filehandle to the server root or a configured public filehandle. The MOUNT protocol had security weaknesses and poor firewall traversal; its function was demonstrated to be redundant given LOOKUP.
NFSv4 integrates byte-range file locking directly into the NFS protocol under a lease-based model, replacing the separate Network Lock Manager (NLM) from NFSv3. This eliminates the requirement for an RPC callback mechanism for locking and allows the server to maintain a single fixed lease period for all client state.
The COMPOUND procedure was introduced to reduce round trips by allowing logical file system operations (e.g., LOOKUP + OPEN + READ) to execute in a single RPC. There is no logical OR/AND of operations; evaluation is strictly sequential and stops at the first error.
Volatile filehandles were introduced because some server environments cannot provide a file system-level invariant suitable for constructing persistent filehandles, and because volatile handles ease implementation of hierarchical storage management and file system migration. The tradeoff is increased client implementation burden to track path components for recovery.
The XDR description in companion document RFC 7531 is authoritative. Where RFC 7530 reproduces XDR constructs for explanatory purposes, any inconsistency between the two documents must be resolved in favor of RFC 7531. RFC 7530 and RFC 7531 together obsolete RFC 3530 without introducing over-the-wire protocol changes.
NFSv4 clients and servers MUST support the Kerberos V5 security mechanism via RPCSEC_GSS, including all three pseudo-flavors: krb5 (rpc_gss_svc_none, number 390003), krb5i (rpc_gss_svc_integrity, 390004), and krb5p (rpc_gss_svc_privacy, 390005).
NFSv4 servers must be able to recover without data loss from multiple power failures, OS failures, and hardware failures of non-storage components. Stable storage must represent a genuine commitment of data, e.g., media commit, battery-backed intermediate storage with recovery software, or UPS-protected cache with recovery software.
Once the server creates a persistent filehandle for a file system object, it MUST accept the same filehandle for the lifetime of the object, including across server restarts and file system migration. When a persistent filehandle refers to a deleted object, the server MUST return NFS4ERR_STALE.
RPCSEC_GSS security flavors as defined in RFC 2203 (version 1) and RFC 5403 (version 2) MUST be implemented as the mechanism to deliver stronger security for NFSv4. Deployment of RPCSEC_GSS is optional, but the security flavor MUST be used to enable the mandatory-to-implement security mechanism.
Security negotiation between client and server SHOULD be done with a secure channel to eliminate the possibility of a third party intercepting and forcing selection of a lower security level than required.
The callback RPC MUST mutually authenticate the NFS server to the principal that acquired the client ID, using the security flavor of the original SETCLIENTID operation. When using RPCSEC_GSS, the server MUST identify itself via a GSS_C_NT_HOSTBASED_SERVICE name of the form 'nfs@hostname'; for Kerberos V5 the form 'nfs/hostname' is RECOMMENDED.
The client MUST NOT interpret the contents of filehandles. If two filehandles from the same server are equal, they MUST refer to the same file. Clients MUST use filehandle comparisons only to improve performance, not for correct behavior.
When processing an NFSv4 request over a reliable transport such as TCP, the server MUST NOT silently drop the request except when the transport connection has been broken. Clients MUST NOT retry a request unless the transport connection has been broken or the procedure being retried is the NULL procedure.
Where an NFSv4 implementation supports operation over IP, the transport layer MUST be an IETF standardized transport protocol that avoids network congestion. Specifically, an NFSv4 implementation MUST support operation over TCP; client and server SHOULD use persistent TCP connections.
A stateid is a 128-bit server-generated quantity that uniquely identifies open and locking states for a specific open-owner or lock-owner/open-owner pair for a specific file. The server increments the seqid component monotonically at each state transition so clients can determine OPEN processing order.
All state held by an NFS client (opens, byte-range locks, delegations) is managed under a server-defined lease. If the client does not renew its lease within the lease period via RENEW or other operations, all associated state may be released by the server.
Client IDs are 64-bit shorthand references to a client-supplied verifier and opaque ID string. They are negotiated via SETCLIENTID/SETCLIENTID_CONFIRM and serve as the basis for all state (opens, locks, delegations) held by a client on the server.
NFSv4 defines two filehandle types: persistent (valid for the lifetime of the file system object) and volatile (may expire, signaled by NFS4ERR_FHEXPIRED). The REQUIRED attribute fh_expire_type is a bitmask with flags FH4_PERSISTENT, FH4_VOLATILE_ANY, FH4_NOEXPIRE_WITH_OPEN, FH4_VOL_MIGRATION, and FH4_VOL_RENAME.
Open delegations (OPEN_DELEGATE_READ or OPEN_DELEGATE_WRITE) allow the server to grant a client guaranteed semantics for file sharing. A read delegation assures no other client can write; a write delegation assures no other client has read or write access. Delegations are recalled via the CB_RECALL callback when conflicts arise.
The COMPOUND procedure is the primary RPC procedure in NFSv4 (alongside NULL). Operations within a COMPOUND request are evaluated in order; once any operation returns a failing result, evaluation stops and all results to that point are returned. This allows combining LOOKUP, OPEN, and READ into a single RPC without prior server contact.
The fs_locations RECOMMENDED attribute (using fs_locations4 structure) supports multi-server namespaces by specifying alternative or replacement locations for file systems. It is used for referrals (redirecting clients to another server), replication (alternative instances), and migration (non-disruptive transfer).
The SECINFO operation allows a client to determine the security triple required for a specific filehandle. It returns a list of security mechanisms acceptable to the server for that namespace entry point, enabling in-band security negotiation without a separate protocol.
RFC 7530 establishes the IANA 'Named Attribute Definitions' registry for NFSv4 named attributes. The initial registry is empty; new entries require IETF Review. Updating existing registrations also requires IETF Review per Section 20.1.2.
NFSv4 moves the authentication model from machine-based to principal-based. However, this does not change the TCP connection management model; clients continue to multiplex multiple users over shared connections. The NFS4ERR_WRONGSEC error allows servers to indicate that the current security triple is insufficient for a resource, triggering SECINFO-based renegotiation.
The strength of NFSv4 security depends on the Kerberos V5 infrastructure in use. Since Kerberos V5 algorithms are not directly selectable by NFSv4 clients or servers, deployers must independently ensure the Kerberos deployment uses acceptably strong algorithms; RFC 6649 provides guidance on disabling weak algorithms.
fattr4 encodes attributes as a bitmap4 (variable-length array of uint32_t, where bit n is at integer position n/32 and bit offset n mod 32) followed by attrlist4 (opaque byte stream of attribute values). This structure supports extensible attribute sets without fixed-size overhead.
nfs_fh4 is a variable-length opaque field bounded by NFS4_FHSIZE, representing the per-server unique file system object identifier. The clientaddr4 structure (r_netid and r_addr strings per RFC 5665) carries network addresses for callback registration in SETCLIENTID.
nfstime4 encodes timestamps as int64_t seconds (signed, relative to Unix epoch midnight January 1, 1970 UTC) plus uint32_t nseconds (nanoseconds; values greater than 999,999,999 are invalid). Negative seconds values denote pre-epoch dates; nseconds is added to seconds in both cases.
stateid4 is encoded as uint32_t seqid (4 bytes, monotonically incremented per state transition) followed by opaque other[NFS4_OTHER_SIZE] (12 bytes), for a total of 128 bits. The seqid field is read-only to the client.
verifier4 is a fixed 8-byte (NFS4_VERIFIER_SIZE=8) opaque field generated by the client and used in COMMIT, CREATE, OPEN, READDIR, and WRITE operations. The server uses it to detect client restarts and distinguish new requests from retransmissions.