NFS Services Administrator's Guide (B.11.31.02) January 2008

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 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.
WARNING! Delegations are disabled, by default. If delegations are enabled, delegations
are only supported by applications that access the delegated files remotely. Local access is
not protected until a future release of HP-UX. Allowing local access and enabling delegation
on a file can corrupt it.
• 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 28).
• 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
New Features in NFS 15