Skip to main content
NetApp Solutions

NFS

Contributors kevin-hoke
PDFs

NFS is a distributed file system protocol that is an open IETF standard defined in Request for Comments (RFC) that allows anyone to implement the protocol.

Volumes in Google Cloud NetApp Volumes are shared out to NFS clients by exporting a path that is accessible to a client or set of clients. Permissions to mount these exports are defined by export policies and rules, which are configurable by Google Cloud NetApp Volumes administrators.

The NetApp NFS implementation is considered a gold standard for the protocol and is used in countless enterprise NAS environments. The following sections cover NFS and specific security features available in Google Cloud NetApp Volumes and how they are implemented.

Default local UNIX users and groups

Google Cloud NetApp Volumes contains several default UNIX users and groups for various basic functionalities. These users and groups cannot currently be modified or deleted. New local users and groups cannot currently be added to Google Cloud NetApp Volumes. UNIX users and groups outside of the default users and groups need to be provided by an external LDAP name service.

The following table shows the default users and groups and their corresponding numeric IDs. NetApp recommends not creating new users or groups in LDAP or on the local clients that re-use these numeric IDs.

Default users: numeric IDs Default groups: numeric IDs

  • root:0

  • pcuser:65534

  • nobody:65535

  • root:0

  • daemon:1

  • pcuser:65534

  • nobody:65535
Note When using NFSv4.1, the root user might display as nobody when running directory listing commands on NFS clients. This is due to the client’s ID domain mapping configuration. See the section called NFSv4.1 and the nobody user/group for details on this issue and how to resolve it.

The root user

In Linux, the root account has access to all commands, files, and folders in a Linux-based file system. Because of the power of this account, security best practices often require the root user to be disabled or restricted in some fashion. In NFS exports, the power a root user has over the files and folders can be controlled in Google Cloud NetApp Volumes through export policies and rules and a concept known as root squash.

Root squashing ensures that the root user accessing an NFS mount is squashed to the anonymous numeric user 65534 (see the section “The anonymous user”) and is currently only available when using NetApp Volumes-Performance by selecting Off for root access during export policy rule creation. If the root user is squashed to the anonymous user, it no longer has access to run chown or setuid/setgid commands (the sticky bit) on files or folders in the NFS mount, and files or folders created by the root user show the anon UID as the owner/group. In addition, NFSv4 ACLs cannot be modified by the root user. However, the root user still has access to chmod and deleted files that it does not have explicit permissions for. If you want to limit access to a root user’s file and folder permissions, consider using a volume with NTFS ACLs, creating a Windows user named root, and applying the desired permissions to the files or folders.

The anonymous user

The anonymous (anon) user ID specifies a UNIX user ID or username that is mapped to client requests that arrive without valid NFS credentials. This can include the root user when root squashing is used. The anon user in Google Cloud NetApp Volumes is 65534.

This UID is normally associated with the username nobody or nfsnobody in Linux environments. Google Cloud NetApp Volumes also uses 65534 as the local UNIX user` pcuser` (see the section “Default local UNIX users and groups”), which is also the default fallback user for Windows to UNIX name mappings when no valid matching UNIX user can be found in LDAP.

Because of the differences in usernames across Linux and Google Cloud NetApp Volumes for UID 65534, the name string for users mapped to 65534 might not match when using NFSv4.1. As a result, you might see nobody as the user on some files and folders. See the section “NFSv4.1 and the nobody user/group” for information about this issue and how to resolve it.

Access control/exports

Initial export/share access for NFS mounts is controlled through host- based export policy rules contained within an export policy. A host IP, host name, subnet, netgroup, or domain is defined to allow access to mount the NFS share and the level of access allowed to the host. Export policy rule configuration options depend on the Google Cloud NetApp Volumes level.

For NetApp Volumes-SW, the following options are available for export-policy configuration:

  • Client match. Comma-separated list of IP addresses, comma-separated list of hostnames, subnets, netgroups, domain names.

  • RO/RW access rules. Select read/write or read only to control level of access to export.NetApp Volumes-Performance provides the following options:

  • Client match. Comma-separated list of IP addresses, comma-separated list of hostnames, subnets, netgroups, domain names.

  • RO/RW access rules. Select read/write or read only to control level of access to export.

  • Root access (on/off). Configures root squash (see the section “The root user" for details).

  • Protocol type. This limits access to the NFS mount to a specific protocol version. When specifying both NFSv3 and NFSv4.1 for the volume, either leave both blank or check both boxes.

  • Kerberos security level (when Enable Kerberos is selected). Provides the options of krb5, krb5i, and/or krb5p for read-only or read-write access.

Change ownership (chown) and change group (chgrp)

NFS on Google Cloud NetApp Volumes only allows the root user to run chown/chgrp on files and folders. Other users see an Operation not permitted error— even on files they own. If you use root squash (as covered in the section “The root user”), the root is squashed to a nonroot user and is not allowed access to chown and chgrp. There are currently no workarounds in Google Cloud NetApp Volumes to allow chown and chgrp for non-root users. If ownership changes are required, consider using dual protocol volumes and set the security style to NTFS to control permissions from the Windows side.

Permission management

Google Cloud NetApp Volumes supports both mode bits (such as 644, 777, and so on for rwx) and NFSv4.1 ACLs to control permissions on NFS clients for volumes that use the UNIX security style. Standard permission management is used for these (such as chmod, chown, or nfs4_setfacl) and work with any Linux client that supports them.

Additionally, when using dual protocol volumes set to NTFS, NFS clients can leverage Google Cloud NetApp Volumes name mapping to Windows users, which then are used to resolve the NTFS permissions. This requires an LDAP connection to Google Cloud NetApp Volumes to provide numeric-ID-to- username translations because Google Cloud NetApp Volumes requires a valid UNIX username to map properly to a Windows username.

Providing granular ACLs for NFSv3

Mode bit permissions cover only owner, group, and everyone else in the semantics—meaning that there are no granular user access controls in place for basic NFSv3. Google Cloud NetApp Volumes does not support POSIX ACLs, nor extended attributes (such as chattr), so granular ACLs are only possible in the following scenarios with NFSv3:

  • NTFS security style volumes (CIFS server required) with valid UNIX to Windows user mappings.

  • NFSv4.1 ACLs applied using an admin client mounting NFSv4.1 to apply ACLs.

Both methods require an LDAP connection for UNIX identity management and a valid UNIX user and group information populated (see the section “LDAP”) and are only available with NetApp Volumes-Performance instances. To use NTFS security style volumes with NFS, you must use dual-protocol (SMB and NFSv3) or dual-protocol (SMB and NFSv4.1), even if no SMB connections are made. To use NFSv4.1 ACLs with NFSv3 mounts, you must select Both (NFSv3/NFSv4.1) as the protocol type.

Regular UNIX mode bits don’t provide the same level of granularity in permissions that NTFS or NFSv4.x ACLs provide. The following table compares the permission granularity between NFSv3 mode bits and NFSv4.1 ACLs. For information about NFSv4.1 ACLs, see nfs4_acl - NFSv4 Access Control Lists.

NFSv3 mode bits NFSv4.1 ACLs

  • Set user ID on execution

  • Set group ID on execution

  • Save swapped text (not defined in POSIX)

  • Read permission for owner

  • Write permission for owner

  • Execute permission for owner on a file; or look up (search) permission for owner in directory

  • Read permission for group

  • Write permission for group

  • Execute permission for group on a file; or look up (search) permission for group in directory

  • Read permission for others

  • Write permission for others

  • Execute permission for others on a file; or look up (search) permission for others in directory

Access control entry (ACE) types (Allow/Deny/Audit)
* Inheritance flags
* directory-inherit
* file-inherit
* no-propagate-inherit
* inherit-only

Permissions
* read-data (files) / list-directory (directories)
* write-data (files) / create-file (directories)
* append-data (files) / create-subdirectory (directories)
* execute (files) / change-directory (directories)
* delete
* delete-child
* read-attributes
* write-attributes
* read-named-attributes
* write-named-attributes
* read-ACL
* write-ACL
* write-owner
* Synchronize

Finally, NFS group membership (in both NFSv3 and NFSV4.x) is limited to a default maximum of 16 for AUTH_SYS as per the RPC packet limits. NFS Kerberos provides up to 32 groups and NFSv4 ACLs remove the limitation by way of granular user and group ACLs (up to 1024 entries per ACE).

Additionally, Google Cloud NetApp Volumes provides extended group support to extend the maximum supported groups up to 32. This requires an LDAP connection to an LDAP server that contains valid UNIX user and group identities. For more information about configuring this, see Creating and managing NFS volumes in the Google documentation.

NFSv3 user and group IDs

NFSv3 user and group IDs come across the wire as numeric IDs rather than names. Google Cloud NetApp Volumes does no username resolution for these numeric IDs with NFSv3, with UNIX security style volumes using just mode bits. When NFSv4.1 ACLs are present, a numeric ID lookup and/or name string lookup is needed to resolve the ACL properly—even when using NFSv3. With NTFS security style volumes, Google Cloud NetApp Volumes must resolve a numeric ID to a valid UNIX user and then map to a valid Windows user to negotiate access rights.

Security limitations of NFSv3 user and group IDs

With NFSv3, the client and server never have to confirm that the user attempting a read or write with a numeric ID is a valid user; it is just implicitly trusted. This opens the file system up to potential breaches simply by spoofing any numeric ID. To prevent security holes like this, there are a few options available to Google Cloud NetApp Volumes.

  • Implementing Kerberos for NFS forces users to authenticate with a username and password or keytab file to get a Kerberos ticket to allow access into a mount. Kerberos is available with NetApp Volumes-Performance instances and only with NFSv4.1.

  • Limiting the list of hosts in your export policy rules limits which NFSv3 clients have access to the Google Cloud NetApp Volumes volume.

  • Using dual-protocol volumes and applying NTFS ACLs to the volume forces NFSv3 clients to resolve numeric IDs to valid UNIX usernames to authenticate properly to access mounts. This requires enabling LDAP and configuring UNIX user and group identities.

  • Squashing the root user limits the damage a root user can do to an NFS mount but does not completely remove risk. For more information, see the section “The root user.”

Ultimately, NFS security is limited to what the protocol version you are using offers. NFSv3, while more performant in general than NFSv4.1, does not provide the same level of security.

NFSv4.1

NFSv4.1 provides greater security and reliability as compared to NFSv3, for the following reasons:

  • Integrated locking through a lease-based mechanism

  • Stateful sessions

  • All NFS functionality over a single port (2049)

  • TCP only

  • ID domain mapping

  • Kerberos integration (NFSv3 can use Kerberos, but only for NFS, not for ancillary protocols such as NLM)

NFSv4.1 dependencies

Because of the additionally security features in NFSv4.1, there are some external dependencies involved that were not needed to use NFSv3 (similar to how SMB requires dependencies such as Active Directory).

NFSv4.1 ACLs

Google Cloud NetApp Volumes offers support for NFSv4.x ACLs, which deliver distinct advantages over normal POSIX-style permissions, such as the following:

  • Granular control of user access to files and directories

  • Better NFS security

  • Improved interoperability with CIFS/SMB

  • Removal of the NFS limitation of 16 groups per user with AUTH_SYS security

  • ACLs bypass the need for group ID (GID) resolution, which effectively removes the GID limitNFSv4.1 ACLs are controlled from NFS clients—not from Google Cloud NetApp Volumes. To use NFSv4.1 ACLs, be sure your client’s software version supports them and the proper NFS utilities are installed.

Compatibility between NFSv4.1 ACLs and SMB clients

NFSv4 ACLs are different from Windows file-level ACLs (NTFS ACLs) but carry similar functionality. However, in multiprotocol NAS environments, if NFSv4.1 ACLs are present and you are using dual-protocol access (NFS and SMB on the same datasets), clients using SMB2.0 and later won’t be able to view or manage ACLs from Windows security tabs.

How NFSv4.1 ACLs work

For reference, the following terms are defined:

  • Access control list (ACL). A list of permissions entries.

  • Access control entry (ACE). A permission entry in the list.

When a client sets an NFSv4.1 ACL on a file during a SETATTR operation, Google Cloud NetApp Volumes sets that ACL on the object, replacing any existing ACL. If there is no ACL on a file, then the mode permissions on the file are calculated from OWNER@, GROUP@, and EVERYONE@. If there are any existing SUID/SGID/STICKY bits on the file, they are not affected.

When a client gets an NFSv4.1 ACL on a file during the course of a GETATTR operation, Google Cloud NetApp Volumes reads the NFSv4.1 ACL associated with the object, constructs a list of ACEs, and returns the list to the client. If the file has an NT ACL or mode bits, then an ACL is constructed from mode bits and is returned to the client.

Access is denied if a DENY ACE is present in the ACL; access is granted if an ALLOW ACE exists. However, access is also denied if neither of the ACEs is present in the ACL.

A security descriptor consists of a security ACL (SACL) and a discretionary ACL (DACL). When NFSv4.1 interoperates with CIFS/SMB, the DACL is one-to-one mapped with NFSv4 and CIFS. The DACL consists of the ALLOW and the DENY ACEs.

If a basic chmod is run on a file or folder with NFSv4.1 ACLs set, existing user and group ACLs are preserved, but the default OWNER@, GROUP@, EVERYONE@ ACLs are modified.

A client using NFSv4.1 ACLs can set and view ACLs for files and directories on the system. When a new file or subdirectory is created in a directory that has an ACL, that object inherits all ACEs in the ACL that have been tagged with the appropriate inheritance flags.

If a file or directory has an NFSv4.1 ACL, that ACL is used to control access no matter which protocol is used to access the file or directory.

Files and directories inherit ACEs from NFSv4 ACLs on parent directories (possibly with appropriate modifications) as long as the ACEs have been tagged with the correct inheritance flags.

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. The ACL also depends on 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 and the parent directory does not have an ACL, the client file mode is used to set standard UNIX file access permissions.

  • If the request includes only standard UNIX file access permissions and the parent directory has a noninheritable ACL, a default ACL based on the mode bits passed into the request is set on the new object.

  • If the request includes only standard UNIX file access permissions but the parent directory has an ACL, the ACEs in the parent directory's ACL are inherited by the new file or directory as long as the ACEs have been tagged with the appropriate inheritance flags.

ACE permissions

NFSv4.1 ACLs permissions uses a series of upper- and lower-case letter values (such as rxtncy) to control access. For more information about these letter values, see HOW TO: Use NFSv4 ACL.

NFSv4.1 ACL behavior with umask and ACL inheritance

NFSv4 ACLs provide the ability to offer ACL inheritance. ACL inheritance means that files or folders created beneath objects with NFSv4.1 ACLs set can inherit the ACLs based on the configuration of the ACL inheritance flag.

Umask is used to control the permission level at which files and folders are created in a directory without administrator interaction. By default, Google Cloud NetApp Volumes allows umask to override inherited ACLs, which is expected behavior as per RFC 5661.

ACL formatting

NFSv4.1 ACLs have specific formatting. The following example is an ACE set on a file:

A::ldapuser@domain.netapp.com:rwatTnNcCy

The preceding example follows the ACL format guidelines of:

type:flags:principal:permissions

A type of A means “allow.” The inherit flags are not set in this case, because the principal is not a group and does not include inheritance. Also, because the ACE is not an AUDIT entry, there is no need to set the audit flags. For more information about NFSv4.1 ACLs, see http://linux.die.net/man/5/nfs4_acl.

If the NFSv4.1 ACL is not set properly (or a name string cannot be resolved by the client and server), the ACL might not behave as expected, or the ACL change might fail to apply and throw an error.

Sample errors include:

Failed setxattr operation: Invalid argument
Scanning ACE string 'A:: user@rwaDxtTnNcCy' failed.

Explicit DENY

NFSv4.1 permissions can include explicit DENY attributes for OWNER, GROUP, and EVERYONE. That is because NFSv4.1 ACLs are default-deny, which means that if an ACL is not explicitly granted by an ACE, then it is denied. Explicit DENY attributes override any ACCESS ACEs, explicit or not.

DENY ACEs are set with an attribute tag of D.

In the example below, GROUP@ is allowed all read and execute permissions, but denied all write access.

sh-4.1$ nfs4_getfacl /mixed
A::ldapuser@domain.netapp.com:ratTnNcCy
A::OWNER@:rwaDxtTnNcCy
D::OWNER@:
A:g:GROUP@:rxtncy
D:g:GROUP@:waDTC
A::EVERYONE@:rxtncy
D::EVERYONE@:waDTC

DENY ACEs should be avoided whenever possible because they can be confusing and complicated; ALLOW ACLs that are not explicitly defined are implicitly denied. When DENY ACEs are set, users might be denied access when they expect to be granted access.

The preceding set of ACEs is equivalent to 755 in mode bits, which means:

  • The owner has full rights.

  • Groups have read only.

  • Others have read only.

However, even if permissions are adjusted to the 775 equivalent, access can be denied because of the explicit DENY set on EVERYONE.

NFSv4.1 ID domain mapping dependencies

NFSv4.1 leverages ID domain mapping logic as a security layer to help verify that a user attempting access to an NFSv4.1 mount is indeed who they claim to be. In these cases, the username and group name coming from the NFSv4.1 client appends a name string and sends it to the Google Cloud NetApp Volumes instance. If that username/group name and ID string combination does not match, then the user and/or group is squashed to the default nobody user specified in the /etc/idmapd.conf file on the client.

This ID string is a requirement for proper permission adherence, especially when NFSv4.1 ACLs and/or Kerberos are in use. As a result, name service server dependencies such as LDAP servers are necessary to ensure consistency across clients and Google Cloud NetApp Volumes for proper user and group name identity resolution.

Google Cloud NetApp Volumes uses a static default ID domain name value of defaultv4iddomain.com. NFS clients default to the DNS domain name for its ID domain name settings, but you can manually adjust the ID domain name in /etc/idmapd.conf.

If LDAP is enabled in Google Cloud NetApp Volumes, then Google Cloud NetApp Volumes automates the NFS ID domain to change to what is configured for the search domain in DNS and clients won’t need to be modified unless they use different DNS domain search names.

When Google Cloud NetApp Volumes can resolve a username or group name in local files or LDAP, the domain string is used and non-matching domain IDs squash to nobody. If Google Cloud NetApp Volumes cannot find a username or group name in local files or LDAP, the numeric ID value is used and the NFS client resolves the name properly (this is similar to NFSv3 behavior).

Without changing the client’s NFSv4.1 ID domain to match what the Google Cloud NetApp Volumes volume is using, you see the following behavior:

  • UNIX users and groups with local entries in Google Cloud NetApp Volumes (such as root, as defined in local UNIX users and groups) are squashed to the nobody value.

  • UNIX users and groups with entries in LDAP (if Google Cloud NetApp Volumes is configured to use LDAP) squashes to nobody if DNS domains are different between NFS clients and Google Cloud NetApp Volumes.

  • UNIX users and groups with no local entries or LDAP entries use the numeric ID value and resolve to the name specified on the NFS client. If no name exists on the client, only the numeric ID is shown.

The following shows the results of the preceding scenario:

# ls -la /mnt/home/prof1/nfs4/
total 8
drwxr-xr-x 2 nobody nobody 4096 Feb  3 12:07 .
drwxrwxrwx 7 root   root   4096 Feb  3 12:06 ..
-rw-r--r-- 1   9835   9835    0 Feb  3 12:07 client-user-no-name
-rw-r--r-- 1 nobody nobody    0 Feb  3 12:07 ldap-user-file
-rw-r--r-- 1 nobody nobody    0 Feb  3 12:06 root-user-file

When the client and server ID domains match, this is how the same file listing looks:

# ls -la
total 8
drwxr-xr-x 2 root   root         4096 Feb  3 12:07 .
drwxrwxrwx 7 root   root         4096 Feb  3 12:06 ..
-rw-r--r-- 1   9835         9835    0 Feb  3 12:07 client-user-no-name
-rw-r--r-- 1 apache apache-group    0 Feb  3 12:07 ldap-user-file
-rw-r--r-- 1 root   root            0 Feb  3 12:06 root-user-file

For more information about this issue and how to resolve it, see the section “NFSv4.1 and the nobody user/group.”

Kerberos dependencies

If you plan to use Kerberos with NFS, you must have the following with Google Cloud NetApp Volumes:

  • Active Directory domain for Kerberos Distribution Center services (KDC)

  • Active Directory domain with user and group attributes populated with UNIX information for LDAP functionality (NFS Kerberos in Google Cloud NetApp Volumes requires a user SPN to UNIX user mapping for proper functionality.)

  • LDAP enabled on the Google Cloud NetApp Volumes instance

  • Active Directory domain for DNS services

NFSv4.1 and the nobody user/group

One of the most common issues seen with an NFSv4.1 configuration is when a file or folder is shown in a listing using ls as being owned by the user:group combination of nobody:nobody.

For example:

sh-4.2$ ls -la | grep prof1-file
-rw-r--r-- 1 nobody nobody    0 Apr 24 13:25 prof1-file

And the numeric ID is 99.

sh-4.2$ ls -lan | grep prof1-file
-rw-r--r-- 1 99 99    0 Apr 24 13:25 prof1-file

In some instances, the file might show the correct owner but nobody as the group.

sh-4.2$ ls -la | grep newfile1
-rw-r--r-- 1 prof1  nobody    0 Oct  9  2019 newfile1

Who is nobody?

The nobody user in NFSv4.1 is different from the nfsnobody user. You can view how an NFS client sees each user by running the id command:

# id nobody
uid=99(nobody) gid=99(nobody) groups=99(nobody)
# id nfsnobody
uid=65534(nfsnobody) gid=65534(nfsnobody) groups=65534(nfsnobody)

With NFSv4.1, the nobody user is the default user defined by the idmapd.conf file and can be defined as any user you want to use.

# cat /etc/idmapd.conf | grep nobody
#Nobody-User = nobody
#Nobody-Group = nobody

Why does this happen?

Because security through name string mapping is a key tenet of NFSv4.1 operations, the default behavior when a name string does not match properly is to squash that user to one that won’t normally have any access to files and folders owned by users and groups.

When you see nobody for the user and/or group in file listings, this generally means something in NFSv4.1 is misconfigured. Case sensitivity can come into play here.

For example, if user1@CVSDEMO.LOCAL (uid 1234, gid 1234) is accessing an export, then Google Cloud NetApp Volumes must be able to find user1@CVSDEMO.LOCAL (uid 1234, gid 1234). If the user in Google Cloud NetApp Volumes is USER1@CVSDEMO.LOCAL, then it won’t match (uppercase USER1 versus lowercase user1). In many cases, you can see the following in the messages file on the client:

May 19 13:14:29 centos7 nfsidmap[17481]: nss_getpwnam: name 'root@defaultv4iddomain.com' does not map into domain 'CVSDEMO.LOCAL'
May 19 13:15:05 centos7 nfsidmap[17534]: nss_getpwnam: name 'nobody' does not map into domain 'CVSDEMO.LOCAL'

The client and server must both agree that a user is indeed who they are claiming to be, so you must check the following to ensure that the user that the client sees has the same information as the user that Google Cloud NetApp Volumes sees.

  • NFSv4.x ID domain. Client: idmapd.conf file; Google Cloud NetApp Volumes uses defaultv4iddomain.com and cannot be changed manually. If using LDAP with NFSv4.1, Google Cloud NetApp Volumes changes the ID domain to what the DNS search domain is using, which is the same as the AD domain.

  • User name and numeric IDs. This determines where the client is looking for user names and leverages the name service switch configuration—client: nsswitch.conf and/or local passwd and group files; Google Cloud NetApp Volumes does not allow modifications to this but automatically adds LDAP to the configuration when it is enabled.

  • Group name and numeric IDs. This determines where the client is looking for group names and leverages the name service switch configuration—client: nsswitch.conf and/or local passwd and group files; Google Cloud NetApp Volumes does not allow modifications to this but automatically adds LDAP to the configuration when it is enabled.

In almost all cases, if you see nobody in user and group listings from clients, the issue is user or group name domain ID translation between Google Cloud NetApp Volumes and the NFS client. To avoid this scenario, use LDAP to resolve user and group information between clients and Google Cloud NetApp Volumes.

Viewing name ID strings for NFSv4.1 on clients

If you are using NFSv4.1, there is a name-string mapping that takes place during NFS operations, as previously described.

In addition to using /var/log/messages to find an issue with NFSv4 IDs, you can use the nfsidmap -l command on the NFS client to view which usernames have properly mapped to the NFSv4 domain.

For example, this is output of the command after a user that can be found by the client and Google Cloud NetApp Volumes accesses an NFSv4.x mount:

# nfsidmap -l
4 .id_resolver keys found:
  gid:daemon@CVSDEMO.LOCAL
  uid:nfs4@CVSDEMO.LOCAL
  gid:root@CVSDEMO.LOCAL
  uid:root@CVSDEMO.LOCAL

When a user that does not map properly into the NFSv4.1 ID domain (in this case, netapp-user) tries to access the same mount and touches a file, they are assigned nobody:nobody, as expected.

# su netapp-user
sh-4.2$ id
uid=482600012(netapp-user), 2000(secondary)
sh-4.2$ cd /mnt/nfs4/
sh-4.2$ touch newfile
sh-4.2$ ls -la
total 16
drwxrwxrwx  5 root   root   4096 Jan 14 17:13 .
drwxr-xr-x. 8 root   root     81 Jan 14 10:02 ..
-rw-r--r--  1 nobody nobody    0 Jan 14 17:13 newfile
drwxrwxrwx  2 root   root   4096 Jan 13 13:20 qtree1
drwxrwxrwx  2 root   root   4096 Jan 13 13:13 qtree2
drwxr-xr-x  2 nfs4   daemon 4096 Jan 11 14:30 testdir

The nfsidmap -l output shows the user pcuser in the display but not netapp-user; this is the anonymous user in our export-policy rule (65534).

# nfsidmap -l
6 .id_resolver keys found:
  gid:pcuser@CVSDEMO.LOCAL
  uid:pcuser@CVSDEMO.LOCAL
  gid:daemon@CVSDEMO.LOCAL
  uid:nfs4@CVSDEMO.LOCAL
  gid:root@CVSDEMO.LOCAL
  uid:root@CVSDEMO.LOCAL