Just wanted to add my findings to this as I was also curious to get user/group mapping to work without the need of a Kerberos server.
However, what I saw especially in comments and documentation from upstream is that this was never designed to work that way. Instead, the idmapper only works in the way I expected (sending username@realm instead of UID) when GSS auth is being configured on the NFS server side which (currently) requires that you have a Kerberos server that manages the authentication tickets for both, the server and the client and serves as the trusting third party, so conceptually a little bit similar to the extra authentication services we usually see around the net.
If that is not available to you I am afraid you are stuck with the old auth_sys, which means sticking to same UIDs/GIDs on server and clients.
In the end I have to say that this is quite inflexibly designed and by design excludes home setups where a separate authentication party is not desirable, without any secure alternative.
Just wanted to add my findings to this as I was also curious to get user/group mapping to work without the need of a Kerberos server.
However, what I saw especially in comments and documentation from upstream is that this was never designed to work that way. Instead, the idmapper only works in the way I expected (sending username@realm instead of UID) when GSS auth is being configured on the NFS server side which (currently) requires that you have a Kerberos server that manages the authentication tickets for both, the server and the client and serves as the trusting third party, so conceptually a little bit similar to the extra authentication services we usually see around the net.
If that is not available to you I am afraid you are stuck with the old auth_sys, which means sticking to same UIDs/GIDs on server and clients.
In the end I have to say that this is quite inflexibly designed and by design excludes home setups where a separate authentication party is not desirable, without any secure alternative.