NFSv4 introduced significant changes compared with NFSv3, including how file and directory ownership is represented between NFS servers and clients. While NFSv3 transfers numeric UID and GID values directly as ownership attributes, NFSv4 uses string-based identities such as user@domain and group@domain, introducing an additional identity-mapping mechanism.

This becomes particularly interesting when using AUTH_SYS (sec=sys). Although NFSv4 represents file ownership using these string-based identities, the client still sends numeric UID, GID, and supplementary GID credentials with its RPC requests for access authorization.

In this article, we will take a closer look at these mechanisms under the hood, compare NFSv3 and NFSv4 traffic using packet captures, and see what happens when NFSv4 identity mapping fails. Most importantly, we will distinguish between two concepts that are easily confused:

The credentials used to authorize an NFS request and the attributes used to represent file ownership.


We already encountered the practical impact of NFSv4 ID mapping in my previous article below, where a mismatching ID-mapping domain caused the NFSv4 client to display the ONTAP ownership as nobody:nogroup instead of root:root.

Understanding Windows-to-UNIX User Mapping with UNIX Security Style in NetApp ONTAP


For a deeper look at how AUTH_SYS (sec=sys) credentials are mapped to a Windows identity when accessing NTFS security-style data through NFS, see the following article.

Understanding NFS AUTH_SYS User Mapping with NTFS Security Style in NetApp ONTAP


Table Of Contents
  1. NFSv4 AUTH_SYS Credentials vs. File Ownership Attributes
  2. Root Squashing and UID 0
  3. Links


NFSv4 AUTH_SYS Credentials vs. File Ownership Attributes

The important point is that authentication credentials and file ownership attributes are two different things:

NFSv4 + AUTH_SYS

Client request credentials:
UID 1001 / GID 1001 / supplementary GIDs
                │
                ▼
              ONTAP
                │
                └── Used to evaluate access permissions


NFSv4 file attributes:

ONTAP UID/GID
      │
      ▼
user@NFSv4-domain / group@NFSv4-domain
      │
      ▼
Linux NFSv4 ID mapping
      │
      ▼
Local UID/GID


Figure: On the ONTAP SVM, the configured NFSv4 ID-mapping domain can be verified with vserver nfs show -vserver svm_matrix_nfs -instance, showing the default defaultv4iddomain.com domain used by our NFS server.


With AUTH_SYS, the client sends numeric UID/GID credentials with an NFS request. For example, a request originating from the UNIX user john can contain UID 1001, primary GID 1001, and its supplementary group IDs. ONTAP uses these credentials when evaluating the UNIX permissions of the requested filesystem object.

However, when NFSv4 returns the owner (owner) and group (owner_group) attributes of a file or directory, these identities are represented using name-based NFSv4 identities rather than simply returning the numeric UID and GID as NFSv3 does. Conceptually, an object owned by root:root may therefore be represented as:

root@defaultv4iddomain.com


The part following @ is the NFSv4 ID-mapping domain. It defines the identity namespace and is unrelated to whether AUTH_SYS is used for authentication; it is also not an Active Directory domain.

In our lab, ONTAP initially used:

By default, ONTAP uses defaultv4iddomain.com as the NFSv4 ID-mapping domain unless a different domain is explicitly configured for the NFS server.

defaultv4iddomain.com

Figure: Wireshark capture showing ONTAP returning the NFSv4 owner and owner_group attributes as string identities using the configured NFSv4 ID-mapping domain defaultv4iddomain.com.


while Ubuntu used:

localdomain

Figure: The Ubuntu NFS client’s NFSv4 ID-mapping domain is configured in /etc/idmapd.conf and initially defaults to localdomain; the effective domain can be verified with nfsidmap -d, showing the mismatch with ONTAP’s defaultv4iddomain.com namespace.


Because these NFSv4 identity domains did not match, Ubuntu could not correctly map the owner and group identities returned by ONTAP. It therefore used the configured fallback identities:

Nobody-User = nobody
Nobody-Group = nogroup


After configuring Ubuntu to use the same defaultv4iddomain.com domain as ONTAP and clearing the NFS ID-mapping cache, the same NFSv4-mounted directory immediately changed from:

nobody:nogroup


to the correctly resolved:

root:root


This explains why AUTH_SYS and NFSv4 ID mapping coexist: AUTH_SYS answers “Who is making this request?” using numeric UID/GID credentials, while NFSv4 ID mapping answers “Who owns this file or directory?” by translating the NFSv4 owner and owner_group identities between the server and client.

NFSv4 Ownership Representation

The important distinction is that NFSv4 changes how UNIX ownership information is represented over the protocol, not how ONTAP fundamentally stores it. ONTAP still maintains the underlying UNIX ownership using numeric UID and GID values, together with the UNIX mode bits.

We can verify this directly on ONTAP:

In our example, ONTAP therefore stores the volume root as UID 0 and GID 2000 with mode 770. The corresponding UNIX identities are root and smbwriters, but the filesystem ownership itself is represented internally by these numeric IDs.

