NFS Daemons
To support NFS activities, several daemons are started when a system goes into
run level 3 or multiuser mode. The mountd and nfsd daemons are
run on systems that are servers. The automatic startup of the server daemons
depends on the existence of entries that are labeled with the NFS file-system
type in /etc/dfs/sharetab. To support NFS file locking, the lockd and statd daemons are
run on NFS clients and servers. However, unlike previous versions of NFS, in
NFS version 4, the daemons lockd, statd, mountd, and nfslogd are not
used.
This section describes the following daemons.
automountd Daemon
This daemon handles the mounting and unmounting requests from the autofs service. The
syntax of the command is as follows:
automountd [ -Tnv ] [ -D name=value ]
The command behaves in the following ways:
-T enables tracing.
-n disables browsing on all autofs nodes.
-v selects to log all status messages to the console.
-D name=value substitutes value for the automount map variable that is indicated by name.
The default value for the automount map is /etc/auto_master. Use the -T option
for troubleshooting.
lockd Daemon
This daemon supports record-locking operations on NFS files. The lockd daemon manages
RPC connections between the client and the server for the Network Lock Manager
(NLM) protocol. The daemon is normally started without any options. You can use
three options with this command. See the lockd(1M) man page. These options
can either be used from the command line or by editing the appropriate
string in /etc/default/nfs. The following are descriptions of keywords that can be set in
the /etc/default/nfs file.
Note - Starting in the Solaris 10 release, the LOCKD_GRACE_PERIOD keyword and the -g option
have been deprecated. The deprecated keyword is replaced with the new keyword GRACE_PERIOD.
If both keywords are set, the value for GRACE_PERIOD overrides the value for
LOCKD_GRACE_PERIOD. See the description of GRACE_PERIOD that follows.
Like LOCKD_GRACE_PERIOD, GRACE_PERIOD=graceperiod in /etc/default/nfs sets the number of seconds after a server
reboot that the clients have to reclaim both NFS version 3 locks, provided
by NLM, and version 4 locks. Thus, the value for GRACE_PERIOD controls
the length of the grace period for lock recovery, for both NFS version
3 and NFS version 4.
The LOCKD_RETRANSMIT_TIMEOUT=timeout parameter in /etc/default/nfs selects the number of seconds to wait before retransmitting
a lock request to the remote server. This option affects the NFS client-side
service. The default value for timeout is 15 seconds. Decreasing the timeout value
can improve response time for NFS clients on a “noisy” network. However, this change
can cause additional server load by increasing the frequency of lock requests. The
same parameter can be used from the command line by starting the daemon
with the -t timeout option.
The LOCKD_SERVERS=nthreads parameter in /etc/default/nfs specifies the maximum number of concurrent threads that the
server handles per connection. Base the value for nthreads on the load
that is expected on the NFS server. The default value is 20. Each
NFS client that uses TCP uses a single connection with the NFS server.
Therefore, each client can use a maximum of 20 concurrent threads on the
server.
All NFS clients that use UDP share a single connection with the
NFS server. Under these conditions, you might have to increase the number of
threads that are available for the UDP connection. A minimum calculation would be to
allow two threads for each UDP client. However, this number is specific to
the workload on the client, so two threads per client might not
be sufficient. The disadvantage to using more threads is that when the threads
are used, more memory is used on the NFS server. If the threads
are never used, however, increasing nthreads has no effect. The same parameter can be
used from the command line by starting the daemon with the nthreads
option.
mountd Daemon
This daemon handles file-system mount requests from remote systems and provides access control.
The mountd daemon checks /etc/dfs/sharetab to determine which file systems are available
for remote mounting and which systems are allowed to do the remote mounting.
You can use the -v option and the -r option with this
command. See the mountd(1M) man page.
The -v option runs the command in verbose mode. Every time an NFS
server determines the access that a client should be granted, a message is
printed on the console. The information that is generated can be useful when
trying to determine why a client cannot access a file system.
The -r option rejects all future mount requests from clients. This option does
not affect clients that already have a file system mounted.
Note - NFS version 4 does not use this daemon.
nfs4cbd Daemon
nfs4cbd, which is for the exclusive use of the NFS version 4 client,
manages the communication endpoints for the NFS version 4 callback program. The daemon
has no user-accessible interface. For more information, see the nfs4cbd(1M) man page.
nfsd Daemon
This daemon handles other client file-system requests. You can use several options with
this command. See the nfsd(1M) man page for a complete listing. These options
can either be used from the command line or by editing the
appropriate string in /etc/default/nfs.
The NFSD_LISTEN_BACKLOG=length parameter in /etc/default/nfs sets the length of the connection queue over connection-oriented
transports for NFS and TCP. The default value is 32 entries. The same
selection can be made from the command line by starting nfsd with
the -l option.
The NFSD_MAX_CONNECTIONS=#-conn parameter in /etc/default/nfs selects the maximum number of connections per connection-oriented transport.
The default value for #-conn is unlimited. The same parameter can be used
from the command line by starting the daemon with the -c #-conn option.
The NFSD_SERVER=nservers parameter in /etc/default/nfs selects the maximum number of concurrent requests that a
server can handle. The default value for nservers is 16. The same selection
can be made from the command line by starting nfsd with the
nservers option.
Unlike older versions of this daemon, nfsd does not spawn multiple copies to
handle concurrent requests. Checking the process table with ps only shows one copy
of the daemon running.
nfslogd Daemon
This daemon provides operational logging. NFS operations that are logged against a server
are based on the configuration options that are defined in /etc/default/nfslogd. When
NFS server logging is enabled, records of all RPC operations on a selected
file system are written to a buffer file by the kernel. Then nfslogd
postprocesses these requests. The name service switch is used to help map UIDs
to logins and IP addresses to host names. The number is recorded if
no match can be found through the identified name services.
Mapping of file handles to path names is also handled by nfslogd. The
daemon tracks these mappings in a file-handle-to-path mapping table. One mapping table exists
for each tag that is identified in /etc/nfs/nfslogd. After post-processing, the records
are written to ASCII log files.
Note - NFS version 4 does not use this daemon.
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 [email protected] 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 [email protected] 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:
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. As for NFS version 4 functionality, operations that modify file attributes will fail.
Configuration Files and nfsmapid
The following describes how the nfsmapid daemon uses the /etc/nsswitch.conf and /etc/resolv.conf files:
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 /etc/nsswitch.conf file. Any changes to the nsswitch.conf file affect nfsmapid operations. For more information about the nsswitch.conf file, see the nsswitch.conf(4) man page.
To ensure that the 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 /etc/resolv.conf file should be configured with the desired parameters 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:
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:
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.
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.
If no DNS TXT record provides a domain name, then by default the nfsmapid daemon uses the configured DNS domain.
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.
To identify the NFS version 4 domain from a DNS TXT RR, use either the nslookup or the dig command:
The following provides sample output for the nslookup command:
# nslookup -q=txt _nfsv4idmapdomain
Server: 10.255.255.255
Address: 10.255.255.255#53
_nfsv4idmapdomain.example.company.com text = "company.com"
See this sample output for the dig command:
# dig +domain=example.company.com -t TXT _nfsv4idmapdomain
...
;; QUESTION SECTION:
;_nfsv4idmapdomain.example.company.com. IN TXT
;; ANSWER SECTION:
_nfsv4idmapdomain.example.company.com. 21600 IN TXT "company.com"
;; AUTHORITY SECTION:
...
For information about setting up a DNS TXT RR, see nfsmapid and DNS TXT Records.
If your network is not setup 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 example.company.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 /var/run/nfs4_domain
company.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.example.company.com
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 sysidtool command includes the sysidnfs4 program. This program runs during the installation process to determine whether an NFS version 4 domain has been configured for the network. See the man pages for sysidtool(1M) and sysidnfs4(1M).
The sysidcfg file has a new keyword, nfs4_domain. This keyword can be used to define the NFS version 4 domain. Note that other keywords can also be defined in the sysidcfg file. See the sysidcfg(4) man page.
The following describes how the functionality operates:
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.
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:
The sample JumpStartTM script, set_nfs4_domain, which was provided in the initial Solaris 10 media distribution is no longer required and is discouraged.
The /etc/.NFS4inst_state.domain file, which was created by the previous implementation of the sysidnfs4 program, is no longer required.
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:
statd Daemon
This daemon works with lockd to provide crash and recovery functions for the
lock manager. The statd daemon tracks the clients that hold locks on an
NFS server. If a server crashes, on rebooting statd on the server contacts
statd on the client. The client statd can then attempt to reclaim any locks
on the server. The client statd also informs the server statd when a
client has crashed so that the client's locks on the server can be
cleared. You have no options to select with this daemon. For more information,
see the statd(1M) man page.
In the Solaris 7 release, the way that statd tracks the clients has
been improved. In all earlier Solaris releases, statd created files in /var/statmon/sm for
each client by using the client's unqualified host name. This file naming caused
problems if you had two clients in different domains that shared a host
name, or if clients were not resident in the same domain as the
NFS server. Because the unqualified host name only lists the host name, without
any domain or IP-address information, the older version of statd had no way
to differentiate between these types of clients. To fix this problem, the Solaris
7 statd creates a symbolic link in /var/statmon/sm to the unqualified host name by
using the IP address of the client. The new link resembles the
following:
# ls -l /var/statmon/sm
lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv4.192.168.255.255 -> myhost
lrwxrwxrwx 1 daemon 11 Apr 29 16:32 ipv6.fec0::56:a00:20ff:feb9:2734 -> v6host
--w------- 1 daemon 11 Apr 29 16:32 myhost
--w------- 1 daemon 11 Apr 29 16:32 v6host
In this example, the client host name is myhost and the client's IP
address is 192.168.255.255. If another host with the name myhost were mounting a
file system, two symbolic links would lead to the host name.
Note - NFS version 4 does not use this daemon.
