JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Managing Network File Systems in Oracle Solaris 11.1     Oracle Solaris 11.1 Information Library
search filter icon
search icon

Document Information

Preface

1.  Managing Network File Systems (Overview)

2.  Network File System Administration (Tasks)

3.  Accessing Network File Systems (Reference)

NFS Files

/etc/default/nfslogd File

/etc/nfs/nfslog.conf File

NFS Daemons

automountd Daemon

lockd Daemon

mountd Daemon

nfs4cbd Daemon

nfsd Daemon

nfslogd Daemon

nfsmapid Daemon

Configuration Files and nfsmapid

Precedence Rules

nfsmapid and DNS TXT Records

Checking for the NFS Version 4 Domain

Configuring the NFS Version 4 Default Domain

Configuring an NFS Version 4 Default Domain in the Oracle Solaris 11 Release

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

Additional Information About nfsmapid

reparsed Daemon

statd Daemon

NFS Commands

automount Command

clear_locks Command

fsstat Command

mount Command

mount Options for NFS File Systems

Using the mount Command

umount Command

mountall Command

umountall Command

sharectl Command

set Subcommand

get Subcommand

status Subcommand

share Command

Non-File-System-Specific share Options

NFS-Specific share Options

Setting Access Lists With the share Command

unshare Command

shareall Command

unshareall Command

showmount Command

nfsref Command

FedFS Commands

Commands for Troubleshooting NFS Problems

nfsstat Command

pstack Command

rpcinfo Command

snoop Command

truss Command

NFS Over RDMA

How the NFS Service Works

Version Negotiation in NFS

Features in NFS Version 4

Unsharing and Resharing a File System in NFS Version 4

File-System Namespace in NFS Version 4

Volatile File Handles in NFS Version 4

Client Recovery in NFS Version 4

OPEN Share Support in NFS Version 4

Delegation in NFS Version 4

ACLs and nfsmapid in NFS Version 4

Reasons for ID Mapping to Fail

Avoiding ID Mapping Problems With ACLs

Checking for Unmapped User or Group IDs

Additional Information About ACLs or nfsmapid

UDP and TCP Negotiation

File Transfer Size Negotiation

How File Systems Are Mounted

Effects of the -public Option and NFS URLs When Mounting

Client-Side Failover

Failover Terminology

What Is a Replicated File System?

Failover and NFS Locking

Client-Side Failover in NFS Version 4

How NFS Server Logging Works

How the WebNFS Service Works

How WebNFS Security Negotiation Works

WebNFS Limitations With Web Browser Use

Secure NFS System

Secure RPC

DH Authentication

KERB Authentication

Using Secure RPC With NFS

How Mirror Mounts Work

When to Use Mirror Mounts

Mounting a File System Using Mirror Mounts

Unmounting a File System Using Mirror Mounts

How NFS Referrals Work

When to Use NFS Referrals?

Creating an NFS Referral

Removing an NFS Referral

Autofs Maps

Master Autofs Map

Mount Point /home

Mount Point /net

Mount Point /nfs4

Direct Autofs Maps

Mount Point /-

Indirect Autofs Maps

How Autofs Works

How Autofs Navigates Through the Network (Maps)

How Autofs Starts the Navigation Process (Master Map)

Autofs Mount Process

Simple Autofs Mount

Hierarchical Mounting

Autofs Unmounting

How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations)

Autofs and Weighting

Variables in a Autofs Map Entry

Maps That Refer to Other Maps

Executable Autofs Maps

Modifying How Autofs Navigates the Network (Modifying Maps)

Default Autofs Behavior With Name Services

Autofs Reference

Autofs and Metacharacters

Ampersand (&)

Asterisk (*)

Autofs and Special Characters

Index

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 at least one NFS share. To display the current list of NFS shares, run the share -F nfs command. 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, 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:

The default value for the automount map is /etc/auto_master. Use the -T option for troubleshooting.

The same specifications you would make on the command line can be made using the sharectl command. However, unlike the command line options, the SMF repository preserves your specifications, through service restarts, system reboots, as well as system upgrades. These are the parameters that can be set for the automountd daemon.

automountd_verbose

Logs status messages to the console and is the equivalent of the -v argument for the automountd daemon. The default value is FALSE.

nobrowse

Turns browsing on or off for all autofs mount points and is the equivalent of the -n argument for automountd. The default value is FALSE.

trace

Expands each remote procedure call (RPC) and displays the expanded RPC on standard output. This keyword is the equivalent of the -T argument for automountd. The default value is 0. Values can range from 0 to 5.

environment

Permits you to assign different values to different environments. This keyword is the equivalent of the -D argument for automountd. The environment parameter can be used multiple times. However, you must use separate entries for each environment assignment.

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 setting parameters using the sharectl command. The following are descriptions of parameters that can be set.


Note - The LOCKD_GRACE_PERIOD keyword and the -g option have been deprecated. The deprecated keyword is replaced with the new grace_period parameter. 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, the grace_period=graceperiodparameter 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 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 5 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=number parameter specifies the maximum number of concurrent lockd requests. The default value is 1024.

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.

In addition to the command line options, several SMF parameters can be used to configure the mountd daemon.

client_versmin

Sets the minimum version of the NFS protocol to be used by the NFS client. The default is 2. Other valid values include 3 or 4. Refer to Setting Up NFS Services.

client_versmax

Sets the maximum version of the NFS protocol to be used by the NFS client. The default is 4. Other valid values include 2 or 3. Refer to Setting Up NFS Services.

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 setting the appropriate SMF parameter with the sharectl command.

The listen_backlog=length parameter 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 max_connections=#-conn parameter 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 servers=nservers parameter selects the maximum number of concurrent requests that a server can handle. The default value for nservers is 1024. 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.

In addition, these SMF parameters can be used to configure the mountd daemon. These parameters do not have command line equivalents:

server_versmin

Sets the minimum version of the NFS protocol to be registered and offered by the server. The default is 2. Other valid values include 3 or 4. Refer to Setting Up NFS Services.

server_versmax

Sets the maximum version of the NFS protocol to be registered and offered by the server. The default is 4. Other valid values include 2 or 3. Refer to Setting Up NFS Services.

server_delegation

Controls whether the NFS version 4 delegation feature is enabled for the server. If this feature is enabled, the server attempts to provide delegations to the NFS version 4 client. By default, server delegation is enabled. To disable server delegation, see How to Select Different Versions of NFS on a Server. For more information, refer to Delegation in NFS Version 4.

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 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:

You can change the domain name for the clients and servers using the sharectl command with the following option.

nfsmapid_domain

Sets a common domain for clients and servers. Overrides the default behavior of using the local DNS domain name. For task information, refer to Setting Up NFS Services.

Configuration Files and nfsmapid

The following describes how the nfsmapid daemon uses the SMF configuration information found in svc:system/name-service/switch and in svc:/network/dns/client:

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 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 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 the parameter in the SMF repository.

  3. 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, where both the domain and search directives are used, the nfsmapid daemon uses the first domain listed after the search directive, which is company.com.

    domain example.company.com
    search company.com foo.bar.com
  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 Oracle Solaris 11 Release

In the Oracle Solaris 11 Release, the default NFS domain version can be set using from the command line by typing the following command:

# sharectl set -p nfsmapid_domain=example.com nfs 

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.


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 OS 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 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 the SMF repository, the [domain_name] that you provide overrides that value.


Additional Information About nfsmapid

For more information about nfsmapid, see the following:

reparsed Daemon

The reparsed daemon interprets the data associated with a reparse point, which are used by DFS and NFS referrals on SMB and NFS file servers. This service is managed by SMF and should not be manually started.

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.