vserver security file-directory show -vserver svm_matrix_nfs -path /vol_smb_unix01

Figure 1: ONTAP stores ownership numerically – UID 0 (root) and GID 2000 (smbwriters)


ONTAP can resolve these numeric IDs to UNIX identities through the SVM’s configured name services. In our lab, the local UNIX user database maps UID 0 to root:

vserver services name-service unix-user show -vserver svm_matrix_nfs


By default, an ONTAP SVM provides

Additional UNIX users required for identity mapping must either be created in the SVM’s local UNIX user database or resolved through a configured external name service such as LDAP or NIS.


When this ownership information is presented to an NFSv4 client, however, NFSv4 represents the owner and owner_group attributes as name-based identities rather than exposing the numeric UID and GID as NFSv3 does.

ONTAP therefore translates its numeric UNIX identities into NFSv4 owner identities, and the Linux client maps those identities back to its local UID and GID values.

ONTAP filesystem                 NFSv4                  Linux client

UID 0          ───────►     root@NFSv4-domain     ───────► UID 0
GID 2000       ───────►     smbwriters@NFSv4-domain ─────► GID 2000


On the Ubuntu client, we can verify that the corresponding local UNIX identities use the same numeric IDs, with root using UID 0 and smbwriters using GID 2000. This provides the local UID/GID mapping for the name-based ownership identities presented through NFSv4.


With the volume mounted using NFSv4, the Ubuntu client now correctly resolves and displays the volume root ownership as root:smbwriters. The UNIX mode 770 (rwxrwx---) also corresponds exactly to the ownership and permissions stored on ONTAP.

ls -ld /mnt/vol_smb_unix01/


Using ls -ldn shows the same ownership numerically, with UID 0 and GID 2000 instead of the resolved names root:smbwriters. This demonstrates that the name-based ownership displayed by the NFSv4 client ultimately maps back to the corresponding local numeric UID and GID values.

ls -ldn /mnt/vol_smb_unix01/


The Ubuntu client is configured to use the same NFSv4 ID-mapping domain defaultv4iddomain.com as ONTAP.

This common identity namespace allows NFSv4 owner and owner_group identities exchanged between ONTAP and Ubuntu to be mapped correctly to their corresponding local UNIX users and groups.

cat /etc/idmapd.conf


On the ONTAP SVM, we can verify the corresponding NFSv4 identity namespace with vserver nfs show.

The NFSv4 ID Mapping Domain is also set to defaultv4iddomain.com, matching the configuration on our Ubuntu client and allowing consistent NFSv4 owner and group identity mapping between both systems.

vserver nfs show -vserver svm_matrix_nfs -instance


For example, if we wanted to change our SVM from defaultv4iddomain.com to matrixpost-lab.net:

The important part is that the NFSv4 clients must use the same ID-mapping domain. NetApp explicitly states that the server and target clients must agree on it; it does not have to be your AD, LDAP, NIS, or DNS domain.

Source: https://docs.netapp.com/us-en/ontap/nfs-config/create-server-task.html

vserver nfs modify -vserver svm_matrix_nfs -v4-id-domain matrixpost-lab.net

NFSv3 – Numeric UID and GID Ownership on the Wire

To better understand how file and directory ownership is represented by NFS, we can capture the traffic between the Linux client and ONTAP while retrieving the attributes of our mounted directory.

With NFSv3, ownership is transmitted as numeric UID and GID values, which the Linux client subsequently resolves to local user and group names.


The Linux client then resolves these numeric IDs to their corresponding names. In our example, the mappings are defined locally in /etc/passwd and /etc/group.

getent passwd root
getent group smbwriters

NFSv4 – String-Based Owner and Group Attributes on the Wire

Repeating the same capture with NFSv4 reveals one of the fundamental differences compared with NFSv3. Instead of returning numeric UID and GID values as file ownership attributes, NFSv4 represents the owner and group as strings, typically in the form user@domain and group@domain, which must be mapped appropriately between the NFS server and client.

With NFSv4 mounted, ONTAP returns string-based identities, typically in the form name@domain.

The Linux NFSv4 client therefore needs to map these strings back to identities known on the client. This is where the NFSv4 ID mapping domain becomes important.


NFSv3NFSv4
uid: 0Owner: root@defaultv4iddomain.com
gid: 2000Owner_Group: smbwriters@defaultv4iddomain.com
Numeric ownershipString-based ownership

NFSv4 – What Happens When the ID Mapping Domains Do Not Match?

Unlike NFSv3, NFSv4 represents file and directory ownership using string-based identities such as root@defaultv4iddomain.com and smbwriters@defaultv4iddomain.com.

This makes a consistent NFSv4 ID mapping domain between the NFS server and client important. If the domains do not match, the Linux client may be unable to map the ownership strings returned by ONTAP to its local users and groups, resulting in ownership being displayed as nobody:nogroup instead.

To demonstrate the effect of an NFSv4 ID mapping domain mismatch, we remove the explicitly configured Domain = defaultv4iddomain.com from /etc/idmapd.conf.

