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.


Table Of Contents
  1. NFSv4 AUTH_SYS Credentials vs. File Ownership Attributes
  2. 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


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:

defaultv4iddomain.com


while Ubuntu used:

localdomain


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)


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.

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