NFS Services Administrator's Guide (5900-1632, August 2011)
NFSv4 uses the COMPOUND RPC procedure to build sequence of requests into a single RPC.
All RPC requests are classified as either NULL or COMPOUND. All requests that are part of
the COMPOUND procedure are known as operations. An operation is a filesystem action
that forms part of a COMPOUND procedure. NFSv4 currently defines 38 operations.
The server evaluates and processes operations sequentially. If an error is encountered, it is
returned by the server for the entire procedure up to the first operation that causes the error.
The NFSv4 protocol design enables NFS developers to add new operations that are based
on IETF specifications.
• Delegation
In NFSv4, the server can delegate certain responsibilities to the client. Delegation enables a
client to locally service operations, such as OPEN, CLOSE, LOCK, LOCKU, READ, and WRITE,
without immediate interactions with the server.
The server grants either a READ or a WRITE delegation to a client at OPEN. After the delegation
is granted, the client can perform all operations locally. Delegations are disabled, by default.
Delegations can be revoked by the server. If another client requests incompatible access to
the file, the server revokes the delegation. Once the delegation is returned, the other client
can access the file.
• Built-In Security
In NFSv4, the built-in security feature enables the RPC layer to use different security mechanisms.
You can specify a different security policy for each filesystem. The server and the clients can
negotiate supported security flavors on a per filesystem basis.
NFSv4 uses the RPCSEC_GSS framework for authentication, integrity, and privacy. This
framework enables the RPC protocols to access the Generic Security Services Application
Programming Interface (GSS-API).
The RPCSEC_GSS/GSS-API security framework is extensible. However, the new security
flavors, whenever added, must conform to the GSS-API model.
For information on how to secure your systems, see “Secure Sharing of Directories ” (page 24).
• ACLs
An Access Control List (ACL) provides stronger file security, by enabling the owner of a file
to define file permissions for the file owner, the group, and other specific users and groups.
ACL support is built into the protocol. ACLs can be managed from an NFS client using either
the setacl or the getacl command.
For more information on ACLs, see acl(1M),getacl(1M), and setacl(1M).
NOTE: In NFSv2 and NFSv3, ACLs are manipulated using NFSACL protocol. If systems in
your environment do not support the NFSACL protocol, then ACLs cannot be manipulated
using this feature.
• File Handle Types
File handles are created on the server and contain information that uniquely identify files and
directories. Following are the different file handle types:
◦ ROOT
The ROOT file handle represents the conceptual root of the file system namespace on an
NFS server. The NFS client starts with the ROOT file handle by using the PUTROOTFH
operation. This operation instructs the server to set the current file handle to the root of
New Features in NFS 11