Using NFSv4

Support for NFSv4

Data ONTAP supports all of the mandatory functionality in NFSv4, except the SPKM3 and LIPKEY security mechanisms, including the following:

COMPOUND--Allows a client to request multiple file operations in a single remote procedure call (RPC) request.
File delegation--Allows the server to delegate file control to some types of clients for read and write access.
Pseudo-fs--Used by NFSv4 servers to determine mount points on the storage system. There is no mount protocol in NFSv4.
Locking--Lease-based. There are no separate Network Lock Manager (NLM) or Network Status Monitor (NSM) protocols in NFSv4.
Named attributes--Similar to Windows NT streams.

Limitations for NFSv4

Be aware of the following limitations when using NFSv4 with Data ONTAP:

Delegation feature is not supported by every client type.
Named attributes can only be created if CIFS is running on the storage system.
Names with non-ASCII characters on volumes other than UTF8 volumes are rejected by the storage system.
All file handles are persistent. The server does not give volatile file handles.
Migration and replication are not supported.
All recommended attributes are supported, except for the following:
- archive
- hidden
- homogeneous
- mimetype
- quota_avail_hard
- quota_avail_soft
- quota_used
- system
- time_backup
NFSv4 does not use the User Datagram Protocol (UDP) transport protocol. If you enable NFSv4 and disable NFS over TCP by setting options nfs.tcp.enable to Off, then NFSv4 is effectively disabled.
Note
On new installations, NFSv4 is disabled by default.

How NFSv4 delegation features work on the storage system

NFSv4 provides server-to-client delegation for file operations.

Delegation of file operations can reduce latency, particularly in environments that

Exhibit a high volume of file open and close requests
Place a heavy load on the server, with a large number of clients and concurrent read sharing operations
Already strain resources because of a high load or numerous clients
Already demonstrate file access latency problems
Have a large number of fast clients trying to access files

Client support for delegation

Delegations are supported only over NFSv4 (not over prior NFS versions). To verify that a specific client type supports delegation, see the client operating system documentation or feature support documentation.

Prerequisites for storage system delegation

Delegation of file operations requires the following configuration criteria to be met:

The requesting client must support delegation and be running NFSv4.
No other client has the file open for writing or "deny read."
There is a recall path present, so the storage system can recall the delegation.

Delegation works on files within any style of qtree, whether or not oplocks have been enabled.

Recalling read delegation

Delegation of file operations to a client can be recalled when the lease expires, or when the storage system receives the following requests from another client:

Write to file, open file for writing, or open file for "deny read"
Change file attributes
Rename file
Delete file

Delegation state recovery

When the server reboots, the delegation state is lost. Clients may reclaim the delegation state upon reconnection, instead of going through the entire delegation request process again. When a client holding a read delegation reboots, all delegation state information will be flushed from the storage system cache upon reconnect. The client must issue a delegation request to establish a new delegation.

Enabling and disabling read delegation

By default, read delegation is disabled. To modify the read delegation setting, complete the following step.

Step	Action
1	Enter the following command: options nfs.v4.read_delegation on \| off

Note
Delegation options take effect as soon as they are changed. There is no need to reboot or restart NFS.

Enabling and disabling write delegation

By default, write delegation is disabled. To modify the write delegation setting, complete the following step.

Step	Action
1	Enter the following command: options nfs.v4.write_delegation on \| off

Note
Delegation options take effect as soon as they are changed. There is no need to reboot or restart NFS.

Retrieving delegation statistics

Use the nfsstat command to retrieve information about delegation requests, as described in the following sections. Results returned by the nfsstat command include delegation requests that have been granted as well as requests that have been denied due to an error. For information about delegation requests your storage system has denied, view the system log file.

You can view delegation information:

Per client
Per vFiler unit
Per storage system

Use the procedures described in the following sections to retrieve delegation information.

Viewing delegation statistics for all clients

To view delegation information for all clients, complete the following step.

Step	Action
1	Enter the following command: nfsstat -h

