> To provide a greater degree of compatibility with NFSv3, which identified users and groups by 32-bit unsigned user identifiers and group identifiers, owner and group strings that consist of ASCII- encoded decimal numeric values with no leading zeros can be given a special interpretation by clients and servers that choose to provide such support. The receiver may treat such a user or group string as representing the same user as would be represented by an NFSv3 uid or gid having the corresponding numeric value.
I'm not sure how common this extension is, at least the Linux server and client support it out of the box. Isilon also supports it, but it must be explicitly enabled.
It is very common. I’m not aware of a v4 server that does not support this.
Originally v4 went all in on Kerberos (GSSAPI technically) to provide strong multi user auth. This is the reason that users and groups are represented as strings.
This approach works reasonably well on Windows with SMB since you have AD there giving you Kerberos and a shared (LDAP) directory. AD is also deeply integrated in the OS for things like credential management and provisioning.
The approach did not work so well on Linux where not everyone is running AD or even some kind of directory. This caused the protocol designers to make Kerberos optional in v4.1. I guess the spec authors already knew that Kerberos was going to be difficult because I just checked and the numerical-strong-user-as-posix-id workaround was already present in the original 4.0 spec.
Everything gets squashed in NFSv4 until idmapd is configured on both the client and the server, and they are set to the same "domain" (by default everything in the FQDN except for the simple host name).
Assuming this is up, everything will be unsquashed, and it will behave like NFSv3.