Introducing Network File System Version 4 on HP-UX 11i v3

11
Figure 9. LOCK opcode reply
The reply from the server is shown in Figure 9. Notice how the server returns to the client a state
identifier (lines 17 through 19) that identifies this particular lock. Also, the client identifier is returned
to the client (line 22) as well because the server maintains state about the client. In this case, the
server is keeping state about this client’s specific locks.
When the client attempts to release a lock through the LOCKU opcode, the stateid associated with a
lock is passed to the server so that the server can uniquely identify and process this unlock request.
Security
Previous NFS protocol versions did little to encourage use of advanced security. Instead, NFS clients
normally used regular integer-based UNIX authentication (AUTH_SYS) or none at all (AUTH_NONE).
NFSv4, however, ensures the availability of improved security by mandating that compliant NFSv4
implementations include advanced security mechanisms such as Kerberos.
The NFSv4 specification dictates that clients and servers negotiate a security flavor. The client sends
the SECINFO opcode to the server. The server then replies with a list of available security flavors,
listed in preferential order with the most preferred listed first. The client is then free to select which
flavor it prefers. The client and server then use that flavor for the duration of the mounted filesystem.
The AUTH_SYS and AUTH_NONE security flavors are still available on 11i v3 for those customers
wishing to continue using them.
The NFSv4 specification also includes native support for access control lists (ACLs). The ACLs
specification in NFSv4 is modeled on the ACLs present in Windows environments and, consequently,
is closer to what is available in the Windows world. This is another feature that helps NFSv4
interoperate better with Windows systems.