test

System Administration Guide: Network Services

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 of 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. The NFS version 4 server expects to receive user and group file attributes in the user_or_group@nfsv4_domain format. 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.

Note –

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 only exist on the NFS version 4 client.

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:

Configuration Files and nfsmapid

The following describes how the nfsmapid daemon uses the /etc/nsswitch.conf and /etc/resolv.conf files:

Precedence Rules

    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:

  1. The daemon first checks the /etc/default/nfs file for a value that has been assigned to the NFSMAPID_DOMAIN keyword. 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 more information about keywords in the /etc/default/nfs file, see Keywords for the /etc/default/nfs File. For procedural information, see Setting Up NFS Services.

    Note –

    The use of the NFSMAPID_DOMAIN setting is not scalable and is not recommended for large deployments.

  2. 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 keyword in the /etc/default/nfs file.

  3. If no DNS TXT record provides a domain name, then by default the nfsmapid daemon uses the configured DNS domain.

  4. 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.

nfsmapid and DNS TXT Records

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 is an example of a preferred entry for enabling the DNS server to provide the NFS version 4 domain name:


_nfsv4idmapdomain		IN		TXT			"foo.bar"

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.yourcorp.com.    IN    TXT    "foo.bar"
_nfsv4idmapdomain.yourcorp.com.           IN    TXT    "foo.bar"

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 sub-domains can define their own DNS TXT resource records (RRs). This capability enables lower level DNS sub-domains to override the TXT record that is defined by the top level DNS domain.

Note –

The domain that is specified by the TXT record can be an arbitrary string that does not necessarily match the DNS domain for clients and servers that use NFS version 4. You have the option of not sharing NFS version 4 data with other DNS domains.

Checking for the NFS Version 4 Domain

Before assigning a value for your network's NFS version 4 domain, check to see if 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.

For more information, see the following man pages:

Configuring the NFS Version 4 Default Domain

This section describes how the network obtains the desired default domain:

Configuring an NFS Version 4 Default Domain in the Solaris Express 5/06 Release

In the initial Solaris 10 release, the domain was defined during the first system reboot after installing the OS. In the Solaris Express 5/06 release, the NFS version 4 domain is defined during the installation of the OS. To provide this functionality, the following features have been added:

    The following describes how the functionality operates:

  1. The sysidnfs4 program checks the /etc/.sysIDtool.state file to determine whether an NFS version 4 domain has been identified.

    • If the .sysIDtool.state file shows that an NFS version 4 domain has been configured for the network, the sysidnfs4 program makes no further checks. See the following example of a .sysIDtool.state file:


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
1       # NFSv4 domain configured
xterms

      The 1 that appears before # NFSv4 domain configured confirms that the NFS version 4 domain has been configured.

    • If the .sysIDtool.state file shows that no NFS version 4 domain has been configured for the network, the sysidnfs4 program must make further checks. See the following example of a .sysIDtool.state file:


      1       # System previously configured?
1       # Bootparams succeeded?
1       # System is on a network?
1       # Extended network information gathered?
1       # Autobinder succeeded?
1       # Network has subnets?
1       # root password prompted for?
1       # locale and term prompted for?
1       # security policy in place
0       # NFSv4 domain configured
xterms

      The 0 that appears before # NFSv4 domain configured confirms that no NFS version 4 domain has been configured.

  2. If no NFS version 4 domain has been identified, the sysidnfs4 program checks the nfs4_domain keyword in the sysidcfg file.

    • If a value for nfs4_domain exists, that value is assigned to the NFSMAPID_DOMAIN keyword in the /etc/default/nfs file. Note that any value assigned to NFSMAPID_DOMAIN overrides the dynamic domain selection capability of the nfsmapid daemon. For more information about the dynamic domain selection capability of nfsmapid, see Precedence Rules.

    • If no value for nfs4_domain exists, the sysidnfs4 program identifies the domain that nfsmapid derives from the operating system's configured name services. This derived value is presented as a default domain at an interactive prompt that gives you the option of accepting the default value or assigning a different NFS version 4 domain.

This functionality makes the following obsolete:

Note –

Because of the inherent ubiquitous and scalable nature of DNS, the use of DNS TXT records for configuring the domain of large NFS version 4 deployments continues to be preferred and strongly encouraged. See nfsmapid and DNS TXT Records.

For specific information about the Solaris installation process, see the following:

Configuring an NFS Version 4 Default Domain in the Solaris 10 Release

In the initial Solaris 10 release of NFS version 4, if your network includes multiple DNS domains, but only has a single UID and GID namespace, all clients must 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 Solaris OS uses the sysidconfig(1M) 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 verion 4 domain 
name (yes/no)? [no]

The default response is [no]. If you choose [no], you see the following:


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 []:
Note –

If a value for NFSMAPID_DOMAIN exists in /etc/default/nfs, the [domain_name] that you provide overrides that value.

Additional Information About nfsmapid

For more information about nfsmapid, see the following: