rfc-7531

Network File System (NFS) Version 4 External Data Representation Standard (XDR) Description

T. Haynes (Editor), D. Noveck (Editor)
date2015-03 streamIETF areawit wgnfsv4 statusPROPOSED STANDARD pages39 canonicalhttps://www.rfc-editor.org/rfc/rfc7531 doi10.17487/RFC7531
The Network File System (NFS) version 4 protocol is a distributed file system protocol that owes its heritage to NFS protocol version 2 (RFC 1094) and version 3 (RFC 1813). Unlike earlier versions, the NFS version 4 protocol supports traditional file access while integrating support for file locking and the MOUNT protocol. In addition, support for strong security (and its negotiation), COMPOUND operations, client caching, and internationalization has been added. Of course, attention has been applied to making NFS version 4 operate well in an Internet environment. RFC 7530 formally obsoletes RFC 3530. This document, together with RFC 7530, replaces RFC 3530 as the definition of the NFS version 4 protocol.

Extracted elements (29)

design-rationale §2

The XDR description is embedded in the RFC with a '///' sentinel prefix so that a simple shell script can extract it into a compilable .x file. The extraction script strips leading whitespace and the sentinel sequence, producing nfs4_prot.x directly from the RFC source.

protocol-element §2

Mandatory file attributes (FATTR4_SUPPORTED_ATTRS=0 through FATTR4_LEASE_TIME=10, plus FATTR4_RDATTR_ERROR=11 and FATTR4_FILEHANDLE=19) must be supported by all NFSv4 servers; recommended attributes (FATTR4_ACL=12 through FATTR4_MOUNTED_ON_FILEID=55) are optional.

protocol-element §2

The ACE mask defines fine-grained permission bits including ACE4_READ_DATA/LIST_DIRECTORY (0x1), ACE4_WRITE_DATA/ADD_FILE (0x2), ACE4_EXECUTE (0x20), ACE4_DELETE (0x10000), ACE4_WRITE_ACL (0x40000), and generic composites ACE4_GENERIC_READ (0x120081), WRITE (0x160106), EXECUTE (0x1200A0).

security

protocol-element §2

The createmode4 enum defines three file creation modes for OPEN: UNCHECKED4 (0, create or open existing), GUARDED4 (1, fail if exists), and EXCLUSIVE4 (2, uses an 8-byte verifier to detect retransmits).

protocol-element §2

The fh_expire_type constants define filehandle volatility: FH4_PERSISTENT (0x0), FH4_NOEXPIRE_WITH_OPEN (0x1), FH4_VOLATILE_ANY (0x2), FH4_VOL_MIGRATION (0x4), FH4_VOL_RENAME (0x8). Clients use fattr4_fh_expire_type to determine caching behavior.

protocol-element §2

The fs_locations4 structure supports server-side referral and migration: it encodes the original fs_root pathname plus a variable array of fs_location4 entries, each with one or more server names and a rootpath. This enables transparent filesystem relocation.

protocol-element §2

The nfs_ftype4 enum defines nine file types: NF4REG (1), NF4DIR (2), NF4BLK (3), NF4CHR (4), NF4LNK (5), NF4SOCK (6), NF4FIFO (7), NF4ATTRDIR (8), and NF4NAMEDATTR (9). NF4ATTRDIR and NF4NAMEDATTR are NFSv4-specific additions supporting named attributes.

protocol-element §2

The nfs_lock_type4 enum defines four lock modes: READ_LT (1), WRITE_LT (2), READW_LT (3, blocking read), and WRITEW_LT (4, blocking write). The locker4 union distinguishes first-lock requests (open_to_lock_owner4) from subsequent requests (exist_lock_owner4).

protocol-element §2

The nfs_opnum4 enum defines 37 NFSv4 operations (OP_ACCESS=3 through OP_RELEASE_LOCKOWNER=39) plus OP_ILLEGAL=10044. All operations are dispatched via the COMPOUND RPC procedure; there is no per-operation RPC.

protocol-element §2

The NFS4_CALLBACK program (program number 0x40000000, version 1) is allocated in the transient range; clients assign the exact program number dynamically and communicate it to the server via the SETCLIENTID operation, supporting CB_NULL and CB_COMPOUND procedures.

protocol-element §2

The nfsstat4 enum defines the complete NFSv4 error space, including POSIX-mapped errors (1–70), NFSv4-specific errors in the range 10001–10048, and NFS4_OK (0). Notable additions include NFS4ERR_WRONGSEC (10016), NFS4ERR_GRACE (10013), and NFS4ERR_CB_PATH_DOWN (10048).

protocol-element §2

The open_claim_type4 enum defines four claim types: CLAIM_NULL (0, normal open by name), CLAIM_PREVIOUS (1, reclaim after server reboot by filehandle), CLAIM_DELEGATE_CUR (2, open with current delegation), and CLAIM_DELEGATE_PREV (3, reclaim previous delegation).

protocol-element §2

The open_delegation_type4 enum (OPEN_DELEGATE_NONE=0, READ=1, WRITE=2) controls delegation grants. open_read_delegation4 includes a recall bool and nfsace4 permissions; open_write_delegation4 additionally includes nfs_space_limit4 to govern client-side flush behavior.

protocol-element §2

The SETCLIENTID operation takes nfs_client_id4 (verifier + opaque id), cb_client4 (callback program + address), and callback_ident. On success it returns a clientid4 and setclientid_confirm verifier that must be confirmed via SETCLIENTID_CONFIRM before the client ID is active.

protocol-element §2

The stable_how4 enum (UNSTABLE4=0, DATA_SYNC4=1, FILE_SYNC4=2) controls write commit semantics. Clients may request weaker stability for performance and use COMMIT to flush to stable storage; the writeverf verifier detects server restarts between WRITE and COMMIT.

protocol-element §2

The verifier4 type is a fixed 8-byte (NFS4_VERIFIER_SIZE) opaque field used in SETCLIENTID, COMMIT (writeverf), READDIR (cookieverf), and EXCLUSIVE4 file creation to detect server restarts and ensure exactly-once semantics.

security-consideration §3

Security considerations for the NFSv4.0 XDR description are fully addressed in the Security Considerations section of RFC 7530, which this document supplements. No additional security considerations are introduced by the XDR encoding itself.

security

wire-format §2

The CB_COMPOUND4args callback structure includes a UTF-8 tag, uint32 minorversion, uint32 callback_ident, and a variable-length nfs_cb_argop4 array supporting CB_GETATTR and CB_RECALL operations.

wire-format §2

The change_info4 structure encodes a bool atomic flag plus before and after changeid4 (uint64) values, allowing clients to determine whether a directory change was atomic with respect to the operation that triggered it.

wire-format §2

The COMPOUND4args structure encodes the primary NFSv4 RPC request as a UTF-8 tag, uint32_t minorversion, and a variable-length array of nfs_argop4 operations. COMPOUND4res mirrors this with a status, tag, and resop array.

wire-format §2

The fattr4 attribute container consists of a bitmap4 attrmask followed by a variable-length opaque attrlist4 attr_vals. This structure is used throughout NFSv4 for both getting and setting file attributes.

wire-format §2

The nfs_client_id4 structure used in SETCLIENTID encodes an 8-byte verifier4 plus a variable-length opaque id field (up to NFS4_OPAQUE_LIMIT = 1024 bytes) to uniquely identify a client instance.

wire-format §2

The nfs_fh4 file handle is encoded as a variable-length opaque field with a maximum size of NFS4_FHSIZE (128 bytes). File handles are the primary object reference in NFSv4.

security

wire-format §2

The nfsace4 Access Control Entry encodes type (acetype4), flag (aceflag4), access_mask (acemask4), and who (utf8str_mixed). ACEs are aggregated into the fattr4_acl recommended attribute.

security

wire-format §2

The nfstime4 structure encodes timestamps as a signed 64-bit integer (seconds) plus an unsigned 32-bit integer (nseconds), providing sub-second precision for file time attributes.

wire-format §2

The OPEN4args structure includes seqid4, share_access (uint32), share_deny (uint32), open_owner4, openflag4 (including createhow4 for CREATE), and open_claim4, capturing the full open semantics including delegation claims.

wire-format §2

The rpcsec_gss_info structure encodes security negotiation data as sec_oid4 (variable opaque OID), qop4 (uint32 quality-of-protection), and rpc_gss_svc_t (NONE=1, INTEGRITY=2, PRIVACY=3), returned in SECINFO responses.

security

wire-format §2

The stateid4 structure encodes state identifiers as a uint32_t seqid followed by a fixed 12-byte (NFS4_OTHER_SIZE) opaque field. State IDs are used to reference open, lock, and delegation state.

wire-format §2

The WRITE4args structure encodes stateid4, offset4, stable_how4 (UNSTABLE4/DATA_SYNC4/FILE_SYNC4), and variable-length opaque data. WRITE4resok returns count4, committed stable_how4, and an 8-byte writeverf verifier.