The Ubuntu client can therefore no longer correctly map the owner and owner_group strings returned by ONTAP to its local identities.

The getent commands confirm that UID and GID 65534 belong locally to nobody and nogroup on this Ubuntu system. These IDs were therefore not sent by ONTAP; they are the client’s fallback representation for NFSv4 identities that could not be mapped.

cat /etc/idmapd.conf


Although the ownership is now incorrectly displayed as nobody:nogroup, we can still create new folders and files on the NFS share.

This is because the failed NFSv4 ID mapping only affects the mapping/display of the owner and owner_group attributes on the client. Under the hood, with sec=sys, the RPC request still sends the numeric UID and GID of the root user (0:0) to ONTAP, which ONTAP uses for the actual access authorization.

Why NFSv4 Uses String-Based Identities Instead of Numeric UIDs and GIDs

One of the fundamental changes introduced with NFSv4 is how file and directory ownership is represented. While NFSv3 transmits numeric UID and GID values, NFSv4 uses string-based owner and owner_group attributes such as root@defaultv4iddomain.com and smbwriters@defaultv4iddomain.com. This makes ownership less dependent on identical numeric UID/GID assignments across different systems.

This mechanism is an inherent part of NFSv4 and is not dependent on Kerberos. Kerberos can provide strong authentication for NFSv4 using sec=krb5, sec=krb5i, or sec=krb5p, but authentication and the representation of file ownership are separate concepts.

NFSv4 does not require a centralized identity service such as NIS or LDAP. Users and groups can also be maintained locally on the NFS clients and server.

However, in larger environments a centralized identity service is recommended to provide consistent user and group identities across all participating systems and avoid manually maintaining the same identity namespace on every host.

Root Squashing and UID 0

The special UNIX identity UID 0, normally represented by the user root, deserves some additional attention when using NFS.

With AUTH_SYS (sec=sys) also when used with NFSv4, an NFS client sends numeric UID and GID credentials with each request. A process running as root on a Linux client therefore normally presents UID 0 to ONTAP, regardless of whether NFSv3 or NFSv4 is being used.

Without additional protection, trusting this UID would mean that a root user on an NFS client could obtain the privileges of UID 0 on the storage system. This is the reason for root squashing: ONTAP export policies separately control whether requests presenting UID 0 are permitted to retain superuser privileges.

Conceptually:

Linux root
    │
    │ AUTH_SYS UID 0
    ▼
ONTAP export policy
    │
    ├── superuser = sys
    │       │
    │       └── UID 0 retained
    │
    └── superuser = none
            │
            └── UID 0 → anonymous user


By default, ONTAP export rules use -superuser none, which causes UID 0 requests to be mapped to the anonymous user.

The default anonymous UID is 65534, which ONTAP associates with the local UNIX user pcuser. This prevents a root user on an arbitrary NFS client from automatically receiving root privileges on exported data.

pcuser (UID 65534) is ONTAP’s default anonymous/fallback UNIX user and is the identity shown in your export policy’s -anon setting. This is the important account for root squashing.

nobody (UID 65535) is primarily used as an unresolved/unknown UNIX identity when ONTAP cannot map an identity to a valid UNIX user or group.

Figure: For comparison, the svm_matrix_cifs SVM, where we have not created any additional local UNIX users, contains only the three default UNIX accounts root, pcuser, and nobody.


In our export policy, the first two rules use Superuser Security Types: any, allowing requests from the matching clients to retain their UID 0 root identity.

The third rule uses sys, which permits superuser access only when the request is authenticated using AUTH_SYS (sec=sys); requests that do not qualify for superuser access are mapped to the configured anonymous UID 65534 (pcuser).

vserver export-policy rule show -vserver svm_matrix_nfs -policyname nfs_policy -instance

Figure: ONTAP export policy rules showing the configured superuser security types and the default anonymous UID 65534, which is used when a request is mapped to the anonymous identity.


For -superuser specifically, ONTAP supports more than any, sys, and none.

-superuser valueMeaning
anyUID 0 retains superuser privileges regardless of the incoming security type.
noneNo incoming security type is granted UID 0 superuser privileges; root is mapped to the anonymous UID. This is the default.
sysUID 0 retains superuser privileges when authenticated with AUTH_SYS (sec=sys).
krb5UID 0 retains superuser privileges with Kerberos 5 authentication.
krb5iSame with Kerberos authentication plus integrity protection.
krb5pSame with Kerberos authentication, integrity and privacy/encryption.
ntlmGrants superuser access when the applicable security type is NTLM.

Links

Network File System (NFS) Version 4 Protocol
https://www.rfc-editor.org/info/rfc7530/

RPC: Remote Procedure Call Protocol Specification Version 2
https://www.rfc-editor.org/info/rfc5531

Specify the ONTAP user ID domain for NFSv4
https://docs.netapp.com/us-en/ontap/nfs-admin/specify-user-id-domain-nfsv4-task.html

idmapd.conf
https://manpages.ubuntu.com/manpages/noble/man5/idmapd.conf.5.html