What’s New in NFS Version 4?
Since its introduction in 1984, the Network File System (NFS) has become a standard for network file sharing, particularly in the UNIX® and Linux® communities. Over the last 20 years, the NFS protocol has slowly evolved to adapt to new requirements and market changes.
For most of that time, NetApp has been working to drive the evolution of NFS to better meet user needs. NetApp Chief Technology Officer Brian Pawlowski coauthored the NFS version 3 specification—currently the most widely used version of NFS—and is cochair of the NFS version 4 (NFSv4) working group. NetApp’s Mike Eisler and Dave Noveck are coauthors of the NFS version 4 specification—the latest available version of NFS—and are editors for the NFS version 4.1 specification that is currently under development.
| Personality |
Stateless |
Stateful |
| Semantics |
UNIX only |
Suport UNIX and Windows |
| Authentication |
Weak (AUTH_SYS) |
Strong (Kerberos) |
| Identification |
32 bit UID/GID |
String based (xyz@netapp.com) |
| Permissions |
UNIX based |
Windows like access |
| Transport |
UDP & TCP |
TCP |
| Caching |
Ad-hoc |
Delegations |
Table 1) Comparison of NFSv3 and NFSv4.
NFS consists of server software—for instance, the software that runs on NetApp® storage—and client software running on hosts that require access to network storage. Proper operation requires that both sides of the connection, client and server, are mature and correctly implemented. Although NFS version 4 has been shipping from NetApp since Data ONTAP® 6.4, our code base, underwent a lot of changes and matured substantially, NFSv4 has now reached a point at which we believe it is ready for production use.
Today, client implementations are becoming stable. NetApp has also made some significant changes and enhancements in Data ONTAP 7.3 to support NFSv4. In this article, I'm going to explore three significant features of NFSv4 that have gotten a lot of attention:
- Access control lists (ACLs) for security and Windows® compatibility
- Mandatory security with Kerberos
- Delegations for client-side caching
While this discussion will largely apply to any NFSv4 implementation, I’ll also describe some details that are unique to NetApp and discuss best practices where appropriate.
| Delegations |
Yes |
|
Yes |
|
Yes |
Yes |
Yes |
| Access Control lists |
Yes |
|
Yes |
|
Yes |
Yes |
Yes |
| Kerberos V5 |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| File Streams |
|
|
|
|
|
Yes |
Yes |
| I18n |
Yes |
Yes |
|
Yes |
Yes |
Yes |
Yes |
| Global Namespace/Referrals |
Yes |
|
|
|
Yes |
Future |
|
Table 2) NFSv4 client and server implementation status.
Access Control Lists
ACLs are one of the most frequently requested features by NetApp customers seeking greater compatibility for Windows clients. NFSv4 ACLs significantly improve NFS security and interoperability with CIFS.
ACLs allow access permissions to be granted or denied on a per-user basis for every file object, providing much finer-grained access control and a greater degree of selectivity than traditional UNIX mode permission bits. NFSv4 ACLs are based on the NT model, but they do not contain owner/group information. NFSv4 ACLs are made up of an array of access control entries (ACEs), which contain information regarding access allowed/denied, permission bits, user name/group name, and flags.
Because NetApp already offers ACL support for CIFS clients, the addition of ACLs in NFSv4 creates some unique considerations. NetApp provides three types of qtrees—UNIX, NTFS, and mixed—for use by different clients. The way that NFSv4 ACLS are handled depends on the type of qtree:
UNIX Qtree
- NFSV4 ACLs and mode bits effective
- Windows clients cannot set attributes
- UNIX semantics win
NTFS Qtree
- NT ACLs and mode bits effective; UNIX clients cannot set attributes
- NFSv4 ACLs are generated from the mode bits for NFS clients accessing files with an NT ACL
- NT semantics wins
Mixed Qtree
- NFSv4 ACLs, NT ACLs, and mode bits effective
- Windows and UNIX clients can set attributes
- NFSv4 ACL is generated from the mode bits for files having NT ACLs
Obviously, you should choose the type of qtree you use carefully to get the desired results:
- NFS access only: UNIX qtree
- Mixed access: mixed qtree
- Mostly CIFS access: NTFS qtree
- CIFS only: NTFS qtree
The only other best practice with regard to ACLs is to use no more than 192 ACEs per ACL. You can increase the number of ACEs per ACL to a current maximum of 400, but doing so could present problems should you need to revert to an earlier version of Data ONTAP or if you use SnapMirror® to go to an earlier version.
Mandatory Security
In addition to including ACLs, NFSv4 improves on the security of previous NFS versions by:
- Mandating the availability of strong RPC security that depends on cryptography
- Negotiating the type of security used between server and client via a secure in-band system
- Using character strings instead of integers to represent user and group identifiers
NFS security has been bolstered by the addition of security based on the Generic Security Services API (GSS-API), called RPCSEC_GSS [RFC2203]. All versions of NFS are capable of using RPCSEC_GSS. However, a conforming NFS version 4 implementation must implement RPCSEC_GSS. RPCSEC_GSS is allocated analogous to the commonly used AUTH_SYS security that was the standard method of authentication in previous NFS versions.
RPCSEC_GSS differs from AUTH_SYS and other traditional NFS security mechanisms in two ways:
- RPCSEC_GSS does more than authentication. It is capable of performing integrity checksums and encryption of the entire body of the RPC request and response. Hence, RPCSEC_GSS provides security beyond just authentication.
- Because RPCSEC_GSS simply encapsulates the GSS-API messaging tokens—it merely acts as a transport for mechanism-specific tokens for security mechanisms such as Kerberos—adding new security mechanisms (as long as they conform to GSS-API) does not require rewriting significant portions of NFS.
Figure 1) NFS with AUTH_SYS versus RPCSEC-GSS security.
Both NFSv3 and NFSv4 can use RPCSEC-GSS. However, AUTH_SYS is the default for NFSv3.
The only security mechanism that NetApp or most NFSv4 clients currently provide under RPCSEC_GSS is Kerberos 5. Kerberos is an authentication mechanism that uses symmetrical key encryption. It never sends passwords across the network in either cleartext or encrypted form and relies on encrypted tickets and session keys to authenticate users before they can use network resources. The Kerberos system utilizes key distribution centers (KDCs) that contain a centralized database of user names and passwords. NetApp supports two types of KDCs: UNIX and Windows Active Directory.
You still have the option of using the weak authentication method of previous NFS versions (AUTH_SYS) should you require it. You can accomplish this by specifying sec=sys on the exportfs command line or in the /etc/exports file. Data ONTAP only supports a maximum of 16 supplemental group IDs in a credential plus 1 primary group ID when AUTH_SYS is used. A maximum of 32 supplemental group IDs is supported with Kerberos.
Delegations for Client-Side Caching
In NFSv3, clients typically function as if there is contention for the files they have open, (even though this is often not the case). Weak cache consistency is maintained through frequent requests from the client to the server to find out whether an open file has been modified by someone else, which can cause unnecessary network traffic and delays in high-latency environments. In situations in which a client holds a lock on a file, all write I/O is required to be synchronous, further impacting client-side performance in many situations.
NFSv4 differs from previous versions of NFS by allowing a server to delegate specific actions on a file to a client to enable more aggressive client caching of data and to allow caching of the locking state. A server cedes control of file updates and the locking state to a client via a delegation. This reduces latency by allowing the client to perform various operations and cache data locally. Two types of delegations currently exist: read and write. The server has the ability to call back a delegation from a client should there be contention for a file.
Once a client holds a delegation, it can perform operations on files whose data has been cached locally to avoid network latency and optimize I/O. The more aggressive caching that results from delegations can be a big help in environments with the following characteristics:
- Frequent opens and closes
- Frequent GETATTRs
- File locking
- Read-only sharing
- High latency
- Fast clients
- Heavily loaded server with many clients
Data ONTAP supports both read and write delegations, and you can separately tune the NFSv4 server to enable or disable one or both types of delegations. When delegations are turned on, Data ONTAP will automatically grant a read delegation to a client that opens a file for reading, or a write delegation to a client opening a file for writing.
The options for enabling or disabling read and write delegations have been provided to give you a level of control over the impact of delegations. Ideally, the server determines if it will provide a delegation to clients or not. Turning on read delegation in a highly read-intensive environment will be beneficial. Write delegations in engineering build environments in which each user writes to separate build files and there is no contention will also improve performance. However, write delegations may not be helpful in scenarios in which there are multiple writers to the same file.
Finding Out More
If you’re concerned about data security (and who isn’t?), new NFSv4 features such as ACL support and mandatory security can significantly reduce the risk of unauthorized data access. Another important design goal for NFSv4 was improved performance on the Internet. Improved client caching behavior through delegations was intended to help satisfy this goal.
In addition to the highly visible changes I’ve described, NFSv4 includes a number of other significant changes, including:
- Elimination of the independent mount daemon and other accessory services that require additional open ports
- Compound requests that group common tasks into a single operation to accelerate response and reduce network traffic
If you want to learn more about these and other features of NFSv4, TR-3085 (PDF) provides a good general reference.
 |
Bikash R. Choudhury
Solutions Architect
NetApp
In his current role as NFS/technical application solutions architect, Bikash spends his time designing architectures for technical application solutions that use NFS, performing functional testing and certifications, and providing Global Partner Alliance support for NFS best practices. Bikash started at NetApp eight years ago as a technical support engineer, and later became the technical global advisor (TGA) for one of NetApp's largest customers.
|