The storage system will return individual delegation statistics for each client.

Viewing delegation statistics for a specific client

To view delegation information for a specific client, complete the following step.

Step

Action

1
Enter the following command:

nfsstat -h <hostname or ip_address>

Step	Action
1	Enter the following command: *nfsstat -h <hostname* or ip_address>**

The storage system will return individual delegation statistics for the specified client.

Viewing delegation statistics for a vFiler unit

To view delegation information specific to a vFiler unit, complete the following step.

Step	Action
1	Enter the following command: *vfiler run <filername> nfsstat -d*

Viewing delegation statistics for a storage system

To view delegation information specific to a storage system, complete the following step.

Step	Action
1	Enter the following command: nfsstat -d

The storage system returns the total number of delegations handled by the storage system, including current delegations and any that have been recalled. To view only current delegations handled by the storage system, use the lock status command.

When a lease expires

When a lease expires the delegation state is revoked and all of the associated state is marked "soft." That means if the storage system receives a conflicting lock request for this same file from another client before the lease has been renewed by the client previously holding the delegation, the conflicting lock is granted. If there is no conflicting lock and the client holding the delegation renews the lease, then the soft locks are changed to hard lock and will not be removed on a conflicting access. However the delegation is not granted again upon a lease renewal.

How the pseudo-fs in NFSv4 affects mount points

NFSv4 uses a pseudo-fs (file system) as an entry point into your storage system for determining mount points. A pseudo-fs allows you to use one port for security, rather than several. All NFSv4 servers support the use of a pseudo-fs.

You may experience inconsistencies with mount points between NFSv3 and NFSv4, because of the pseudo-fs used in NFSv4.

In the examples that follow, you have these volumes:

/vol/vol0 (root)
/vol/vol1
/vol/home

Example 1

In NFSv3 if you do not use the complete path from /vol/vol0, and you mount filer:/, the mount point is filer:/vol/vol0. That is, if the path does not begin with /vol in NFSv3, then Data ONTAP adds /vol/vol0 to the beginning of the path.

In NFSv4, if you do not use the complete path from /vol/vol0 and you mount filer:/, you mount the root of the pseudo-fs and not /vol/vol0. Data ONTAP does not add /vol/vol0 to the beginning of the path.

Therefore, if you mount filer:/ /n/filer using NFSv3 and try the same mount using NFSv4, you would mount a different file system.

Example 2

In Data ONTAP's implementation of the NFSv4 pseudo-fs, the nodes "/" and "/vol" are always present and form the common prefix of any reference into the pseudo-fs. Any reference that does not begin with "/vol" is invalid.

In this example, there is a /vol/vol0/home directory. In NFSv3, if you mount filer:/home/users, /home is considered as the directory /vol/vol0/home. In NFSv4, if you mount filer:/home/users, /home is not interpreted as the volume /vol/home; it is considered an invalid path in the pseudo-fs tree.

Specifying the user ID domain for NFSv4

The domain that Data ONTAP uses for NFSv4 user ID mapping by default is the NIS domain, if one is set. If an NIS domain is not set, the DNS domain is used. You might need to set the user ID domain if, for example, you have multiple user ID domains.

To specify the user ID domain to be used for NFSv4 user ID mapping, complete the following step.

Step	Action
1	Enter the following command: options nfs.v4.id_domain domain

About NFSv4 ACLs

Compared to NFSv4 file access without access control lists (ACL), NFSv4 ACLs provide the following benefits:

Finer-grained control of user access for files and directories
Better NFS security
Improved interoperability with CIFS
Removal of the NFS 16 groups per user limitation

NFSv4 ACLs are different from Windows file-level ACLs (NTFS ACLs), but Data ONTAP can map NFSv4 ACLs to NTFS ACLs for viewing on Windows platforms.

Note
Data ONTAP does not support POSIX ACLs.

