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 known_user@example.com and then send this attribute to the NFS Version 4 server. After the server receives known_user@example.com 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.
The nfsmapid daemon uses the SMF configuration information found in svc:system/name-service/switch and in svc:/network/dns/client as follows:
nfsmapid uses standard C library functions to request password and group information from back-end name services. These name services are controlled by the settings in the svc:system/name-service/switch SMF service. Any changes to the service properties affect nfsmapid operations. For more information about the svc:system/name-service/switch SMF service, see the nsswitch.conf (4) man page.
To ensure that NFS Version 4 clients are capable of mounting file systems from different domains, nfsmapid relies on the configuration of the DNS TXT resource record (RR), _nfsv4idmapdomain. For more information about configuring the _nfsv4idmapdomain resource record, see nfsmapid and DNS TXT Records. Also, note the following:
The DNS TXT RR should be explicitly configured on the DNS server with the desired domain information.
The svc:system/name-service/switch SMF service should be configured to enable the resolver to find the DNS server and search the TXT records for client and server NFS Version 4 domains.
For more information, see the following:
The resolv.conf (4) man page
For nfsmapid to work properly, NFS Version 4 clients and servers must have the same domain. To ensure matching NFS Version 4 domains, nfsmapid follows these strict precedence rules:
The daemon first checks the SMF repository for a value that has been assigned to the nfsmapid_domain parameter. If a value is found, the assigned value takes precedence over any other settings. The assigned value is appended to the outbound attribute strings and is compared against inbound attribute strings. For procedural information, see Setting Up the NFS Service.
If no value has been assigned to nfsmapid_domain, then the daemon checks for a domain name from a DNS TXT RR. nfsmapid relies on directives in the /etc/resolv.conf file that are used by the set of routines in the resolver. The resolver searches through the configured DNS servers for the _nfsv4idmapdomain TXT RR. Note that the use of DNS TXT records is more scalable. For this reason, continued use of TXT records is much preferred over setting the parameter in the SMF repository.
If no DNS TXT record is configured to provide a domain name, then the nfsmapid daemon uses the value specified by the domain or search directive in the /etc/resolv.conf file, with the directive specified last taking precedence.
In the following example, both the domain and search directives are used. The nfsmapid daemon uses the first domain listed after the search directive, which is example.com.
domain company.example.com search example.com abc.def.com
If the /etc/resolv.conf file does not exist, nfsmapid obtains the NFS Version 4 domain name by following the behavior of the domainname command. Specifically, if the /etc/defaultdomain file exists, nfsmapid uses the contents of that file for the NFS Version 4 domain. If the /etc/defaultdomain file does not exist, nfsmapid uses the domain name that is provided by the network's configured naming service. For more information, see the domainname (1M) man page.
The ubiquitous nature of DNS provides an efficient storage and distribution mechanism for the NFS Version 4 domain name. Additionally, because of the inherent scalability of DNS, the use of DNS TXT resource records is the preferred method for configuring the NFS Version 4 domain name for large deployments. You should configure the _nfsv4idmapdomain TXT record on enterprise-level DNS servers. Such configurations ensure that any NFS Version 4 client or server can find its NFS Version 4 domain by traversing the DNS tree.
The following example shows a preferred entry for enabling the DNS server to provide the NFS Version 4 domain name:
_nfsv4idmapdomain IN TXT "abc.def"
In this example, the domain name to configure is the value that is enclosed in double quotes. Note that no ttl field is specified and that no domain is appended to _nfsv4idmapdomain, which is the value in the owner field. This configuration enables the TXT record to use the zone's ${ORIGIN} entry from the Start-Of-Authority (SOA) record. For example, at different levels of the domain namespace, the record could read as follows:
_nfsv4idmapdomain.subnet.example.com. IN TXT "abc.def" _nfsv4idmapdomain.example.com. IN TXT "abc.def"
This configuration provides DNS clients with the added flexibility of using the resolv.conf file to search up the DNS tree hierarchy. See the resolv.conf (4) man page. This capability provides a higher probability of finding the TXT record. For even more flexibility, lower level DNS subdomains can define their own DNS TXT resource records (RRs). This capability enables lower level DNS subdomains to override the TXT record that is defined by the top level DNS domain.
Before assigning a value for your network's NFS Version 4 domain, check whether an NFS Version 4 domain has already been configured for your network. The following examples provide ways of identifying your network's NFS Version 4 domain.
To identify the NFS Version 4 domain from a DNS TXT RR, use either the nslookup or the dig command:
The following example shows sample output for the nslookup command:
# nslookup -q=txt _nfsv4idmapdomain Server: 10.255.255.255 Address: 10.255.255.255#53 _nfsv4idmapdomain.company.example.com text = "example.com"
The following example shows sample output for the dig command:
# dig +domain=company.example.com -t TXT _nfsv4idmapdomain ... ;; QUESTION SECTION: ;_nfsv4idmapdomain.company.example.com. IN TXT ;; ANSWER SECTION: _nfsv4idmapdomain.company.example.com. 21600 IN TXT "example.com" ;; AUTHORITY SECTION: ...
For information about setting up a DNS TXT RR, see nfsmapid and DNS TXT Records.
If your network is not set up with a NFS Version 4 DNS TXT RR, use the following command to identify your NFS Version 4 domain from the DNS domain name:
# egrep domain /etc/resolv.conf domain company.example.com
If the /etc/resolv.conf file is not configured to provide a DNS domain name for the client, use the following command to identify the domain from the network's NFS Version 4 domain configuration:
# cat /system/volatile/nfs4_domain example.com
If you are using a different naming service, such as NIS, use the following command to identify the domain for the naming service configured for your network:
# domainname it.company.example.com
For more information, see the following man pages:
This section describes how the network obtains the desired default domain:
For most current releases, see Configuring an NFS Version 4 Default Domain in the Oracle Solaris 11 Release.
For the initial Solaris 10 release, see Configuring an NFS Version 4 Default Domain in the Solaris 10 Release.
In the Oracle Solaris 11 release, set the default NFS domain version by typing the following command:
# sharectl set -p nfsmapid_domain=example.com nfs
In the initial Solaris 10 release of NFS Version 4, if your network included multiple DNS domains but only had a single UID and GID namespace, all clients had to use one value for nfsmapid_domain. For sites that use DNS, nfsmapid resolves this issue by obtaining the domain name from the value that you assigned to _nfsv4idmapdomain. For more information, see nfsmapid and DNS TXT Records. If your network is not configured to use DNS, during the first system boot, the operating system uses the sysidconfig utility to provide the following prompts for an NFS Version 4 domain name:
This system is configured with NFS Version 4, which uses a domain name that is automatically derived from the system's name services. The derived domain name is sufficient for most configurations. In a few cases, mounts that cross different domains might cause files to be owned by nobody due to the lack of a common domain name. Do you need to override the system's default NFS version 4 domain name (yes/no)? [no]
The default response is [no]. If you choose [no], you see the following message:
For more information about how the NFS Version 4 default domain name is derived and its impact, refer to the man pages for nfsmapid(1M) and nfs(4), and the System Administration Guide: Network Services.
If you choose [yes], you see this prompt:
Enter the domain to be used as the NFS Version 4 domain name. NFS Version 4 domain name []:
For more information about nfsmapid, see the following:
nfsmapid (1M) man page
nfs (4) man page
http://www.ietf.org/rfc/rfc1464.txthttp://www.ietf.org/rfc/rfc1464.txt