nfsmapid Daemon

Version 4 of the NFS protocol (RFC3530) changed the way user or group identifiers (UID or GID) are exchanged between the client and server. The protocol requires that a file's owner and group attributes be exchanged between an NFS Version 4 client and an NFS Version 4 server as strings in the form at user@nfsv4-domain or group@nfsv4-domain , respectively.

For example, user known_user has a UID 123456 on an NFS Version 4 client whose fully qualified hostname is system.example.com. For the client to make requests to the NFS Version 4 server, the client must map the UID 123456 to [e-mail] and then send this attribute to the NFS Version 4 server. After the server receives [e-mail] from the client, the server maps the string to the local UID 123456, which is understood by the underlying file system. This functionality assumes that every UID and GID in the network is unique and that the NFS Version 4 domains on the client match the NFS Version 4 domains on the server.

The NFS Version 4 client and server are both capable of performing integer-to-string and string-to-integer conversions. For example, in response to a GETATTR operation, the NFS Version 4 server maps UIDs and GIDs obtained from the underlying file system into their respective string representation and sends this information to the client. Alternately, the client must also map UIDs and GIDs into string representations. For example, in response to the chown command, the client maps the new UID or GID to a string representation before sending a SETATTR operation to the server.

Note, however, that the client and server respond differently to unrecognized strings:

• If the user does not exist on the server, even within the same NFS Version 4 domain configuration, the server rejects the remote procedure call (RPC) and returns an error message to the client. This situation limits the operations that can be performed by the remote user.

• If the user exists on both the client and server but they have mismatched domains, the server rejects the attribute modifying operations (such as SETATTR) that require the server to map the inbound user string to an integer value that the underlying file system can understand. For NFS Version 4 clients and servers to function properly, their NFS Version 4 domains, the portion of the string after the @ sign, should match.

• If the NFS Version 4 client does not recognize a user or group name from the server, the client is unable to map the string to its unique ID, an integer value. Under such circumstances, the client maps the inbound user or group string to the nobody user. This mapping to nobody creates varied problems for different applications. With NFS Version 4, operations that modify file attributes will fail.

• If the server does not recognize the given user or group name, even if the NFS Version 4 domains match, the server is unable to map the user or group name to its unique ID, an integer value. Under such circumstances, the server maps the inbound user or group name to the nobody user. To prevent such occurrences, administrators should avoid making special accounts that exist only on the NFS Version 4 client.

You can change the domain name for the clients and servers using the sharectl command with the nfsmapid_domain option. This option sets a common domain for clients and servers. It overrides the default behavior of using the local DNS domain name. For task information, refer to Setting Up the NFS Service.