To set and modify NFSv4 ACLs, NFSv4 must be enabled and NFSv4 ACLs must be enabled. (See Enabling and disabling NFSv4 ACLs for more information.) Once enabled, ACLs are set or modified from clients using NFSv4.

ACL characteristics using NFSv4

With NFSv4 enabled, and nfs.v4.acl.enable on, a client using NFSv4 ACLs can set ACLs on files and directories on the system. When a file or subdirectory of a directory with an ACL is created, they inherit appropriate ACL values. While it is off, ACL values cannot be viewed from the client.

For access checking, CIFS users are mapped to UNIX users. The mapped UNIX user and that user's group membership are checked against the ACL.

If a file or directory has an ACL, that ACL is used to control access no matter what protocol--NFSv2, NFSv3, NFSv4, or CIFS--is used to access the file or directory and is used even if NFSv4 is no longer enabled on the system.

Inheriting an NFSv4 ACL

Files and directories inherit NFSv4 ACLs from parent directories (possibly with appropriate modifications).

When a file or directory is created as the result of an NFSv4 request, the ACL on the resulting file or directory depends on whether the file creation request includes an ACL or only standard UNIX file access permissions, and whether the parent directory has an ACL:

If the request includes an ACL, that ACL is used.
If the request includes only standard UNIX file access permissions, but the parent directory has an ACL, the parent directory ACL (possibly with modifications) is inherited by the new file or directory.
Note
A parent ACL is inherited even if nfs.v4.acl.enable is off.
If the request includes only standard UNIX file access permissions, and the parent directory does not have an ACL, then the client file mode is used to set standard UNIX file access permissions.

ACLs and qtrees

The security semantics of a qtree are determined by its security style and its ACL (NFSv4 or NTFS):

For a qtree with UNIX security style
- NFSv4 ACLs and mode bits are effective.
- NTFS ACLs are not enforced.
- Windows clients cannot set attributes.
For a qtree with mixed security style
- NFSv4 ACLs and mode bits are effective.
- NTFS ACLs are enforced.
- Both Windows and UNIX clients can set attributes.
  Note
  A qtree can have either an NFSv4 ACL or NTFS ACL, but not both. Data ONTAP will remap one type to the other, as necessary.
For a qtree with NTFS security style
- NFSv4 ACLs are not enforced.
- NTFS ACLs and mode bits are effective and are enforced.
- UNIX clients cannot set attributes.

Enabling and disabling NFSv4 ACLs

Use the nfs.v4.acl.enable option (disabled by default) to control the setting and viewing of NFSv4 ACLs.

To modify the nfs.v4.acl.enable option setting, complete the following step.

Step	Action
1	Enter the following command: options nfs.acl.enable on \| off [off]

Note
The nfs.v4.acl.enable option does not affect whether an ACL is enforced and does not affect existing ACLs.

Setting or Modifying an NFSv4 ACL

Use the setfacl command to set or modify an NFSv4 ACL.

To set an ACL granting the user nfsuser read, write, and execute permission on file a, complete the following step.

Step	Action
1	Enter the following command: setfacl -m user:nfsuser:rwx a

Viewing an NFSc4 ACL

To view an NFSv4 ACL, complete the following step.

Step	Action
1	Enter the following command: getfacl a # file: a # owner: nfs4user # group: engr user::rw- user:nfs4user:rwx #effective:rwx group::r-- #effective:r-- mask:rwx other:r-- Note that running the `ls -l` command for the same file shows the following: -rw-r--r--+ 1 nfs4user 0 May 27 17:43 a The + in this output indicates that the Solaris client recognized that an ACL is set on the file.

Step

Action

Enter the following command:

getfacl a

# file: a

# owner: nfs4user

# group: engr

user::rw-

user:nfs4user:rwx          #effective:rwx

group::r--              #effective:r--

mask:rwx

other:r--

Note that running the ls -l command for the same file shows the following:

-rw-r--r--+  1 nfs4user 0 May 27 17:43 a

The + in this output indicates that the Solaris client recognized that an ACL is set on the file.