This chapter describes the NFS commands, as well as the different parts of the NFS environment and how these parts work together.NFS Files NFS Daemons NFS Commands Commands for Troubleshooting NFS Problems NFS Over RDMA How the NFS Service Works Autofs Maps How Autofs Works Autofs Reference If your system has zones enabled and you want to use this feature in a non-global zone, see System Administration Guide: Solaris Containers-Resource Management and Solaris Zones for more information. You need several files to support NFS activities on any computer. Many of these files are ASCII, but some of the files are data files. Table 6–1 lists these files and their functions. File Name Function /etc/default/autofs Lists configuration information for the autofs environment. /etc/default/fs Lists the default file-system type for local file systems. /etc/default/nfs Lists configuration information for lockd and nfsd. For more information, refer to Keywords for the /etc/default/nfs File and the nfs4 man page. /etc/default/nfslogd Lists configuration information for the NFS server logging daemon, nfslogd. /etc/dfs/dfstab Lists the local resources to be shared. /etc/dfs/fstypes Lists the default file-system types for remote file systems. /etc/dfs/sharetab Lists the local and remote resources that are shared. See the sharetab4 man page. Do not edit this file. /etc/mnttab Lists file systems that are currently mounted, including automounted directories. See the mnttab4 man page. Do not edit this file. /etc/netconfig Lists the transport protocols. Do not edit this file. /etc/nfs/nfslog.conf Lists general configuration information for NFS server logging. /etc/nfs/nfslogtab Lists information for log postprocessing by nfslogd. Do not edit this file. /etc/nfssec.conf Lists NFS security services. /etc/rmtab Lists file systems that are remotely mounted by NFS clients. See the rmtab4 man page. Do not edit this file. /etc/vfstab Defines file systems to be mounted locally. See the vfstab4 man page. The first entry in /etc/dfs/fstypes is often used as the default file-system type for remote file systems. This entry defines the NFS file-system type as the default.Only one entry is in /etc/default/fs: the default file-system type for local disks. You can determine the file-system types that are supported on a client or server by checking the files in /kernel/fs. Starting in the Solaris 10 release, you can use the /etc/default/autofs file to configure your autofs environment. Specifically, this file provides an additional way to configure your autofs commands and autofs daemons. The same specifications you would make on the command line can be made in this configuration file. However, unlike the specifications you would make on the command line, this file preserves your specifications, even during upgrades to your operating system. Additionally, you are no longer required to update critical startup files to ensure that the existing behavior of your autofs environment is preserved. You can make your specifications by providing values for the following keywords:AUTOMOUNT_TIMEOUTSets the duration for a file system to remain idle before the file system is unmounted. This keyword is the equivalent of the t argument for the automount command. The default value is 600. AUTOMOUNT_VERBOSEProvides notification of autofs mounts, unmounts, and other nonessential events. This keyword is the equivalent of the v argument for automount. The default value is FALSE. AUTOMOUNTD_VERBOSELogs status messages to the console and is the equivalent of the v argument for the automountd daemon. The default value is FALSE. AUTOMOUNTD_NOBROWSETurns browsing on or off for all autofs mount points and is the equivalent of the n argument for automountd. The default value is FALSE. AUTOMOUNTD_TRACEExpands 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. AUTOMOUNTD_ENVPermits you to assign different values to different environments. This keyword is the equivalent of the D argument for automountd. The AUTOMOUNTD_ENV keyword can be used multiple times. However, you must use separate lines for each environment assignment. For more information, refer to the man pages for automount1M and automountd1M. For procedural information, refer to How to Use the /etc/default/autofs File. In NFS version 4, the following keywords can be set in the /etc/default/nfs file. These keywords control the NFS protocols that are used by both the client and server.NFS_SERVER_VERSMINSets the minimum version of the NFS protocol to be registered and offered by the server. Starting in the Solaris 10 release, the default is 2. Other valid values include 3 or 4. Refer to Setting Up NFS Services. NFS_SERVER_VERSMAXSets the maximum version of the NFS protocol to be registered and offered by the server. Starting in the Solaris 10 release, the default is 4. Other valid values include 2 or 3. Refer to Setting Up NFS Services. NFS_CLIENT_VERSMINSets the minimum version of the NFS protocol to be used by the NFS client. Starting in the Solaris 10 release, the default is 2. Other valid values include 3 or 4. Refer to Setting Up NFS Services. NFS_CLIENT_VERSMAXSets the maximum version of the NFS protocol to be used by the NFS client. Starting in the Solaris 10 release, the default is 4. Other valid values include 2 or 3. Refer to Setting Up NFS Services. NFS_SERVER_DELEGATIONControls 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. NFSMAPID_DOMAINSets 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. Also, see nfsmapid Daemon. This file defines some of the parameters that are used when using NFS server logging. The following parameters can be defined.CYCLE_FREQUENCYDetermines the number of hours that must pass before the log files are cycled. The default value is 24 hours. This option is used to prevent the log files from growing too large. IDLE_TIMESets the number of seconds nfslogd should sleep before checking for more information in the buffer file. This parameter also determines how often the configuration file is checked. This parameter, along with MIN_PROCESSING_SIZE, determines how often the buffer file is processed. The default value is 300 seconds. Increasing this number can improve performance by reducing the number of checks. MAPPING_UPDATE_INTERVALSpecifies the number of seconds between updates of the records in the file-handle-to-path mapping tables. The default value is 86400 seconds or one day. This parameter helps keep the file-handle-to-path mapping tables up-to-date without having to continually update the tables. MAX_LOGS_PRESERVEDetermines the number of log files to be saved. The default value is 10. MIN_PROCESSING_SIZESets the minimum number of bytes that the buffer file must reach before processing and writing to the log file. This parameter, along with IDLE_TIME, determines how often the buffer file is processed. The default value is 524288 bytes. Increasing this number can improve performance by reducing the number of times the buffer file is processed. PRUNE_TIMEOUTSelects the number of hours that must pass before a file-handle-to-path mapping record times out and can be reduced. The default value is 168 hours or 7 days. UMASKSpecifies the file mode creation mask for the log files that are created by nfslogd. The default value is 0137. This file defines the path, file names, and type of logging to be used by nfslogd. Each definition is associated with a tag. Starting NFS server logging requires that you identify the tag for each file system. The global tag defines the default values. You can use the following parameters with each tag as needed.defaultdir=pathSpecifies the default directory path for the logging files. Unless you specify differently, the default directory is /var/nfs. log=path/filenameSets the path and file name for the log files. The default is /var/nfs/nfslog. fhtable=path/filenameSelects the path and file name for the file-handle-to-path database files. The default is /var/nfs/fhtable. buffer=path/filenameDetermines the path and file name for the buffer files. The default is /var/nfs/nfslog_workbuffer. logformat=basic|extendedSelects the format to be used when creating user-readable log files. The basic format produces a log file that is similar to some ftpd daemons. The extended format gives a more detailed view. If the path is not specified, the path that is defined by defaultdir is used. Also, you can override defaultdir by using an absolute path.To identify the files more easily, place the files in separate directories. Here is an example of the changes that are needed.% cat /etc/nfs/nfslog.conf #ident "@(#)nfslog.conf 1.5 99/02/21 SMI" # . . # NFS server log configuration file. # global defaultdir=/var/nfs \ log=nfslog fhtable=fhtable buffer=nfslog_workbuffer publicftp log=logs/nfslog fhtable=fh/fhtables buffer=buffers/workbufferIn this example, any file system that is shared with log=publicftp uses the following values: The default directory is /var/nfs. Log files are stored in /var/nfs/logs/nfslog*. File-handle-to-path database tables are stored in /var/nfs/fh/fhtables. Buffer files are stored in /var/nfs/buffers/workbuffer. For procedural information, refer to How to Enable NFS Server Logging. 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 lockd Daemon mountd Daemon nfs4cbd Daemon nfsd Daemon nfslogd Daemon nfsmapid Daemon statd 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. 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 lockd1M 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.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. 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 mountd1M 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.NFS version 4 does not use this 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 nfs4cbd1M man page. This daemon handles other client file-system requests. You can use several options with this command. See the nfsd1M 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. 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.NFS version 4 does not use this 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.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. 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.conf4 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 Configuring the NFS Version 4 Default Domain resolv.conf4 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 /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.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 domainname1M 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 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.conf4 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.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. 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:nslookup1M dig1M resolv.conf4 domainname1M This section describes how the network obtains the desired default domain:For the Solaris Express 5/06 release, see Configuring an NFS Version 4 Default Domain in the Solaris Express 5/06 Release. For the initial Solaris 10 release, see Configuring an NFS Version 4 Default Domain in the Solaris 10 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 sysidtool1M and sysidnfs41M. 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 sysidcfg4 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 xtermsThe 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 xtermsThe 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 JumpStart 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. 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:Solaris Express Installation Guide: Basic Installations Solaris Express Installation Guide: Network-Based Installations 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 sysidconfig1M 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 []:If a value for NFSMAPID_DOMAIN exists in /etc/default/nfs, the [domain_name] that you provide overrides that value. For more information about nfsmapid, see the following:nfsmapid1M man page nfs4 man page http://www.ietf.org/rfc/rfc1464.txt ACLs and nfsmapid in NFS Version 4 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 statd1M 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 v6hostIn 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.NFS version 4 does not use this daemon. These commands must be run as root to be fully effective, but requests for information can be made by all users: automount Command clear_locks Command fsstat Command mount Command mountall Command setmnt Command sharemgr Command sharectl Command share Command shareall Command showmount Command umount Command umountall Command unshare Command unshareall Command This command installs autofs mount points and associates the information in the automaster files with each mount point. The syntax of the command is as follows:automount [ t duration ] [ v ]t duration sets the time, in seconds, that a file system is to remain mounted, and v selects the verbose mode. Running this command in the verbose mode allows for easier troubleshooting.If not specifically set, the value for duration is set to 5 minutes. In most circumstances, this value is good. However, on systems that have many automounted file systems, you might need to increase the duration value. In particular, if a server has many users active, checking the automounted file systems every 5 minutes can be inefficient. Checking the autofs file systems every 1800 seconds, which is 30 minutes, could be more optimal. By not unmounting the file systems every 5 minutes, /etc/mnttab can become large. To reduce the output when df checks each entry in /etc/mnttab, you can filter the output from df by using the F option (see the df1M man page) or by using egrep.You should consider that adjusting the duration also changes how quickly changes to the automounter maps are reflected. Changes cannot be seen until the file system is unmounted. Refer to Modifying the Maps for instructions on how to modify automounter maps. This command enables you to remove all file, record, and share locks for an NFS client. You must be root to run this command. From an NFS server, you can clear the locks for a specific client. From an NFS client, you can clear locks for that client on a specific server. The following example would clear the locks for the NFS client that is named tulip on the current system. # clear_locks tulipUsing the s option enables you to specify which NFS host to clear the locks from. You must run this option from the NFS client, which created the locks. In this situation, the locks from the client would be removed from the NFS server that is named bee.# clear_locks -s beeThis command should only be run when a client crashes and cannot clear its locks. To avoid data corruption problems, do not clear locks for an active client. Starting in the Solaris 10 11/06 release, the fsstat utility enables you to monitor file system operations by file system type and by mount point. Various options allow you to customize the output. See the following examples.This example shows output for NFS version 3, version 4, and the root mount point.% fsstat nfs3 nfs4 / new name name attr attr lookup rddir read read write write file remov chng get set ops ops ops bytes ops bytes 3.81K 90 3.65K 5.89M 11.9K 35.5M 26.6K 109K 118M 35.0K 8.16G nfs3 759 503 457 93.6K 1.44K 454K 8.82K 65.4K 827M 292 223K nfs4 25.2K 18.1K 1.12K 54.7M 1017 259M 1.76M 22.4M 20.1G 1.43M 3.77G /This example uses the i option to provide statistics about the I/O operations for NFS version 3, version 4, and the root mount point.% fsstat -i nfs3 nfs4 / read read write write rddir rddir rwlock rwulock ops bytes ops bytes ops bytes ops ops 109K 118M 35.0K 8.16G 26.6K 4.45M 170K 170K nfs3 65.4K 827M 292 223K 8.82K 2.62M 74.1K 74.1K nfs4 22.4M 20.1G 1.43M 3.77G 1.76M 3.29G 25.5M 25.5M /This example uses the n option to provide statistics about the naming operations for NFS version 3, version 4, and the root mount point.% fsstat -n nfs3 nfs4 / lookup creat remov link renam mkdir rmdir rddir symlnk rdlnk 35.5M 3.79K 90 2 3.64K 5 0 26.6K 11 136K nfs3 454K 403 503 0 101 0 0 8.82K 356 1.20K nfs4 259M 25.2K 18.1K 114 1017 10 2 1.76M 12 8.23M /For more information, see the fsstat1M man page. With this command, you can attach a named file system, either local or remote, to a specified mount point. For more information, see the mount1M man page. Used without arguments, mount displays a list of file systems that are currently mounted on your computer. Many types of file systems are included in the standard Solaris installation. Each file-system type has a specific man page that lists the options to mount that are appropriate for that file-system type. The man page for NFS file systems is mount_nfs1M. For UFS file systems, see mount_ufs1M. The Solaris 7 release includes the ability to select a path name to mount from an NFS server by using an NFS URL instead of the standard server:/pathname syntax. See How to Mount an NFS File System Using an NFS URL for further information.The version of the mount command that is included in any Solaris release from 2.6 to the current release does not warn about invalid options. The command silently ignores any options that cannot be interpreted. Ensure that you verify all of the options that were used so that you can prevent unexpected behavior. The subsequent text lists some of the options that can follow the o flag when you are mounting an NFS file system. For a complete list of options, refer to the mount_nfs1M man page. bg|fgThese options can be used to select the retry behavior if a mount fails. The bg option causes the mount attempts to be run in the background. The fg option causes the mount attempt to be run in the foreground. The default is fg, which is the best selection for file systems that must be available. This option prevents further processing until the mount is complete. bg is a good selection for noncritical file systems because the client can do other processing while waiting for the mount request to be completed. forcedirectioThis option improves performance of large sequential data transfers. Data is copied directly to a user buffer. No caching is performed in the kernel on the client. This option is off by default. Previously, all write requests were serialized by both the NFS client and the NFS server. The NFS client has been modified to permit an application to issue concurrent writes, as well as concurrent reads and writes, to a single file. You can enable this functionality on the client by using the forcedirectio mount option. When you use this option, you are enabling this functionality for all files within the mounted file system. You could also enable this functionality on a single file on the client by using the directio interface. Unless this functionality has been enabled, writes to files are serialized. Also, if concurrent writes or concurrent reads and writes are occurring, then POSIX semantics are no longer being supported for that file.For an example of how to use this option, refer to Using the mount Command. largefilesWith this option, you can access files that are larger than 2 Gbytes on a server that is running the Solaris 2.6 release. Whether a large file can be accessed can only be controlled on the server, so this option is silently ignored on NFS version 3 mounts. Starting with release 2.6, by default, all UFS file systems are mounted with largefiles. For mounts that use the NFS version 2 protocol, the largefiles option causes the mount to fail with an error. nolargefilesThis option for UFS mounts guarantees that no large files can exist on the file system. See the mount_ufs1M man page. Because the existence of large files can only be controlled on the NFS server, no option for nolargefiles exists when using NFS mounts. Attempts to NFS-mount a file system by using this option are rejected with an error. nosuid|suidStarting in the Solaris 10 release, the nosuid option is the equivalent of specifying the nodevices option with the nosetuid option. When the nodevices option is specified, the opening of device-special files on the mounted file system is disallowed. When the nosetuid option is specified, the setuid bit and setgid bit in binary files that are located in the file system are ignored. The processes run with the privileges of the user who executes the binary file.The suid option is the equivalent of specifying the devices option with the setuid option. When the devices option is specified, the opening of device-special files on the mounted file system is allowed. When the setuid option is specified, the setuid bit and the setgid bit in binary files that are located in the file system are honored by the kernel.If neither option is specified, the default option is suid, which provides the default behavior of specifying the devices option with the setuid option.The following table describes the effect of combining nosuid or suid with devices or nodevices, and setuid or nosetuid. Note that in each combination of options, the most restrictive option determines the behavior.Behavior From the Combined Options Option Option Option The equivalent of nosetuid with nodevices nosuid nosetuid nodevices The equivalent of nosetuid with nodevices nosuid nosetuid devices The equivalent of nosetuid with nodevices nosuid setuid nodevices The equivalent of nosetuid with nodevices nosuid setuid devices The equivalent of nosetuid with nodevices suid nosetuid nodevices The equivalent of nosetuid with devices suid nosetuid devices The equivalent of setuid with nodevices suid setuid nodevices The equivalent of setuid with devices suid setuid devices The nosuid option provides additional security for NFS clients that access potentially untrusted servers. The mounting of remote file systems with this option reduces the chance of privilege escalation through importing untrusted devices or importing untrusted setuid binary files. All these options are available in all Solaris file systems. publicThis option forces the use of the public file handle when contacting the NFS server. If the public file handle is supported by the server, the mounting operation is faster because the MOUNT protocol is not used. Also, because the MOUNT protocol is not used, the public option allows mounting to occur through a firewall. rw|roThe rw and ro options indicate whether a file system is to be mounted read-write or read-only. The default is read-write, which is the appropriate option for remote home directories, mail-spooling directories, or other file systems that need to be changed by users. The read-only option is appropriate for directories that should not be changed by users. For example, shared copies of the man pages should not be writable by users. sec=modeYou can use this option to specify the authentication mechanism to be used during the mount transaction. The value for mode can be one of the following.Use krb5 for Kerberos version 5 authentication service. Use krb5i for Kerberos version 5 with integrity. Use krb5p for Kerberos version 5 with privacy. Use none for no authentication. Use dh for Diffie-Hellman (DH) authentication. Use sys for standard UNIX authentication. The modes are also defined in /etc/nfssec.conf. soft|hardAn NFS file system that is mounted with the soft option returns an error if the server does not respond. The hard option causes the mount to continue to retry until the server responds. The default is hard, which should be used for most file systems. Applications frequently do not check return values from soft-mounted file systems, which can make the application fail or can lead to corrupted files. If the application does check the return values, routing problems and other conditions can still confuse the application or lead to file corruption if the soft option is used. In most situations, the soft option should not be used. If a file system is mounted by using the hard option and becomes unavailable, an application that uses this file system hangs until the file system becomes available. Refer to the following examples.In NFS version 2 or version 3, both of these commands mount an NFS file system from the server bee read-only.# mount -F nfs -r bee:/export/share/man /usr/man# mount -F nfs -o ro bee:/export/share/man /usr/manIn NFS version 4, the following command line would accomplish the same mount.# mount -F nfs -o vers=4 -r bee:/export/share/man /usr/man In NFS version 2 or version 3, this command uses the O option to force the man pages from the server bee to be mounted on the local system even if /usr/man has already been mounted. See the following.# mount -F nfs -O bee:/export/share/man /usr/manIn NFS version 4, the following command line would accomplish the same mount.# mount -F nfs -o vers=4 -O bee:/export/share/man /usr/man In NFS version 2 or version 3, this command uses client failover.# mount -F nfs -r bee,wasp:/export/share/man /usr/manIn NFS version 4, the following command line uses client failover.# mount -F nfs -o vers=4 -r bee,wasp:/export/share/man /usr/manWhen used from the command line, the listed servers must support the same version of the NFS protocol. Do not use both version 2 and version 3 servers when running mount from the command line. You can use both servers with autofs. Autofs automatically selects the best subset of version 2 or version 3 servers. Here is an example of using an NFS URL with the mount command in NFS version 2 or version 3.# mount -F nfs nfs://bee//export/share/man /usr/manHere is an example of using an NFS URL with the mount command in NFS version 4.# mount -F nfs -o vers=4 nfs://bee//export/share/man /usr/man Use the forcedirectio mount option to enable the client to permit concurrent writes, as well as concurrent reads and writes, to a file. Here is an example. # mount -F nfs -o forcedirectio bee:/home/somebody /mntIn this example, the command mounts an NFS file system from the server bee and enables concurrent reads and writes for each file in the directory /mnt. When support for concurrent reads and writes is enabled, the following occurs.The client permits applications to write to a file in parallel. Caching is disabled on the client. Consequently, data from reads and writes is kept on the server. More explicitly, because the client does not cache the data that is read or written, any data that the application does not already have cached for itself is read from the server. The client's operating system does not have a copy of this data. Normally, the NFS client caches data in the kernel for applications to use.Because caching is disabled on the client, the read-ahead and write-behind processes are disabled. A read-ahead process occurs when the kernel anticipates the data that an application might request next. The kernel then starts the process of gathering that data in advance. The kernel's goal is to have the data ready before the application makes a request for the data.The client uses the write-behind process to increase write throughput. Instead of immediately starting an I/O operation every time an application writes data to a file, the data is cached in memory. Later, the data is written to the disk.Potentially, the write-behind process permits the data to be written in larger chunks or to be written asynchronously from the application. Typically, the result of using larger chunks is increased throughput. Asynchronous writes permit overlap between application processing and I/O processing. Also, asynchronous writes permit the storage subsystem to optimize the I/O by providing a better sequencing of the I/O. Synchronous writes force a sequence of I/O on the storage subsystem that might not be optimal. Significant performance degradation can occur if the application is not prepared to handle the semantics of data that is not being cached. Multithreaded applications avoid this problem. If support for concurrent writes is not enabled, all write requests are serialized. When requests are serialized, the following occurs. When a write request is in progress, a second write request has to wait for the first write request to be completed before proceeding. Use the mount command with no arguments to display file systems that are mounted on a client. See the following.% mount / on /dev/dsk/c0t3d0s0 read/write/setuid on Wed Apr 7 13:20:47 2004 /usr on /dev/dsk/c0t3d0s6 read/write/setuid on Wed Apr 7 13:20:47 20041995 /proc on /proc read/write/setuid on Wed Apr 7 13:20:47 2004 /dev/fd on fd read/write/setuid on Wed Apr 7 13:20:47 2004 /tmp on swap read/write on Wed Apr 7 13:20:51 2004 /opt on /dev/dsk/c0t3d0s5 setuid/read/write on Wed Apr 7 13:20:51 20041995 /home/kathys on bee:/export/home/bee7/kathys intr/noquota/nosuid/remote on Wed Apr 24 13:22:13 2004 This command enables you to remove a remote file system that is currently mounted. The umount command supports the V option to allow for testing. You might also use the a option to unmount several file systems at one time. If mount-points are included with the a option, those file systems are unmounted. If no mount points are included, an attempt is made to unmount all file systems that are listed in /etc/mnttab except for the “required” file systems, such as /, /usr, /var, /proc, /dev/fd, and /tmp. Because the file system is already mounted and should have an entry in /etc/mnttab, you do not need to include a flag for the file-system type. The f option forces a busy file system to be unmounted. You can use this option to unhang a client that is hung while trying to mount an unmountable file system.By forcing an unmount of a file system, you can cause data loss if files are being written to. See the following examples.This example unmounts a file system that is mounted on /usr/man: # umount /usr/man This example displays the results of running umount a -V: # umount -a -V umount /home/kathys umount /opt umount /home umount /netNotice that this command does not actually unmount the file systems. Use this command to mount all file systems or a specific group of file systems that are listed in a file-system table. The command provides a way of doing the following:Selecting the file-system type to be accessed with the F FSType option Selecting all the remote file systems that are listed in a file-system table with the r option Selecting all the local file systems with the l option Because all file systems that are labeled as NFS file-system type are remote file systems, some of these options are redundant. For more information, see the mountall1M man page. Note that the following two examples of user input are equivalent: # mountall -F nfs# mountall -F nfs -r Use this command to unmount a group of file systems. The k option runs the fuser k mount-point command to kill any processes that are associated with the mount-point. The s option indicates that unmount is not to be performed in parallel. l specifies that only local file systems are to be used, and r specifies that only remote file systems are to be used. The h host option indicates that all file systems from the named host should be unmounted. You cannot combine the h option with l or r. The following is an example of unmounting all file systems that are mounted from remote hosts: # umountall -rThe following is an example of unmounting all file systems that are currently mounted from the server bee: # umountall -h bee The Solaris Express, Developer Edition 2/07 release includes the sharemgr utility, which is an administrative tool that provides an enhanced method of sharing files and performing related tasks. Previously, such tasks were accomplished by adding entries to the /etc/dfs/dfstab file and using the share command to create a temporary share. You made the share permanent by rebooting the system or using the shareall command. Related administrative tasks necessitated that you manually edit configuration files. The sharemgr utility simplifies this process by introducing two concepts:Share – One or more files or directories in a share group. Share group – A container of one or more shared files or directories. Note the following:Options for sharemgr are set to a share group, not to a specific file or directory. All options apply to each file and directory in the group. A file or directory can only be assigned to one share group. However, you can move a file or directory from one group to another. A share group can be used by multiple file-system types. For example, the share group my_group could be used by NFS and ZFS and be assigned one set of options for NFS and another set of options for ZFS.When a share is managed by ZFS, sharemgr identifies the share and lists it in a zfs share group. The sharemgr utility accomplishes different tasks by using subcommands. Options and their related properties can be used with each subcommand. The utility uses the following syntax:# sharemgr [subcommand] [option] [share_group]The sharemgr utility provides a unique way of checking the validity of a desired configuration. The n option allows you to test the validity of the options and properties you want to use with a specific subcommand. The test does not change your configuration. For example, if you use the n option with the subcommand create, no share group is created. The following tables describes the subcommands supported by the sharemgr utility.Subcommand Description create Makes (or creates) a new share group delete Removes a share group list Lists the current share groups show Lists the shares by share group set Sets a share group's properties, including the group's security property unset Removes (or unsets) properties from a share group add-share Adds a new share to a share group move-share Moves a share from one share group to another remove-share Removes a share from a share group set-share Updates the properties associated with a share disable Unshares one or more share groups enable Shares one or more share groups start Used by the smf utility to share one or more share groups stop Used by the smf utility to unshare one or more share groups -h Provides online-help descriptions of sharemgr and its subcommands and options, and shows the syntax to use The following table describes the properties supported by the sharemgr utility.Property Value Description aclok boolean Enable access control lists (ACL) for NFS version 2. anon UID Specify the User ID for unknown users. index file path Include the specified file in a content list for a directory. log tag Specify a tag for NFS server logging. Note that these tags are defined in the /etc/nfs/nfslog.conf file. nosub boolean Disallow clients from mounting subdirectories of shares. nosuid boolean Disallow the use of the setuid and setgid functions. public boolean Move the location of a public file handle from root to an exported directory for WebNFS-enabled browsers and clients. Only one file system (or share) on each server can use this property. This property is not accepted by a share group. For more information, see share_nfs1M man page. ro access-list, boolean, or an asterisk (*) If the property is set to an access-list, permissions for the list are set to read-only. For information about access lists, see the share_nfs1M man page.If you set the property to no value or true, permissions for the share group are set to read-only.If you set the property to an asterisk (*), permissions for all hosts are set to read-only.To use this property, you must use the S option to set the security mode. For more information about setting a security mode, see set Subcommand. root access-list or an asterisk (*) If the property is set to an access-list, permissions for the list are set to root access. For information about access-lists, see the share_nfs1M man page.If you set the property to an asterisk (*), all hosts have root access.To use this property, you must use the S option to set the security mode. For more information about setting a security mode, see set Subcommand. rw access-list, boolean, or an asterisk (*) If the property is set to an access-list, permissions for the list are set to read-write. For information about access-lists, see the share_nfs1M man page.If you set the property to no value or true, permissions for the share group are set to read-write.If you set the property to an asterisk (*), permissions for all hosts are set to read-write.To use this property, you must use the S option to set the security mode. For more information about setting a security mode, see set Subcommand. window integer For the dh security mode, set the number of seconds a credential is available.To use this property, you must use the S option to set the security mode. For more information about setting a security mode, see set Subcommand. sharemgr and sharectl are the preferred utilities for managing your file systems and file-sharing protocols. For procedures that use the sharemgr utility, see the following:Automatic File-System Sharing Mounting File Systems Administering the Secure NFS System Also, see the sharemgr1M man page.The sharectl utility is an administrative tool that enables you to configure and manage file-sharing protocols, such as NFS. For more information, see the following:sharectl1M man page sharectl Command. The sections that follow describe each subcommand for sharemgr and provide examples.create Subcommand delete Subcommand list Subcommand show Subcommand set Subcommand unset Subcommand add-share Subcommand move-share Subcommand remove-share Subcommand set-share Subcommand enable Subcommand disable Subcommand start Subcommand stop Subcommand -h Feature The create subcommand makes (or creates) a share group. After you create a share group, use the add-share subcommand to add shares to the group. Note the following:The group name is restricted to alphanumeric characters, the hyphen (-), and the underscore (_). The first character must be alphabetic. By default, a newly created share group is enabled. If a file-system type is not specified, all supported protocols are added to the share group. When adding options to the share group, you must explicitly define the protocol associated with the options. This subcommand supports the following options:nChecks the validity of a desired configuration. PSpecifies a file-system type. The default is NFS. pSpecifies a property for the new share group. hProvides an online-help description. The create subcommand uses the following syntax:# sharemgr create [-h] [-n] [-P protocol] [-p property=value] share_groupThe following example creates my_group with the following parameters:The share group uses NFS. The permissions for the group are set to read-write. The functions, setuid and setgid, cannot be used on my_group. example# sharemgr create -P nfs -p rw=true -p nosuid=true my_group This subcommand removes a share group. Before using this option, use the remove-share subcommand to delete all shares from the group. Alternately, use the f option with this subcommand to force the removal of a group that might still contain shares. The f option unshares and removes all shares from the share group, so the share group can be removed.To remove a protocol from a share group, use the P option. Note that when using the P option, the share group is not removed. Only the protocol is removed from the group.This subcommand supports the following options:nChecks the validity of command-line string fForces a share group to be removed PSpecifies a file-system type to be removed from the group hProvides an online-help description This subcommand uses the following syntax:# sharemgr delete [-h] [-n] [-f] [-P protocol] share_group This subcommand provides a list of current share groups. You can customize the output by using various options with this subcommand.This subcommand supports the following options:PEnables you to see a list of groups that use a specific file-system type. vIs the verbose option and provides the following:Group name Status of the group, specifically whether the group is enabled or disabled File-system type used by the group hProvides an online-help description. This subcommand uses the following syntax:# sharemgr list [-h] [-P protocol] [-v]The following example shows the output for the v option:example# sharemgr list -v group01 enabled nfs group02 disabled nfs This subcommand provides a list of shares by group. By specifying one or more share groups, you can limit the output to a list of shares in the specified groups. If no groups are specified, the list shows the shares in each group.This subcommand supports the following options:pShows you the properties assigned to each group. vIs the verbose option. If included, the verbose option provides the resource name and descriptions of each share. xCreates an XML file for the output. Because this option automatically includes the information you would get from the p and v options, no other options are needed when you use this option. hProvides an online-help description. This subcommand uses the following syntax:# sharemgr show [-h] [-v] [-p] [-x] [share_group...]The following example uses the p option to show the shares and group properties for my_group:example01# sharemgr show -p my_group my_group nfs=(rw=true nosuid=true) /export/home/home0 /export/home/home1The next example uses the v option to show the shares in my_group and their descriptions:example02# sharemgr show -v my_group my_group HOME0=/export/home/home0 "Home directory set 0" HOME1=/export/home/home1 "Home directory set 1" This subcommand sets properties to a share group. Note the following conditions:If you do not change the protocol currently associated with the group, the previous property value is replaced with the new value. If you specify a different protocol for the group, the new properties for the different protocol are added to the existing shares. A group can be associated with more than one protocol and can have different properties for each protocol.This subcommand supports the following options:nChecks the validity of the command-line string. PSpecifies a file-system type. pSpecifies a property for the share group. SSpecifies the security mode, such as sys, dh, or krb5. For more information about security modes, see the nfssec5 man page. sSpecifies the path to the share, which is a file or a directory. hProvides an online-help description. This subcommand uses the following syntax:# sharemgr set [-h] [-n] [-P protocol] [-s share-path] [-S security-mode] [-p property=value] share_groupThe following example sets the user ID for unknown users in my_group to 1234546:example01# sharemgr set -p anon=123456 my_groupIn the next example, the following occurs:my_group continues to use NFS. Previously, nosuid was set to true. Because set replaces the previous value for nosuid with the new value, the functions, setuid and setgid, can now be used on the shares in my_group. The permissions for the group continue to be set to read-write. example02# sharemgr create -P nfs -p rw=true -p nosuid=true my_group example02# sharemgr set -P nfs -p nosuid=false my_group This subcommand removes (or unsets) properties from a share group.This subcommand supports the following options:nChecks the validity of the command-line string PSpecifies the protocol associated with the properties being removed from the group pSpecifies the property to be removed from the share group sSpecifies the path to the share, which is a file or a directory. hProvides an online-help description This subcommand uses the following syntax:# sharemgr unset [-h] [-n] -P protocol [-s share-path] [-p property] share_group After creating a share group, use this subcommand to add shares to the group. A share is a path to a file or a directory. Note that a share can exist in one group only. If you try to add a share to another group, you will get an error message.This subcommand supports the following options:nChecks the validity of the command-line string. sSpecifies the path to the share, which is a file or a directory. tSpecifies that the share is transient. Transient shares are automatically removed from the group when you reboot the system or use the disable or stop subcommands. dAdds descriptive text about the share. rAssigns the share a resource name that identifies the share. Note that the resource name only uses alphanumeric characters, the hyphen (-), and the underscore (_). The first character in the name must be alphabetic. hProvides an online-help description. This subcommand uses the following syntax:# sharemgr add-share [-h] [-n] -s share-path [-t] [-d description] [-r resource-name] share_groupThe following example adds the shares /export/home/home0 and /export/home/home1 to my_group.example# sharemgr add-share -s /export/home/home0 my_group example# sharemgr add-share -s /export/home/home1 my_group Use this subcommand to move a share from one group to another.This subcommand supports the following options:nChecks the validity of the command-line string sSpecifies the path to the share, which is a file or a directory hProvides an online-help description This subcommand uses the following syntax:# sharemgr move-share [-h] [-n] -s share-path share_groupThe following example shows a share that was added to my_group and then moved to your_group.example# sharemgr add-share -s /export/home/home0 my_group example# sharemgr move-share -s /export/home/home0 your_group Use this subcommand to remove a share from a share group.This subcommand supports the following options:nChecks the validity of the command-line string sSpecifies the path to the share, which is a file or a directory hProvides an online-help description This subcommand uses the following syntax:# sharemgr remove-share [-h] [-n] -s share-path share_groupThe following example removes the share /export/home/home0 from my_group.example# sharemgr remove-share -s /export/home/home0 my_group Use this subcommand to change the properties associated with a share. Currently, you can use this subcommand to change the descriptive text associated with a specific share.This subcommand supports the following options:nChecks the validity of the command-line string. sSpecifies the path to the share, which is a file or a directory. dAdds descriptive text about the share. rAssigns the share a resource name that identifies the share. Note that the resource name only uses alphanumeric characters, the hyphen (-), and the underscore (_). The first character in the name must be alphabetic. hProvides an online-help description. This subcommand uses the following syntax:# sharemgr set-share [-h] [-n] -s share-path [-d description] [-r resource-name] share_groupThe following example shows how a description is changed.example# sharemgr add-share -s /export/home/home0 -d "original text" my_group example# sharemgr set-share -s /export/home/home0 -d "new text" my_group Use this subcommand to share (or enable) the shares in the groups that you specify. Note that the groups you create are enabled by default. You must use this subcommand to enable a group that has previously been disabled with the disable subcommand.If you specify a protocol, only the groups that are associated with that protocol are enabled. This subcommand supports the following options:aSpecifies all groups nChecks the validity of the command-line string PSpecifies a file-system type hProvides an online-help description This subcommand uses the following syntax:# sharemgr enable [-h] [-n] [-P protocol] [share_group | -a]The following example shares (or enables) the shares in all groups that use NFS.example01# sharemgr enable -P NFS -aIn this next example, all shares in my_group are shared (or enabled).example02# sharemgr enable my_group Use this subcommand to unshare (or disable) the shares in the groups that you specify. This subcommand can be reversed by using the enable subcommand.If you specify a protocol, only the groups that are associated with that protocol are disabled. This subcommand supports the following options:aSpecifies all groups nChecks the validity of the command-line string PSpecifies a file-system type hProvides an online-help description This subcommand uses the following syntax:# sharemgr disable [-h] [-P protocol] [share_group | -a]The following example unshares (or disables) the shares in all groups that use NFS.example01# sharemgr disable -P NFS -aIn this next example, all shares in my_group are unshared (or disabled).example02# sharemgr disable my_group This subcommand is similar to the enable subcommand with these distinctions:start enables the shares to start sharing in specified groups that have previously been stopped by the stop subcommand. start can be used by SMF (Service Management Facility) to enable shares to start sharing in specified groups during a system boot. See the man pages for smf5 and svcadm1M. start works only on groups that are enabled. This subcommand supports the following options:aSpecifies all groups hProvides an online-help description Using the start Subcommand Using the svcadm Command The start subcommand uses the following syntax:# sharemgr start [-h] [share-group | -a]The following example enables the shares in all groups to start sharing.# sharemgr start -a The svcadm command uses the following syntax:# svcadm start network/shares/group:share-groupThe following example enables the shares in my-group to start sharing.# svcadm start network/shares/group:my-group This subcommand is similar to the disable subcommand with these distinctions:stop unshares the shares in specified groups, and can only be reversed by using the start subcommand. stop can be used by SMF (Service Management Facility) to unshare the shares in specified groups during a system shutdown. See the man pages for smf5 and svcadm1M. stop works only on groups that are enabled. stop permanently removes all transient shares. This subcommand supports the following options:aSpecifies all groups hProvides an online-help description Using the stop Subcommand Using the svcadm Command The stop subcommand uses the following syntax:# sharemgr stop [-h] [share-group | -a]The following example unshares the shares in all groups.# sharemgr stop -a The svcadm command uses the following syntax:# svcadm stop network/shares/group:share-groupThe following example unshares the shares in my-group.# svcadm stop network/shares/group:my-group The sharemgr utility has an online help feature that describes sharemgr and its subcommands and options, and shows proper syntax. For online help, use h.This feature uses the following syntax:# sharemgr [subcommand] -hThe following example uses h to provide a complete description of the sharemgr utility.example01# sharemgr -h USAGE: # sharemgr [subcommand] [option] [share_group] DESCRIPTION: Configures and manages file sharing SUBCOMMANDS: create Makes (or creates) a new share group delete Removes a share group list Lists the current share groups show Lists the shares by share group set Sets a share group's properties unset Removes (or unsets) properties from a share group add-share Adds a new share to a share group move-share Moves a share from one share group to another remove-share Removes a share from a share group set-share Updates the properties associated with a share disable Unshares one or more share groups enable Shares one or more share groups start Used by the smf utility to share one or more share groups stop Used by the smf utility to unshare one or more share groups -h Online-help feature SEE ALSO: sharemgr(1M) man page System Administration Guide: Network ServicesThis next example uses h to provide information about the set subcommand.example02# sharemgr set -h USAGE: # sharemgr set [-h] [-n] [-P protocol] [-S security-mode] [-p property=value] share_group DESCRIPTION: Sets a share group's properties OPTIONS: -h Online-help feature -n Checks the validity of the command-line string -P Specifies a file-system type. -p Specifies a property for the share group. -S Specifies the security mode, such as sys, dh, or krb5 PROPERTIES: aclok={true|false} Enable access control lists (ACL) for NFS version 2. anon=UID Specify the User ID for unknown users. index=file path Include the specified file in a content list for a directory. log=tag Specify a tag to use for log messages. nosub={true|false} Disallow clients from mounting subdirectories of shares. nosuid={true|false} Disallow the use of the setuid() and setgid() functions. ro={access-list|true|*} If ro is set to an access-list, permissions for the list are read-only. If ro is set to no value or to true, permissions for the share group are read-only. If ro is set to an asterisk (*), permissions for all hosts are set to read-only. root={access-list|*} If root is set to an access-list, permissions for the list are set to allow root access. If root is set to an asterisk (*), all hosts have root access. rw={access-list|true|*} If rw is set to an access list, permissions for the list are set to read-write. If rw is set to no value or to true, permissions for the share group are set to read-write. If rw is set to an asterisk (*), permissions for all hosts are set to read-write. window=integer For the dh security mode, set the number of seconds a credential is available. SEE ALSO: sharemgr(1M) man page System Administration Guide: Network Services nfssec(5) man page for more information about security modesFor help, you can also refer to the sharemgr1M man page. The Solaris Express, Developer Edition 2/07 release includes the sharectl utility, which is an administrative tool that enables you to configure and manage file-sharing protocols, such as NFS. You can use this command to do the following:Set client and server operational properties Display property values for a specific protocol Obtain the status of a protocol The sharectl utility uses the following syntax:# sharectl subcommand [option] [protocol]The sharectl utility supports the following subcommands:Subcommand Description set Defines the properties for a file-sharing protocol. For a list of properties and property values, see the parameters described in the nfs4 man page. get Displays the properties and property values for the specified protocol. status Displays whether the specified protocol is enabled or disabled. If no protocol is specified, the status of all file-sharing protocols is displayed. sharemgr and sharectl are the preferred utilities for managing your file systems and file-sharing protocols. For more information about the sharectl utility, see the following:sharectl1M man page set Subcommand get Subcommand status Subcommand For information about the sharemgr utility, see the following:sharemgr1M man page sharemgr Command The set subcommand, which defines the properties for a file-sharing protocol, supports the following options:hProvides an online-help description pDefines a property for the protocol The set subcommand uses the following syntax:# sharectl set [-h] [-p property=value] protocolThe following:You must have root privileges to use the set subcommand. You do not need to repeat this command-line syntax for each additional property value. You can use the p option multiple times to define multiple properties on the same command line. The following example sets the minimum version of the NFS protocol for the client to 3:# sharectl set -p nfs_client_versmin=3 nfs The get subcommand, which displays the properties and property values for the specified protocol, supports the following options:hProvides an online-help description. pIdentifies the property value for the specified property. If the p option is not used, all property values are displayed. The get subcommand uses the following syntax:# sharectl get [-h] [-p property] protocolYou must have root privileges to use the get subcommand. The following example uses nfsd_servers, which is the property that enables you to specify the maximum number of concurrent NFS requests:# sharectl get -p nfsd_servers nfs nfsd_servers=16In the following example, because the p option is not used, all property values are displayed:# sharectl get nfs listen_backlog=32 protocol=ALL servers=32 lockd_listen_backlog=32 lockd_servers=20 lockd_retransmit_timeout=5 grace_period=90 nfsmapid_domain=company.com server_versmin=2 server_versmax=4 client_versmin=2 client_versmax=4 max_connections=-1 The status subcommand, which displays whether the specified protocol is enabled or disabled, supports the following option:hProvides an online-help description The status subcommand uses the following syntax:# sharectl status [-h] [protocol]The following example shows the status of the NFS protocol:# sharectl status nfs nfs enabled Starting with the Solaris Express, Developer Edition 2/07 release, sharemgr and sharectl are the preferred utilities for managing your file systems and file-sharing protocols. See sharemgr Command and sharectl Command With this command, you can make a local file system on an NFS server available for mounting. You can also use the share command to display a list of the file systems on your system that are currently shared. The NFS server must be running for the share command to work. The NFS server software is started automatically during boot if an entry is in /etc/dfs/dfstab. The command does not report an error if the NFS server software is not running, so you must verify that the software is running. The objects that can be shared include any directory tree. However, each file system hierarchy is limited by the disk slice or partition that the file system is located on. For instance, sharing the root (/) file system would not also share /usr, unless these directories are on the same disk partition or slice. Normal installation places root on slice 0 and /usr on slice 6. Also, sharing /usr would not share any other local disk partitions that are mounted on subdirectories of /usr.A file system cannot be shared if that file system is part of a larger file system that is already being shared. For example, if /usr and /usr/local are on one disk slice, /usr can be shared or /usr/local can be shared. However, if both directories need to be shared with different share options, /usr/local must be moved to a separate disk slice.You can gain access to a file system that is read-only shared through the file handle of a file system that is read-write shared. However, the two file systems have to be on the same disk slice. You can create a more secure situation. Place those file systems that need to be read-write on a separate partition or separate disk slice from the file systems that you need to share as read-only. For information about how NFS version 4 functions when a file system is unshared and then reshared, refer to Unsharing and Resharing a File System in NFS Version 4. Some of the options that you can include with the o flag are as follows. rw|roThe pathname file system is shared read-write or read-only for all clients. rw=accesslistThe file system is shared read-write for the clients that are listed only. All other requests are denied. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist has been expanded. See Setting Access Lists With the share Command for more information. You can use this option to override an ro option. The options that you can use with NFS file systems include the following.aclokThis option enables an NFS server that supports the NFS version 2 protocol to be configured to do access control for NFS version 2 clients. Without this option, all clients are given minimal access. With this option, the clients have maximal access. For instance, on file systems that are shared with the aclok option, if anyone has read permissions, everyone does. However, without this option, you can deny access to a client who should have access permissions. A decision to permit too much access or too little access depends on the security systems already in place. See Using Access Control Lists to Protect Files in System Administration Guide: Security Services for more information about access control lists (ACLs).To use ACLs, ensure that clients and servers run software that supports the NFS version 3 and NFS_ACL protocols. If the software only supports the NFS version 3 protocol, clients obtain correct access but cannot manipulate the ACLs. If the software supports the NFS_ACL protocol, the clients obtain correct access and can manipulate the ACLs. Starting with the Solaris 2.5 release, the Solaris system supports both protocols. anon=uidYou use uid to select the user ID of unauthenticated users. If you set uid to -1, the server denies access to unauthenticated users. You can grant root access by setting anon=0, but this option allows unauthenticated users to have root access, so use the root option instead. index=filenameWhen a user accesses an NFS URL, the index=filename option forces the HTML file to load, instead of displaying a list of the directory. This option mimics the action of current browsers if an index.html file is found in the directory that the HTTP URL is accessing. This option is the equivalent of setting the DirectoryIndex option for httpd. For instance, suppose that the dfstab file entry resembles the following:share -F nfs -o ro,public,index=index.html /export/webThese URLs then display the same information:nfs://<server>/<dir> nfs://<server>/<dir>/index.html nfs://<server>//export/web/<dir> nfs://<server>//export/web/<dir>/index.html http://<server>/<dir> http://<server>/<dir>/index.html log=tagThis option specifies the tag in /etc/nfs/nfslog.conf that contains the NFS server logging configuration information for a file system. This option must be selected to enable NFS server logging. nosuidThis option signals that all attempts to enable the setuid or setgid mode should be ignored. NFS clients cannot create files with the setuid or setgid bits on. publicThe public option has been added to the share command to enable WebNFS browsing. Only one file system on a server can be shared with this option. root=accesslistThe server gives root access to the hosts in the list. By default, the server does not give root access to any remote hosts. If the selected security mode is anything other than sec=sys, you can only include client host names in the accesslist. Starting with the Solaris 2.6 release, the list of clients that are defined in accesslist is expanded. See Setting Access Lists With the share Command for more information. Granting root access to other hosts has wide security implications. Use the root= option with extreme caution. root=client-nameThe client-name value is used with AUTH_SYS authentication to check the client's IP address against a list of addresses provided by exportfs1B. If a match is found, root access is given to the file systems being shared. root=host-nameFor secure NFS modes, such as AUTH_SYS or RPCSEC_GSS, the server checks the clients' principal names against a list of host-based principal names that are derived from an access list. The generic syntax for the client's principal name is root@hostname. For Kerberos V the syntax is root/hostname.fully.qualified@REALM. When you use the host-name value, the clients on the access list must have the credentials for a principal name. For Kerberos V, the client must have a valid keytab entry for its root/hostname.fully.qualified@REALM principal name. For more information, see Configuring Kerberos Clients in System Administration Guide: Security Services. sec=mode[:mode]mode selects the security modes that are needed to obtain access to the file system. By default, the security mode is UNIX authentication. You can specify multiple modes, but use each security mode only once per command line. Each mode option applies to any subsequent rw, ro, rw=, ro=, root=, and window= options until another mode is encountered. The use of sec=none maps all users to user nobody. window=valuevalue selects the maximum lifetime in seconds of a credential on the NFS server. The default value is 30000 seconds or 8.3 hours. In Solaris releases prior to 2.6, the accesslist that was included with either the ro=, rw=, or root= option of the share command was restricted to a list of host names or netgroup names. Starting with the Solaris 2.6 release, the access list can also include a domain name, a subnet number, or an entry to deny access. These extensions should simplify file access control on a single server without having to change the namespace or maintain long lists of clients.This command provides read-only access for most systems but allows read-write access for rose and lilac: # share -F nfs -o ro,rw=rose:lilac /usr/srcIn the next example, read-only access is assigned to any host in the eng netgroup. The client rose is specifically given read-write access. # share -F nfs -o ro=eng,rw=rose /usr/srcYou cannot specify both rw and ro without arguments. If no read-write option is specified, the default is read-write for all clients. To share one file system with multiple clients, you must type all options on the same line. Multiple invocations of the share command on the same object “remember” only the last command that is run. This command enables read-write access to three client systems, but only rose and tulip are given access to the file system as root.# share -F nfs -o rw=rose:lilac:tulip,root=rose:tulip /usr/srcWhen sharing a file system that uses multiple authentication mechanisms, ensure that you include the ro, ro=, rw, rw=, root, and window options after the correct security modes. In this example, UNIX authentication is selected for all hosts in the netgroup that is named eng. These hosts can only mount the file system in read-only mode. The hosts tulip and lilac can mount the file system read-write if these hosts use Diffie-Hellman authentication. With these options, tulip and lilac can mount the file system read-only even if these hosts are not using DH authentication. However, the host names must be listed in the eng netgroup. # share -F nfs -o sec=dh,rw=tulip:lilac,sec=sys,ro=eng /usr/srcEven though UNIX authentication is the default security mode, UNIX authentication is not included if the sec option is used. Therefore, you must include a sec=sys option if UNIX authentication is to be used with any other authentication mechanism.You can use a DNS domain name in the access list by preceding the actual domain name with a dot. The string that follows the dot is a domain name, not a fully qualified host name. The following entry allows mount access to all hosts in the eng.example.com domain:# share -F nfs -o ro=.:.eng.example.com /export/share/manIn this example, the single “.” matches all hosts that are matched through the NIS or NIS+ namespaces. The results that are returned from these name services do not include the domain name. The “.eng.example.com” entry matches all hosts that use DNS for namespace resolution. DNS always returns a fully qualified host name. So, the longer entry is required if you use a combination of DNS and the other namespaces.You can use a subnet number in an access list by preceding the actual network number or the network name with “@”. This character differentiates the network name from a netgroup or a fully qualified host name. You must identify the subnet in either /etc/networks or in an NIS or NIS+ namespace. The following entries have the same effect if the 192.168 subnet has been identified as the eng network:# share -F nfs -o ro=@eng /export/share/man # share -F nfs -o ro=@192.168 /export/share/man # share -F nfs -o ro=@192.168.0.0 /export/share/manThe last two entries show that you do not need to include the full network address.If the network prefix is not byte aligned, as with Classless Inter-Domain Routing (CIDR), the mask length can be explicitly specified on the command line. The mask length is defined by following either the network name or the network number with a slash and the number of significant bits in the prefix of the address. For example:# share -f nfs -o ro=@eng/17 /export/share/man # share -F nfs -o ro=@192.168.0/17 /export/share/manIn these examples, the “/17” indicates that the first 17 bits in the address are to be used as the mask. For additional information about CIDR, look up RFC 1519.You can also select negative access by placing a “-” before the entry. Note that the entries are read from left to right. Therefore, you must place the negative access entries before the entry that the negative access entries apply to:# share -F nfs -o ro=-rose:.eng.example.com /export/share/manThis example would allow access to any hosts in the eng.example.com domain except the host that is named rose. This command allows you to make a previously available file system unavailable for mounting by clients. You can use the unshare command to unshare any file system, whether the file system was shared explicitly with the share command or automatically through /etc/dfs/dfstab. If you use the unshare command to unshare a file system that you shared through the dfstab file, be careful. Remember that the file system is shared again when you exit and reenter run level 3. You must remove the entry for this file system from the dfstab file if the change is to continue. When you unshare an NFS file system, access from clients with existing mounts is inhibited. The file system might still be mounted on the client, but the files are not accessible.For information about how NFS version 4 functions when a file system is unshared and then reshared, refer to Unsharing and Resharing a File System in NFS Version 4. The following is an example of unsharing a specific file system:# unshare /usr/src This command allows for multiple file systems to be shared. When used with no options, the command shares all entries in /etc/dfs/dfstab. You can include a file name to specify the name of a file that lists share command lines. If you do not include a file name, /etc/dfs/dfstab is checked. If you use a “-” to replace the file name, you can type share commands from standard input. The following is an example of sharing all file systems that are listed in a local file: # shareall /etc/dfs/special_dfstab This command makes all currently shared resources unavailable. The F FSType option selects a list of file-system types that are defined in /etc/dfs/fstypes. This flag enables you to choose only certain types of file systems to be unshared. The default file-system type is defined in /etc/dfs/fstypes. To choose specific file systems, use the unshare command. The following is an example of unsharing all NFS-type file systems:# unshareall -F nfs This command displays one of the following:All clients that have remotely mounted file systems that are shared from an NFS server Only the file systems that are mounted by clients The shared file systems with the client access information The showmount command only shows NFS version 2 and version 3 exports. This command does not show NFS version 4 exports. The command syntax is as follows: showmount [ ade ] [ hostname ]aPrints a list of all the remote mounts. Each entry includes the client name and the directory. dPrints a list of the directories that are remotely mounted by clients. ePrints a list of the files that are shared or are exported. hostnameSelects the NFS server to gather the information from. If hostname is not specified, the local host is queried. The following command lists all clients and the local directories that the clients have mounted:# showmount -a bee lilac:/export/share/man lilac:/usr/src rose:/usr/src tulip:/export/share/manThe following command lists the directories that have been mounted:# showmount -d bee /export/share/man /usr/srcThe following command lists file systems that have been shared:# showmount -e bee /usr/src (everyone) /export/share/man eng This command creates an /etc/mnttab table. The mount and umount commands consult the table. Generally, you do not have to run this command manually, as this command runs automatically when a system is booted. These commands can be useful when troubleshooting NFS problems.You can use this command to gather statistical information about NFS and RPC connections. The syntax of the command is as follows:nfsstat [ cmnrsz ] cDisplays client-side information mDisplays statistics for each NFS-mounted file system nSpecifies that NFS information is to be displayed on both the client side and the server side rDisplays RPC statistics sDisplays the server-side information zSpecifies that the statistics should be set to zero If no options are supplied on the command line, the cnrs options are used. Gathering server-side statistics can be important for debugging problems when new software or new hardware is added to the computing environment. Running this command a minimum of once a week, and storing the numbers, provides a good history of previous performance.Refer to the following example:# nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 719949194 0 0 0 0 58478624 33 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 73753609 0 0 0 0 987278 7254 Server nfs: calls badcalls 787783794 3516 Version 2: (746607 calls) null getattr setattr root lookup readlink read 883 0% 60 0% 45 0% 0 0% 177446 23% 1489 0% 537366 71% wrcache write create remove rename link symlink 0 0% 1105 0% 47 0% 59 0% 28 0% 10 0% 9 0% mkdir rmdir readdir statfs 26 0% 0 0% 27926 3% 108 0% Version 3: (728863853 calls) null getattr setattr lookup access 1365467 0% 496667075 68% 8864191 1% 66510206 9% 19131659 2% readlink read write create mkdir 414705 0% 80123469 10% 18740690 2% 4135195 0% 327059 0% symlink mknod remove rmdir rename 101415 0% 9605 0% 6533288 0% 111810 0% 366267 0% link readdir readdirplus fsstat fsinfo 2572965 0% 519346 0% 2726631 0% 13320640 1% 60161 0% pathconf commit 13181 0% 6248828 0% Version 4: (54871870 calls) null compound 266963 0% 54604907 99% Version 4: (167573814 operations) reserved access close commit 0 0% 2663957 1% 2692328 1% 1166001 0% create delegpurge delegreturn getattr 167423 0% 0 0% 1802019 1% 26405254 15% getfh link lock lockt 11534581 6% 113212 0% 207723 0% 265 0% locku lookup lookupp nverify 230430 0% 11059722 6% 423514 0% 21386866 12% open openattr open_confirm open_downgrade 2835459 1% 4138 0% 18959 0% 3106 0% putfh putpubfh putrootfh read 52606920 31% 0 0% 35776 0% 4325432 2% readdir readlink remove rename 606651 0% 38043 0% 560797 0% 248990 0% renew restorefh savefh secinfo 2330092 1% 8711358 5% 11639329 6% 19384 0% setattr setclientid setclientid_confirm verify 453126 0% 16349 0% 16356 0% 2484 0% write release_lockowner illegal 3247770 1% 0 0% 0 0% Server nfs_acl: Version 2: (694979 calls) null getacl setacl getattr access getxattrdir 0 0% 42358 6% 0 0% 584553 84% 68068 9% 0 0% Version 3: (2465011 calls) null getacl setacl getxattrdir 0 0% 1293312 52% 1131 0% 1170568 47% The previous listing is an example of NFS server statistics. The first five lines relate to RPC and the remaining lines report NFS activities. In both sets of statistics, knowing the average number of badcalls or calls and the number of calls per week can help identify a problem. The badcalls value reports the number of bad messages from a client. This value can indicate network hardware problems.Some of the connections generate write activity on the disks. A sudden increase in these statistics could indicate trouble and should be investigated. For NFS version 2 statistics, the connections to note are setattr, write, create, remove, rename, link, symlink, mkdir, and rmdir. For NFS version 3 and version 4 statistics, the value to watch is commit. If the commit level is high in one NFS server, compared to another almost identical server, check that the NFS clients have enough memory. The number of commit operations on the server grows when clients do not have available resources. This command displays a stack trace for each process. The pstack command must be run by the owner of the process or by root. You can use pstack to determine where a process is hung. The only option that is allowed with this command is the PID of the process that you want to check. See the proc1 man page.The following example is checking the nfsd process that is running.# /usr/bin/pgrep nfsd 243 # /usr/bin/pstack 243 243: /usr/lib/nfs/nfsd -a 16 ef675c04 poll (24d50, 2, ffffffff) 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0) 00011390 main (3, efffff14, 0, 0, ffffffff, 400) + 3c8 00010fb0 _start (0, 0, 0, 0, 0, 0) + 5cThe example shows that the process is waiting for a new connection request, which is a normal response. If the stack shows that the process is still in poll after a request is made, the process might be hung. Follow the instructions in How to Restart NFS Services to fix this problem. Review the instructions in NFS Troubleshooting Procedures to fully verify that your problem is a hung program. This command generates information about the RPC service that is running on a system. You can also use this command to change the RPC service. Many options are available with this command. See the rpcinfo1M man page. The following is a shortened synopsis for some of the options that you can use with the command.rpcinfo [ m | s ] [ hostname ]rpcinfo T transport hostname [ progname ]rpcinfo [ t | u ] [ hostname ] [ progname ]mDisplays a table of statistics of the rpcbind operations sDisplays a concise list of all registered RPC programs TDisplays information about services that use specific transports or protocols tProbes the RPC programs that use TCP uProbes the RPC programs that use UDP transportSelects the transport or protocol for the services hostnameSelects the host name of the server that you need information from prognameSelects the RPC program to gather information about If no value is given for hostname, the local host name is used. You can substitute the RPC program number for progname, but many users can remember the name and not the number. You can use the p option in place of the s option on those systems that do not run the NFS version 3 software.The data that is generated by this command can include the following:The RPC program number The version number for a specific program The transport protocol that is being used The name of the RPC service The owner of the RPC service The following example gathers information about the RPC services that are running on a server. The text that is generated by the command is filtered by the sort command to make the output more readable. Several lines that list RPC services have been deleted from the example.% rpcinfo -s bee |sort -n program version(s) netid(s) service owner 100000 2,3,4 udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind superuser 100001 4,3,2 ticlts,udp,udp6 rstatd superuser 100002 3,2 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd superuser 100003 3,2 tcp,udp,tcp6,udp6 nfs superuser 100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd superuser 100007 1,2,3 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind superuser 100008 1 ticlts,udp,udp6 walld superuser 100011 1 ticlts,udp,udp6 rquotad superuser 100012 1 ticlts,udp,udp6 sprayd superuser 100021 4,3,2,1 tcp,udp,tcp6,udp6 nlockmgr superuser 100024 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status superuser 100029 3,2,1 ticots,ticotsord,ticlts keyserv superuser 100068 5 tcp,udp cmsd superuser 100083 1 tcp,tcp6 ttdbserverd superuser 100099 3 ticotsord autofs superuser 100133 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 100134 1 ticotsord tokenring superuser 100155 1 ticots,ticotsord,tcp,tcp6 smserverd superuser 100221 1 tcp,tcp6 - superuser 100227 3,2 tcp,udp,tcp6,udp6 nfs_acl superuser 100229 1 tcp,tcp6 metad superuser 100230 1 tcp,tcp6 metamhd superuser 100231 1 ticots,ticotsord,ticlts - superuser 100234 1 ticotsord gssd superuser 100235 1 tcp,tcp6 - superuser 100242 1 tcp,tcp6 metamedd superuser 100249 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 300326 4 tcp,tcp6 - superuser 300598 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 390113 1 tcp - unknown 805306368 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser 1289637086 1,5 tcp - 26069The following two examples show how to gather information about a particular RPC service by selecting a particular transport on a server. The first example checks the mountd service that is running over TCP. The second example checks the NFS service that is running over UDP.% rpcinfo -t bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting % rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting This command is often used to watch for packets on the network. The snoop command must be run as root. The use of this command is a good way to ensure that the network hardware is functioning on both the client and the server. Many options are available. See the snoop1M man page. A shortened synopsis of the command follows:snoop [ -d device ] [ o filename ] [ host hostname ] d deviceSpecifies the local network interface o filenameStores all the captured packets into the named file hostnameDisplays packets going to and from a specific host only The d device option is useful on those servers that have multiple network interfaces. You can use many expressions other than setting the host. A combination of command expressions with grep can often generate data that is specific enough to be useful.When troubleshooting, make sure that packets are going to and from the proper host. Also, look for error messages. Saving the packets to a file can simplify the review of the data. You can use this command to check if a process is hung. The truss command must be run by the owner of the process or by root. You can use many options with this command. See the truss1 man page. A shortened syntax of the command follows.truss [ -t syscall ] p pidt syscallSelects system calls to trace p pidIndicates the PID of the process to be traced The syscall can be a comma-separated list of system calls to be traced. Also, starting syscall with an ! selects to exclude the listed system calls from the trace.This example shows that the process is waiting for another connection request from a new client. # /usr/bin/truss -p 243 poll(0x00024D50, 2, -1) (sleeping...)The previous example shows a normal response. If the response does not change after a new connection request has been made, the process could be hung. Follow the instructions in How to Restart NFS Services to fix the hung program. Review the instructions in NFS Troubleshooting Procedures to fully verify that your problem is a hung program. Starting in the Solaris 10 release, the default transport for NFS is the Remote Direct Memory Access (RDMA) protocol, which is a technology for memory-to-memory transfer of data over high-speed networks. Specifically, RDMA provides remote data transfer directly to and from memory without CPU intervention. RDMA also provides direct data placement, which eliminates data copies and, therefore, further eliminates CPU intervention. Thus, RDMA relieves not only the host CPU, but also reduces contention for the host memory and I/O buses. To provide this capability, RDMA combines the interconnect I/O technology of InfiniBand on SPARC platforms with the Solaris operating system. The following figure shows the relationship of RDMA to other protocols, such as UDP and TCP.

The context describes the graphic.

Because RDMA is the default transport protocol for NFS, no special share or mount options are required to use RDMA on a client or server. The existing automounter maps, vfstab and dfstab, work with the RDMA transport. NFS mounts over the RDMA transport occur transparently when InfiniBand connectivity exists on SPARC platforms between the client and the server. If the RDMA transport is not available on both the client and the server, the TCP transport is the initial fallback, followed by UDP if TCP is unavailable. Note, however, that if you use the proto=rdma mount option, NFS mounts are forced to use RDMA only.To specify that TCP and UDP be used only, you can use the proto=tcp/udp mount option. This option disables RDMA on an NFS client. For more information about NFS mount options, see the mount_nfs1M man page and mount Command.RDMA for InfiniBand uses the IP addressing format and the IP lookup infrastructure to specify peers. However, because RDMA is a separate protocol stack, it does not fully implement all IP semantics. For example, RDMA does not use IP addressing to communicate with peers. Therefore, RDMA might bypass configurations for various security policies that are based on IP addresses. However, the NFS and RPC administrative policies, such as mount restrictions and secure RPC, are not bypassed. The following sections describe some of the complex functions of the NFS software. Note that some of the feature descriptions in this section are exclusive to NFS version 4.Version Negotiation in NFS Features in NFS Version 4 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 Large Files How NFS Server Logging Works How the WebNFS Service Works WebNFS Limitations With Web Browser Use Secure NFS System Secure RPC If your system has zones enabled and you want to use this feature in a non-global zone, see System Administration Guide: Solaris Containers-Resource Management and Solaris Zones for more information. The NFS initiation process includes negotiating the protocol levels for servers and clients. If you do not specify the version level, then the best level is selected by default. For example, if both the client and the server can support version 3, then version 3 is used. If the client or the server can only support version 2, then version 2 is used.Starting in the Solaris 10 release, you can set the keywords NFS_CLIENT_VERSMIN, NFS_CLIENT_VERSMAX, NFS_SERVER_VERSMIN, NFS_SERVER_VERSMAX in the /etc/default/nfs file. Your specified minimum and maximum values for the server and the client would replace the default values for these keywords. For both the client and the server the default minimum value is 2 and the default maximum value is 4. See Keywords for the /etc/default/nfs File. To find the version supported by the server, the NFS client begins with the setting for NFS_CLIENT_VERSMAX and continues to try each version until reaching the version setting for NFS_CLIENT_VERSMIN. As soon as the supported version is found, the process terminates. For example, if NFS_CLIENT_VERSMAX=4 and NFS_CLIENT_VERSMIN=2, then the client attempts version 4 first, then version 3, and finally version 2. If NFS_CLIENT_VERSMIN and NFS_CLIENT_VERSMAX are set to the same value, then the client always uses this version and does not attempt any other version. If the server does not offer this version, the mount fails.You can override the values that are determined by the negotiation by using the vers option with the mount command. See the mount_nfs1M man page. For procedural information, refer to Setting Up NFS Services. Many changes have been made to NFS in version 4. This section provides descriptions of these new features.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 Client-Side Failover in NFS Version 4 Starting in the Solaris 10 release, NFS version 4 does not support the LIPKEY/SPKM security flavor. Also, NFS version 4 does not use the mountd, nfslogd, and statd daemons. For procedural information related to using NFS version 4, refer to Setting Up NFS Services.With both NFS version 3 and version 4, if a client attempts to access a file system that has been unshared, the server responds with an error code. However, with NFS version 3 the server maintains any locks that the clients had obtained before the file system was unshared. Thus, when the file system is reshared, NFS version 3 clients can access the file system as though that file system had never been unshared.With NFS version 4, when a file system is unshared, all the state for any open files or file locks in that file system is destroyed. If the client attempts to access these files or locks, the client receives an error. This error is usually reported as an I/O error to the application. Note, however, that resharing a currently shared file system to change options does not destroy any of the state on the server.For related information, refer to Client Recovery in NFS Version 4 or see the unshare_nfs1M man page. NFS version 4 servers create and maintain a pseudo-file system, which provides clients with seamless access to all exported objects on the server. Prior to NFS version 4, the pseudo-file system did not exist. Clients were forced to mount each shared server file system for access. Consider the following example.

The context describes the graphic.

Note that the client cannot see the payroll directory and the nfs4x directory, because these directories are not exported and do not lead to exported directories. However, the local directory is visible to the client, because local is an exported directory. The projects directory is visible to the client, because projects leads to the exported directory, nfs4. Thus, portions of the server namespace that are not explicitly exported are bridged with a pseudo-file system that views only the exported directories and those directories that lead to server exports.A pseudo-file system is a structure that contains only directories and is created by the server. The pseudo-file system permits a client to browse the hierarchy of exported file systems. Thus, the client's view of the pseudo-file system is limited to paths that lead to exported file systems.Previous versions of NFS did not permit a client to traverse server file systems without mounting each file system. However, in NFS version 4, the server namespace does the following:Restricts the client's file-system view to directories that lead to server exports. Provides clients with seamless access to server exports without requiring that the client mount each underlying file system. See the previous example. Note, however, that different operating systems might require the client to mount each server file system. For POSIX-related reasons, the Solaris NFS version 4 client does not cross server file-system boundaries. When such attempts are made, the client makes the directory appear to be empty. To remedy this situation, you must perform a mount for each of the server's file systems. File handles are created on the server and contain information that uniquely identifies files and directories. In NFS versions 2 and 3 the server returned persistent file handles. Thus, the client could guarantee that the server would generate a file handle that always referred to the same file. For example:If a file was deleted and replaced with a file of the same name, the server would generate a new file handle for the new file. If the client used the old file handle, the server would return an error that the file handle was stale. If a file was renamed, the file handle would remain the same. If you had to reboot the server, the file handles would remain the same. Thus, when the server received a request from a client that included a file handle, the resolution was straightforward and the file handle always referred to the correct file.This method of identifying files and directories for NFS operations was fine for most UNIX-based servers. However, the method could not be implemented on servers that relied on other methods of identification, such as a file's path name. To resolve this problem, the NFS version 4 protocol permits a server to declare that its file handles are volatile. Thus, a file handle could change. If the file handle does change, the client must find the new file handle.Like NFS versions 2 and 3, the Solaris NFS version 4 server always provides persistent file handles. However, Solaris NFS version 4 clients that access non-Solaris NFS version 4 servers must support volatile file handles if the server uses them. Specifically, when the server tells the client that the file handle is volatile, the client must cache the mapping between path name and file handle. The client uses the volatile file handle until it expires. On expiration, the client does the following:Flushes the cached information that refers to that file handle Searches for that file's new file handle Retries the operation The server always tells the client which file handles are persistent and which file handles are volatile. Volatile file handles might expire for any of these reasons:When you close a file When the filehandle's file system migrates When a client renames a file When the server reboots Note that if the client is unable to find the new file handle, an error message is put in the syslog file. Further attempts to access this file fail with an I/O error. The NFS version 4 protocol is a stateful protocol. A protocol is stateful when both the client and the server maintain current information about the following.Open files File locks When a failure occurs, such as a server crash, the client and the server work together to reestablish the open and lock states that existed prior to the failure.When a server crashes and is rebooted, the server loses its state. The client detects that the server has rebooted and begins the process of helping the server rebuild its state. This process is known as client recovery, because the client directs the process.When the client discovers that the server has rebooted, the client immediately suspends its current activity and begins the process of client recovery. When the recovery process starts, a message, such as the following, is displayed in the system error log /var/adm/messages.NOTICE: Starting recovery server basil.example.company.comDuring the recovery process, the client sends the server information about the client's previous state. Note, however, that during this period the client does not send any new requests to the server. Any new requests to open files or set file locks must wait for the server to complete its recovery period before proceeding.When the client recovery process is complete, the following message is displayed in the system error log /var/adm/messages.NOTICE: Recovery done for server basil.example.company.comNow the client has successfully completed sending its state information to the server. However, even though the client has completed this process, other clients might not have completed their process of sending state information to the server. Therefore, for a period of time, the server does not accept any open or lock requests. This period of time, which is known as the grace period, is designated to permit all the clients to complete their recovery.During the grace period, if the client attempts to open any new files or establish any new locks, the server denies the request with the GRACE error code. On receiving this error, the client must wait for the grace period to end and then resend the request to the server. During the grace period the following message is displayed.NFS server recoveringNote that during the grace period the commands that do not open files or set file locks can proceed. For example, the commands ls and cd do not open a file or set a file lock. Thus, these commands are not suspended. However, a command such as cat, which opens a file, would be suspended until the grace period ends.When the grace period has ended, the following message is displayed.NFS server recovery ok.The client can now send new open and lock requests to the server.Client recovery can fail for a variety of reasons. For example, if a network partition exists after the server reboots, the client might not be able to reestablish its state with the server before the grace period ends. When the grace period has ended, the server does not permit the client to reestablish its state because new state operations could create conflicts. For example, a new file lock might conflict with an old file lock that the client is trying to recover. When such situations occur, the server returns the NO_GRACE error code to the client.If the recovery of an open operation for a particular file fails, the client marks the file as unusable and the following message is displayed.WARNING: The following NFS file could not be recovered and was marked dead (can't reopen: NFS status 70): file : filenameNote that the number 70 is only an example.If reestablishing a file lock during recovery fails, the following error message is posted.NOTICE: nfs4_send_siglost: pid PROCESS-ID lost lock on server SERVER-NAMEIn this situation, the SIGLOST signal is posted to the process. The default action for the SIGLOST signal is to terminate the process.For you to recover from this state, you must restart any applications that had files open at the time of the failure. Note that the following can occur.Some processes that did not reopen the file could receive I/O errors. Other processes that did reopen the file, or performed the open operation after the recovery failure, are able to access the file without any problems. Thus, some processes can access a particular file while other processes cannot. The NFS version 4 protocol provides several file-sharing modes that the client can use to control file access by other clients. A client can specify the following:DENY_NONE mode permits other clients read and write access to a file. DENY_READ mode denies other clients read access to a file. DENY_WRITE mode denies other clients write access to a file. DENY_BOTH mode denies other clients read and write access to a file. The Solaris NFS version 4 server fully implements these file-sharing modes. Therefore, if a client attempts to open a file in a way that conflicts with the current share mode, the server denies the attempt by failing the operation. When such attempts fail with the initiation of the open or create operations, the Solaris NFS version 4 client receives a protocol error. This error is mapped to the application error EACCES.Even though the protocol provides several sharing modes, currently the open operation in Solaris does not offer multiple sharing modes. When opening a file, a Solaris NFS version 4 client can only use the DENY_NONE mode.Also, even though the Solaris fcntl system call has an F_SHARE command to control file sharing, the fcntl commands cannot be implemented correctly with NFS version 4. If you use these fcntl commands on an NFS version 4 client, the client returns the EAGAIN error to the application. NFS version 4 provides both client support and server support for delegation. Delegation is a technique by which the server delegates the management of a file to a client. For example, the server could grant either a read delegation or a write delegation to a client. Read delegations can be granted to multiple clients at the same time, because these read delegations do not conflict with each other. A write delegation can be granted to only one client, because a write delegation conflicts with any file access by any other client. While holding a write delegation, the client would not send various operations to the server because the client is guaranteed exclusive access to a file. Similarly, the client would not send various operations to the server while holding a read delegation. The reason is that the server guarantees that no client can open the file in write mode. The effect of delegation is to greatly reduce the interactions between the server and the client for delegated files. Therefore, network traffic is reduced, and performance on the client and the server is improved. Note, however, that the degree of performance improvement depends on the kind of file interaction used by an application and the amount of network and server congestion.The decision about whether to grant a delegation is made entirely by the server. A client does not request a delegation. The server makes decisions about whether to grant a delegation, based on the access patterns for the file. If a file has been recently accessed in write mode by several different clients, the server might not grant a delegation. The reason is that this access pattern indicates the potential for future conflicts.A conflict occurs when a client accesses a file in a manner that is inconsistent with the delegations that are currently granted for that file. For example, if a client holds a write delegation on a file and a second client opens that file for read or write access, the server recalls the first client's write delegation. Similarly, if a client holds a read delegation and another client opens the same file for writing, the server recalls the read delegation. Note that in both situations, the second client is not granted a delegation because a conflict now exists. When a conflict occurs, the server uses a callback mechanism to contact the client that currently holds the delegation. On receiving this callback, the client sends the file's updated state to the server and returns the delegation. If the client fails to respond to the recall, the server revokes the delegation. In such instances, the server rejects all operations from the client for this file, and the client reports the requested operations as failures. Generally, these failures are reported to the application as I/O errors. To recover from these errors, the file must be closed and then reopened. Failures from revoked delegations can occur when a network partition exists between the client and the server while the client holds a delegation.Note that one server does not resolve access conflicts for a file that is stored on another server. Thus, an NFS server only resolves conflicts for files that it stores. Furthermore, in response to conflicts that are caused by clients that are running various versions of NFS, an NFS server can only initiate recalls to the client that is running NFS version 4. An NFS server cannot initiate recalls for clients that are running earlier versions of NFS.The process for detecting conflicts varies. For example, unlike NFS version 4, because version 2 and version 3 do not have an open procedure, the conflict is detected only after the client attempts to read, write, or lock a file. The server's response to these conflicts varies also. For example:For NFS version 3, the server returns the JUKEBOX error, which causes the client to halt the access request and try again later. The client prints the message File unavailable. For NFS version 2, because an equivalent of the JUKEBOX error does not exist, the server makes no response, which causes the client to wait and then try again. The client prints the message NFS server not responding. These conditions clear when the delegation conflict has been resolved.By default, server delegation is enabled. You can disable delegation by modifying the /etc/default/nfs file. For procedural information, refer to How to Select Different Versions of NFS on a Server.No keywords are required for client delegation. The NFS version 4 callback daemon, nfs4cbd, provides the callback service on the client. This daemon is started automatically whenever a mount for NFS version 4 is enabled. By default, the client provides the necessary callback information to the server for all Internet transports that are listed in the /etc/netconfig system file. Note that if the client is enabled for IPv6 and if the IPv6 address for the client's name can be determined, then the callback daemon accepts IPv6 connections.The callback daemon uses a transient program number and a dynamically assigned port number. This information is provided to the server, and the server tests the callback path before granting any delegations. If the callback path does not test successfully, the server does not grant delegations, which is the only externally visible behavior.Note that because callback information is embedded within an NFS version 4 request, the server is unable to contact the client through a device that uses Network Address Translation (NAT). Also, the callback daemon uses a dynamic port number. Therefore, the server might not be able to traverse a firewall, even if that firewall enables normal NFS traffic on port 2049. In such situations, the server does not grant delegations. An access control list (ACL) provides better file security by enabling the owner of a file to define file permissions for the file owner, the group, and other specific users and groups. ACLs are set on the server and the client by using the setfacl command. See the setfacl1 man page. In NFS version 4, the ID mapper, nfsmapid, is used to map user or group IDs in ACL entries on a server to user or group IDs in ACL entries on a client. The reverse is also true. The user and group IDs in the ACL entries must exist on both the client and the server.The following situations can cause ID mapping to fail:If the user or group that exists in an ACL entry on the server cannot be mapped to a valid user or group on the client, the user is not allowed to read the ACL on the client.For example, when you issue the ls l command, you receive the error message, Permission denied, for the files with user or group ID ACL entities that cannot be mapped from the server to the client. The ID mapper was unable to map a user or group in the ACL. If the ID mapper had been able to map the user or group, a plus (+) sign would have appeared after the permissions in the files list that is produced by ls l. For example:% ls -l -rw-r--rw-+ 1 luis staff 11968 Aug 12 2005 foobarSimilarly, the getfacl command can return the Permission denied error message for the same reason. For more information about this command, see the getfacl1 man page. If the user or group ID in any ACL entry that is set on the client cannot be mapped to a valid user or group ID on the server, the setfacl command can fail and return the Permission denied error message. If the client and server have mismatched NFSMAPID_DOMAIN values, ID mapping fails. For more information, see Keywords for the /etc/default/nfs File. To avoid ID mapping problems, do the following:Make sure that the value for NFSMAPID_DOMAIN is set correctly in the /etc/default/nfs file. Make sure that all user and group IDs in the ACL entries exist on both the NFS version 4 client and server. To determine if any user or group cannot be mapped on the server or client, use the following script:#! /usr/sbin/dtrace -Fs sdt:::nfs4-acl-nobody { printf("validate_idmapping: (%s) in the ACL could not be mapped!", stringof(arg0)); }The probe name that is used in this script is an interface that could change in the future. For more information, see Stability Levels in Solaris Dynamic Tracing Guide. See the following:Protecting Files With ACLs (Task Map) in System Administration Guide: Security Services nfsmapid Daemon During initiation, the transport protocol is also negotiated. By default, the first connection-oriented transport that is supported on both the client and the server is selected. If this selection does not succeed, the first available connectionless transport protocol is used. The transport protocols that are supported on a system are listed in /etc/netconfig. TCP is the connection-oriented transport protocol that is supported by the release. UDP is the connectionless transport protocol.When both the NFS protocol version and the transport protocol are determined by negotiation, the NFS protocol version is given precedence over the transport protocol. The NFS version 3 protocol that uses UDP is given higher precedence than the NFS version 2 protocol that is using TCP. You can manually select both the NFS protocol version and the transport protocol with the mount command. See the mount_nfs1M man page. Under most conditions, allow the negotiation to select the best options. The file transfer size establishes the size of the buffers that are used when transferring data between the client and the server. In general, larger transfer sizes are better. The NFS version 3 protocol has an unlimited transfer size. However, starting with the Solaris 2.6 release, the software bids a default buffer size of 32 Kbytes. The client can bid a smaller transfer size at mount time if needed, but under most conditions this bid is not necessary.The transfer size is not negotiated with systems that use the NFS version 2 protocol. Under this condition, the maximum transfer size is set to 8 Kbytes.You can use the rsize and wsize options to set the transfer size manually with the mount command. You might need to reduce the transfer size for some PC clients. Also, you can increase the transfer size if the NFS server is configured to use larger transfer sizes.Starting in the Solaris 10 release, restrictions on wire transfer sizes have been relaxed. The transfer size is based on the capabilities of the underlying transport. For example, the NFS transfer limit for UDP is still 32 Kbytes. However, because TCP is a streaming protocol without the datagram limits of UDP, maximum transfer sizes over TCP have been increased to 1 Mbyte. The following description applies to NFS version 3 mounts. The NFS version 4 mount process does not include the portmap service nor does it include the MOUNT protocol.When a client needs to mount a file system from a server, the client must obtain a file handle from the server. The file handle must correspond to the file system. This process requires that several transactions occur between the client and the server. In this example, the client is attempting to mount /home/terry from the server. A snoop trace for this transaction follows.client -> server PORTMAP C GETPORT prog=100005 (MOUNT) vers=3 proto=UDP server -> client PORTMAP R GETPORT port=33492 client -> server MOUNT3 C Null server -> client MOUNT3 R Null client -> server MOUNT3 C Mount /export/home9/terry server -> client MOUNT3 R Mount OK FH=9000 Auth=unix client -> server PORTMAP C GETPORT prog=100003 (NFS) vers=3 proto=TCP server -> client PORTMAP R GETPORT port=2049 client -> server NFS C NULL3 server -> client NFS R NULL3 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OKIn this trace, the client first requests the mount port number from the portmap service on the NFS server. After the client receives the mount port number (33492), that number is used to test the availability of the service on the server. After the client has determined that a service is running on that port number, the client then makes a mount request. When the server responds to this request, the server includes the file handle for the file system (9000) being mounted. The client then sends a request for the NFS port number. When the client receives the number from the server, the client tests the availability of the NFS service (nfsd). Also, the client requests NFS information about the file system that uses the file handle.In the following trace, the client is mounting the file system with the public option.client -> server NFS C LOOKUP3 FH=0000 /export/home9/terry server -> client NFS R LOOKUP3 OK FH=9000 client -> server NFS C FSINFO3 FH=9000 server -> client NFS R FSINFO3 OK client -> server NFS C GETATTR3 FH=9000 server -> client NFS R GETATTR3 OKBy using the default public file handle (which is 0000), all the transactions to obtain information from the portmap service and to determine the NFS port number are skipped.NFS version 4 provides support for volatile file handles. For more information, refer to Volatile File Handles in NFS Version 4. Using the public option can create conditions that cause a mount to fail. Adding an NFS URL can also confuse the situation. The following list describes the specifics of how a file system is mounted when you use these options.Public option with NFS URL – Forces the use of the public file handle. The mount fails if the public file handle is not supported. Public option with regular path – Forces the use of the public file handle. The mount fails if the public file handle is not supported. NFS URL only – Use the public file handle if this file handle is enabled on the NFS server. If the mount fails when using the public file handle, then try the mount with the MOUNT protocol. Regular path only – Do not use the public file handle. The MOUNT protocol is used. By using client-side failover, an NFS client can be aware of multiple servers that are making the same data available and can switch to an alternate server when the current server is unavailable. The file system can become unavailable if one of the following occurs. If the file system is connected to a server that crashes If the server is overloaded If a network fault occurs The failover, under these conditions, is normally transparent to the user. Thus, the failover can occur at any time without disrupting the processes that are running on the client.Failover requires that the file system be mounted read-only. The file systems must be identical for the failover to occur successfully. See What Is a Replicated File System? for a description of what makes a file system identical. A static file system or a file system that is not changed often is the best candidate for failover. You cannot use CacheFS and client-side failover on the same NFS mount. Extra information is stored for each CacheFS file system. This information cannot be updated during failover, so only one of these two features can be used when mounting a file system.The number of replicas that need to be established for every file system depends on many factors. Ideally, you should have a minimum of two servers. Each server should support multiple subnets. This setup is better than having a unique server on each subnet. The process requires that each listed server be checked. Therefore, if more servers are listed, each mount is slower.To fully comprehend the process, you need to understand two terms.failover – The process of selecting a server from a list of servers that support a replicated file system. Normally, the next server in the sorted list is used, unless it fails to respond. remap – To use a new server. Through normal use, the clients store the path name for each active file on the remote file system. During the remap, these path names are evaluated to locate the files on the new server. For the purposes of failover, a file system can be called a replica when each file is the same size and has the same file size or file type as the original file system. Permissions, creation dates, and other file attributes are not considered. If the file size or file types are different, the remap fails and the process hangs until the old server becomes available. In NFS version 4, the behavior is different. See Client-Side Failover in NFS Version 4.You can maintain a replicated file system by using rdist, cpio, or another file transfer mechanism. Because updating the replicated file systems causes inconsistency, for best results consider these precautions:Renaming the old version of the file before installing a new version of the file Running the updates at night when client usage is low Keeping the updates small Minimizing the number of copies Some software packages require read locks on files. To prevent these products from breaking, read locks on read-only file systems are allowed but are visible to the client side only. The locks persist through a remap because the server does not “know” about the locks. Because the files should not change, you do not need to lock the file on the server side. In NFS version 4, if a replica cannot be established because the file sizes are different or the file types are not the same, then the following happens.The file is marked dead. A warning is printed. The application receives a system call failure. If you restart the application and try again to access the file, you should be successful. In NFS version 4, you no longer receive replication errors for directories of different sizes. In prior versions of NFS, this condition was treated as an error and would impede the remapping process.Furthermore, in NFS version 4, if a directory read operation is unsuccessful, the operation is performed by the next listed server. In previous versions of NFS, unsuccessful read operations would cause the remap to fail and the process to hang until the original server was available. Starting with the Solaris 2.6 release, the Solaris OS supports files that are over 2 Gbytes. By default, UFS file systems are mounted with the largefiles option to support the new capability. Previous releases cannot handle files of this size. See How to Disable Large Files on an NFS Server for instructions.If the server's file system is mounted with the largefiles option, a Solaris 2.6 NFS client can access large files without the need for changes. However, not all Solaris 2.6 commands can handle these large files. See largefile5 for a list of the commands that can handle the large files. Clients that cannot support the NFS version 3 protocol with the large file extensions cannot access any large files. Although clients that run the Solaris 2.5 release can use the NFS version 3 protocol, large file support was not included in that release. NFS server logging provides records of NFS reads and writes, as well as operations that modify the file system. This data can be used to track access to information. In addition, the records can provide a quantitative way to measure interest in the information.When a file system with logging enabled is accessed, the kernel writes raw data into a buffer file. This data includes the following:A timestamp The client IP address The UID of the requester The file handle of the file or directory object that is being accessed The type of operation that occurred The nfslogd daemon converts this raw data into ASCII records that are stored in log files. During the conversion, the IP addresses are modified to host names and the UIDs are modified to logins if the name service that is enabled can find matches. The file handles are also converted into path names. To accomplish the conversion, the daemon tracks the file handles and stores information in a separate file handle-to-path table. That way, the path does not have to be identified again each time a file handle is accessed. Because no changes to the mappings are made in the file handle-to-path table if nfslogd is turned off, you must keep the daemon running.Server logging is not supported in NFS version 4. The WebNFS service makes files in a directory available to clients by using a public file handle. A file handle is an address that is generated by the kernel that identifies a file for NFS clients. The public file handle has a predefined value, so the server does not need to generate a file handle for the client. The ability to use this predefined file handle reduces network traffic by eliminating the MOUNT protocol. This ability should also accelerate processes for the clients.By default, the public file handle on an NFS server is established on the root file system. This default provides WebNFS access to any clients that already have mount privileges on the server. You can change the public file handle to point to any file system by using the share command.When the client has the file handle for the file system, a LOOKUP is run to determine the file handle for the file to be accessed. The NFS protocol allows the evaluation of only one path name component at a time. Each additional level of directory hierarchy requires another LOOKUP. A WebNFS server can evaluate an entire path name with a single multi-component lookup transaction when the LOOKUP is relative to the public file handle. Multi-component lookup enables the WebNFS server to deliver the file handle to the desired file without exchanging the file handles for each directory level in the path name.In addition, an NFS client can initiate concurrent downloads over a single TCP connection. This connection provides quick access without the additional load on the server that is caused by setting up multiple connections. Although web browser applications support concurrent downloading of multiple files, each file has its own connection. By using one connection, the WebNFS software reduces the overhead on the server.If the final component in the path name is a symbolic link to another file system, the client can access the file if the client already has access through normal NFS activities.Normally, an NFS URL is evaluated relative to the public file handle. The evaluation can be changed to be relative to the server's root file system by adding an additional slash to the beginning of the path. In this example, these two NFS URLs are equivalent if the public file handle has been established on the /export/ftp file system.nfs://server/junk nfs://server//export/ftp/junkThe NFS version 4 protocol is preferred over the WebNFS service. NFS version 4 fully integrates all the security negotiation that was added to the MOUNT protocol and the WebNFS service. The Solaris 8 release includes a new protocol that enables a WebNFS client to negotiate a selected security mechanism with a WebNFS server. The new protocol uses security negotiation multi-component lookup, which is an extension to the multi-component lookup that was used in earlier versions of the WebNFS protocol.The WebNFS client initiates the process by making a regular multi–component lookup request by using the public file handle. Because the client has no knowledge of how the path is protected by the server, the default security mechanism is used. If the default security mechanism is not sufficient, the server replies with an AUTH_TOOWEAK error. This reply indicates that the default mechanism is not valid. The client needs to use a stronger default mechanism.When the client receives the AUTH_TOOWEAK error, the client sends a request to the server to determine which security mechanisms are required. If the request succeeds, the server responds with an array of security mechanisms that are required for the specified path. Depending on the size of the array of security mechanisms, the client might have to make more requests to obtain the complete array. If the server does not support WebNFS security negotiation, the request fails.After a successful request, the WebNFS client selects the first security mechanism from the array that the client supports. The client then issues a regular multi-component lookup request by using the selected security mechanism to acquire the file handle. All subsequent NFS requests are made by using the selected security mechanism and the file handle.The NFS version 4 protocol is preferred over the WebNFS service. NFS version 4 fully integrates all the security negotiation that was added to the MOUNT protocol and the WebNFS service. Several functions that a web site that uses HTTP can provide are not supported by the WebNFS software. These differences stem from the fact that the NFS server only sends the file, so any special processing must be done on the client. If you need to have one web site configured for both WebNFS and HTTP access, consider the following issues:NFS browsing does not run CGI scripts. So, a file system with an active web site that uses many CGI scripts might not be appropriate for NFS browsing. The browser might start different viewers to handle files in different file formats. Accessing these files through an NFS URL starts an external viewer if the file type can be determined by the file name. The browser should recognize any file name extension for a standard MIME type when an NFS URL is used. The WebNFS software does not check inside the file to determine the file type. So, the only way to determine a file type is by the file name extension. NFS browsing cannot utilize server-side image maps (clickable images). However, NFS browsing can utilize client-side image maps (clickable images) because the URLs are defined with the location. No additional response is required from the document server. The NFS environment is a powerful way and convenient way to share file systems on a network of different computer architectures and operating systems. However, the same features that make sharing file systems through NFS operation convenient also pose some security problems. Historically, most NFS implementations have used UNIX (or AUTH_SYS) authentication, but stronger authentication methods such as AUTH_DH have also been available. When using UNIX authentication, an NFS server authenticates a file request by authenticating the computer that makes the request, but not the user. Therefore, a client user can run su and impersonate the owner of a file. If DH authentication is used, the NFS server authenticates the user, making this sort of impersonation much harder.With root access and knowledge of network programming, anyone can introduce arbitrary data into the network and extract any data from the network. The most dangerous attacks are those attacks that involve the introduction of data. An example is the impersonation of a user by generating the right packets or by recording “conversations” and replaying them later. These attacks affect data integrity. Attacks that involve passive eavesdropping, which is merely listening to network traffic without impersonating anybody, are not as dangerous, because data integrity is not compromised. Users can protect the privacy of sensitive information by encrypting data that is sent over the network. A common approach to network security problems is to leave the solution to each application. A better approach is to implement a standard authentication system at a level that covers all applications. The Solaris operating system includes an authentication system at the level of the remote procedure call (RPC), which is the mechanism on which the NFS operation is built. This system, known as Secure RPC, greatly improves the security of network environments and provides additional security to services such as the NFS system. When the NFS system uses the facilities that are provided by Secure RPC, it is known as a Secure NFS system. Secure RPC is fundamental to the Secure NFS system. The goal of Secure RPC is to build a system that is at minimum as secure as a time-sharing system. In a time-sharing system all users share a single computer. A time-sharing system authenticates a user through a login password. With Data Encryption Standard (DES) authentication, the same authentication process is completed. Users can log in on any remote computer just as users can log in on a local terminal. The users' login passwords are their assurance of network security. In a time-sharing environment, the system administrator has an ethical obligation not to change a password to impersonate someone. In Secure RPC, the network administrator is trusted not to alter entries in a database that stores public keys.You need to be familiar with two terms to understand an RPC authentication system: credentials and verifiers. Using ID badges as an example, the credential is what identifies a person: a name, address, and birthday. The verifier is the photo that is attached to the badge. You can be sure that the badge has not been stolen by checking the photo on the badge against the person who is carrying the badge. In RPC, the client process sends both a credential and a verifier to the server with each RPC request. The server sends back only a verifier because the client already “knows” the server's credentials. RPC's authentication is open ended, which means that a variety of authentication systems can be plugged into it, such as UNIX, DH, and KERB. When UNIX authentication is used by a network service, the credentials contain the client's host name, UID, GID, and group-access list. However, the verifier contains nothing. Because no verifier exists, a superuser could falsify appropriate credentials by using commands such as su. Another problem with UNIX authentication is that UNIX authentication assumes all computers on a network are UNIX computers. UNIX authentication breaks down when applied to other operating systems in a heterogeneous network. To overcome the problems of UNIX authentication, Secure RPC uses DH authentication. DH authentication uses the Data Encryption Standard (DES) and Diffie-Hellman public-key cryptography to authenticate both users and computers in the network. DES is a standard encryption mechanism. Diffie-Hellman public-key cryptography is a cipher system that involves two keys: one public and one secret. The public keys and secret keys are stored in the namespace. NIS stores the keys in the public-key map. These maps contain the public key and secret key for all potential users. See the System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) for more information about how to set up the maps. The security of DH authentication is based on a sender's ability to encrypt the current time, which the receiver can then decrypt and check against its own clock. The timestamp is encrypted with DES. The requirements for this scheme to work are as follows:The two agents must agree on the current time. The sender and receiver must be using the same encryption key. If a network runs a time-synchronization program, the time on the client and the server is synchronized automatically. If a time-synchronization program is not available, timestamps can be computed by using the server's time instead of the network time. The client asks the server for the time before starting the RPC session, then computes the time difference between its own clock and the server's. This difference is used to offset the client's clock when computing timestamps. If the client and server clocks become unsynchronized the server begins to reject the client's requests. The DH authentication system on the client resynchronizes with the server. The client and server arrive at the same encryption key by generating a random conversation key, also known as the session key, and by using public-key cryptography to deduce a common key. The common key is a key that only the client and server are capable of deducing. The conversation key is used to encrypt and decrypt the client's timestamp. The common key is used to encrypt and decrypt the conversation key. Kerberos is an authentication system that was developed at MIT. Kerberos offers a variety of encryption types, including DES. Kerberos support is no longer supplied as part of Secure RPC, but starting in the Solaris 9 release a server-side and client-side implementation is included. See Chapter 20, Introduction to the Kerberos Service, in System Administration Guide: Security Services for more information about the implementation of Kerberos authentication. Be aware of the following points if you plan to use Secure RPC: If a server crashes when no one is around (after a power failure, for example), all the secret keys that are stored on the system are deleted. Now no process can access secure network services or mount an NFS file system. The important processes during a reboot are usually run as root. Therefore, these processes would work if root's secret key were stored away, but nobody is available to type the password that decrypts it. keylogin -r allows root to store the clear secret key in /etc/.rootkey, which keyserv reads. Some systems boot in single-user mode, with a root login shell on the console and no password prompt. Physical security is imperative in such cases. Diskless computer booting is not totally secure. Somebody could impersonate the boot server and boot a devious kernel that, for example, makes a record of your secret key on a remote computer. The Secure NFS system provides protection only after the kernel and the key server are running. Otherwise, no way exists to authenticate the replies that are given by the boot server. This limitation could be a serious problem, but the limitation requires a sophisticated attack, using kernel source code. Also, the crime would leave evidence. If you polled the network for boot servers, you would discover the devious boot server's location. Most setuid programs are owned by root. If the secret key for root is stored in /etc/.rootkey, these programs behave as they always have. If a setuid program is owned by a user, however, the setuid program might not always work. For example, suppose that a setuid program is owned by dave and dave has not logged into the computer since it booted. The program would not be able to access secure network services. If you log in to a remote computer (using login, rlogin, or telnet) and use keylogin to gain access, you give access to your account. The reason is that your secret key is passed to that computer's key server, which then stores your secret key. This process is only a concern if you do not trust the remote computer. If you have doubts, however, do not log in to a remote computer if the remote computer requires a password. Instead, use the NFS environment to mount file systems that are shared by the remote computer. As an alternative, you can use keylogout to delete the secret key from the key server. If a home directory is shared with the o sec=dh option, remote logins can be a problem. If the /etc/hosts.equiv or ~/.rhosts files are not set to prompt for a password, the login succeeds. However, the users cannot access their home directories because no authentication has occurred locally. If the user is prompted for a password, the user has access to his or her home directory if the password matches the network password. Autofs uses three types of maps:Master map Direct maps Indirect maps The auto_master map associates a directory with a map. The map is a master list that specifies all the maps that autofs should check. The following example shows what an auto_master file could contain. # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /- auto_direct -ro This example shows the generic auto_master file with one addition for the auto_direct map. Each line in the master map /etc/auto_master has the following syntax: mount-point map-name [ mount-options ]mount-pointmount-point is the full (absolute) path name of a directory. If the directory does not exist, autofs creates the directory if possible. If the directory exists and is not empty, mounting on the directory hides its contents. In this situation, autofs issues a warning.The notation /- as a mount point indicates that this particular map is a direct map. The notation also means that no particular mount point is associated with the map. map-namemap-name is the map autofs uses to find directions to locations, or mount information. If the name is preceded by a slash (/), autofs interprets the name as a local file. Otherwise, autofs searches for the mount information by using the search that is specified in the name-service switch configuration file (/etc/nsswitch.conf). Special maps are also used for /net. See Mount Point /net for more information. mount-optionsmount-options is an optional, comma-separated list of options that apply to the mounting of the entries that are specified in map-name, unless the entries in map-name list other options. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_nfs1M man page for NFS-specific mount options. For NFS-specific mount points, the bg (background) and fg (foreground) options do not apply. A line that begins with # is a comment. All the text that follows until the end of the line is ignored. To split long lines into shorter ones, put a backslash (\) at the end of the line. The maximum number of characters of an entry is 1024. If the same mount point is used in two entries, the first entry is used by the automount command. The second entry is ignored. The mount point /home is the directory under which the entries that are listed in /etc/auto_home (an indirect map) are to be mounted. Autofs runs on all computers and supports /net and /home (automounted home directories) by default. These defaults can be overridden by entries in the NIS auto.master map or NIS+ auto_master table, or by local editing of the /etc/auto_master file. Autofs mounts under the directory /net all the entries in the special map -hosts. The map is a built-in map that uses only the hosts database. Suppose that the computer gumbo is in the hosts database and it exports any of its file systems. The following command changes the current directory to the root directory of the computer gumbo.% cd /net/gumboAutofs can mount only the exported file systems of host gumbo, that is, those file systems on a server that are available to network users instead of those file systems on a local disk. Therefore, all the files and directories on gumbo might not be available through /net/gumbo. With the /net method of access, the server name is in the path and is location dependent. If you want to move an exported file system from one server to another, the path might no longer work. Instead, you should set up an entry in a map specifically for the file system you want rather than use /net. Autofs checks the server's export list only at mount time. After a server's file systems are mounted, autofs does not check with the server again until the server's file systems are automatically unmounted. Therefore, newly exported file systems are not “seen” until the file systems on the client are unmounted and then remounted. A direct map is an automount point. With a direct map, a direct association exists between a mount point on the client and a directory on the server. Direct maps have a full path name and indicate the relationship explicitly. The following is a typical /etc/auto_direct map: /usr/local -ro \ /bin ivy:/export/local/sun4 \ /share ivy:/export/local/share \ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news Lines in direct maps have the following syntax: key [ mount-options ] locationkeykey is the path name of the mount point in a direct map. mount-optionsmount-options is the options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_cachefs1M man page for CacheFS specific mount options. For information about using CacheFS options with different versions of NFS, see Accessing NFS File Systems Using CacheFS. locationlocation is the location of the file system. One or more file systems are specified as server:pathname for NFS file systems or :devicename for High Sierra file systems (HSFS). The pathname should not include an automounted mount point. The pathname should be the actual absolute path to the file system. For instance, the location of a home directory should be listed as server:/export/home/username, not as server:/home/username. As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash at the end of the line to split long lines into shorter ones. Of all the maps, the entries in a direct map most closely resemble the corresponding entries in /etc/vfstab. An entry might appear in /etc/vfstab as follows: dancer:/usr/local - /usr/local/tmp nfs - yes ro The equivalent entry appears in a direct map as follows: /usr/local/tmp -ro dancer:/usr/localNo concatenation of options occurs between the automounter maps. Any options that are added to an automounter map override all options that are listed in maps that are searched earlier. For instance, options that are included in the auto_master map would be overridden by corresponding entries in any other map. See How Autofs Selects the Nearest Read-Only Files for Clients (Multiple Locations) for other important features that are associated with this type of map. In Example 6–3, the mount point /- tells autofs not to associate the entries in auto_direct with any specific mount point. Indirect maps use mount points that are defined in the auto_master file. Direct maps use mount points that are specified in the named map. Remember, in a direct map the key, or mount point, is a full path name. An NIS or NIS+ auto_master file can have only one direct map entry because the mount point must be a unique value in the namespace. An auto_master file that is a local file can have any number of direct map entries if entries are not duplicated. An indirect map uses a substitution value of a key to establish the association between a mount point on the client and a directory on the server. Indirect maps are useful for accessing specific file systems, such as home directories. The auto_home map is an example of an indirect map. Lines in indirect maps have the following general syntax: key [ mount-options ] locationkeykey is a simple name without slashes in an indirect map. mount-optionsmount-options is the options that you want to apply to this particular mount. These options are required only if the options differ from the map default. Options for each specific type of file system are listed in the mount man page for that file system. For example, see the mount_nfs1M man page for NFS-specific mount options. locationlocation is the location of the file system. One or more file systems are specified as server:pathname. The pathname should not include an automounted mount point. The pathname should be the actual absolute path to the file system. For instance, the location of a directory should be listed as server:/usr/local, not as server:/net/server/usr/local. As in the master map, a line that begins with # is a comment. All the text that follows until the end of the line is ignored. Put a backslash (\) at the end of the line to split long lines into shorter ones. Example 6–3 shows an auto_master map that contains the following entry: /home auto_home -nobrowse auto_home is the name of the indirect map that contains the entries to be mounted under /home. A typical auto_home map might contain the following: david willow:/export/home/david rob cypress:/export/home/rob gordon poplar:/export/home/gordon rajan pine:/export/home/rajan tammy apple:/export/home/tammy jim ivy:/export/home/jim linda -rw,nosuid peach:/export/home/lindaAs an example, assume that the previous map is on host oak. Suppose that the user linda has an entry in the password database that specifies her home directory as /home/linda. Whenever linda logs in to computer oak, autofs mounts the directory /export/home/linda that resides on the computer peach. Her home directory is mounted read-write, nosuid. Assume the following conditions occur: User linda's home directory is listed in the password database as /home/linda. Anybody, including Linda, has access to this path from any computer that is set up with the master map referring to the map in the previous example.Under these conditions, user linda can run login or rlogin on any of these computers and have her home directory mounted in place for her. Furthermore, now Linda can also type the following command: % cd ~davidautofs mounts David's home directory for her (if all permissions allow).No concatenation of options occurs between the automounter maps. Any options that are added to an automounter map override all options that are listed in maps that are searched earlier. For instance, options that are included in the auto_master map are overridden by corresponding entries in any other map. On a network without a name service, you have to change all the relevant files (such as /etc/passwd) on all systems on the network to allow Linda access to her files. With NIS, make the changes on the NIS master server and propagate the relevant databases to the slave servers. On a network that is running NIS+, propagating the relevant databases to the slave servers is done automatically after the changes are made. Autofs is a client-side service that automatically mounts the appropriate file system. The components that work together to accomplish automatic mounting are the following:The automount command The autofs file system The automountd daemon The automount service, svc:/system/filesystem/autofs, which is called at system startup time, reads the master map file auto_master to create the initial set of autofs mounts. These autofs mounts are not automatically mounted at startup time. These mounts are points under which file systems are mounted in the future. These points are also known as trigger nodes.After the autofs mounts are set up, these mounts can trigger file systems to be mounted under them. For example, when autofs receives a request to access a file system that is not currently mounted, autofs calls automountd, which actually mounts the requested file system. After initially mounting autofs mounts, the automount command is used to update autofs mounts as necessary. The command compares the list of mounts in the auto_master map with the list of mounted file systems in the mount table file /etc/mnttab (formerly /etc/mtab). automount then makes the appropriate changes. This process allows system administrators to change mount information within auto_master and have those changes used by the autofs processes without stopping and restarting the autofs daemon. After the file system is mounted, further access does not require any action from automountd until the file system is automatically unmounted. Unlike mount, automount does not read the /etc/vfstab file (which is specific to each computer) for a list of file systems to mount. The automount command is controlled within a domain and on computers through the namespace or local files. The following is a simplified overview of how autofs works. The automount daemon automountd is started at boot time by the service svc:/system/filesystem/autofs. See Figure 6–3. This service also runs the automount command, which reads the master map and installs autofs mount points. See How Autofs Starts the Navigation Process (Master Map) for more information.

The context describes the graphic.

Autofs is a kernel file system that supports automatic mounting and unmounting. When a request is made to access a file system at an autofs mount point, the following occurs:Autofs intercepts the request. Autofs sends a message to the automountd for the requested file system to be mounted. automountd locates the file system information in a map, creates the trigger nodes, and performs the mount. Autofs allows the intercepted request to proceed. Autofs unmounts the file system after a period of inactivity. Mounts that are managed through the autofs service should not be manually mounted or unmounted. Even if the operation is successful, the autofs service does not check that the object has been unmounted, resulting in possible inconsistencies. A reboot clears all the autofs mount points. Autofs searches a series of maps to navigate through the network. Maps are files that contain information such as the password entries of all users on a network or the names of all host computers on a network. Effectively, the maps contain network-wide equivalents of UNIX administration files. Maps are available locally or through a network name service such as NIS or NIS+. You create maps to meet the needs of your environment by using the Solaris Management Console tools. See Modifying How Autofs Navigates the Network (Modifying Maps). The automount command reads the master map at system startup. Each entry in the master map is a direct map name or an indirect map name, its path, and its mount options, as shown in Figure 6–4. The specific order of the entries is not important. automount compares entries in the master map with entries in the mount table to generate a current list.

The context describes the graphic.

What the autofs service does when a mount request is triggered depends on how the automounter maps are configured. The mount process is generally the same for all mounts. However, the final result changes with the mount point that is specified and the complexity of the maps. Starting with the Solaris 2.6 release, the mount process has also been changed to include the creation of the trigger nodes.To help explain the autofs mount process, assume that the following files are installed.$ cat /etc/auto_master # Master map for automounter # +auto_master /net -hosts -nosuid,nobrowse /home auto_home -nobrowse /share auto_share $ cat /etc/auto_share # share directory map for automounter # ws gumbo:/export/share/wsWhen the /share directory is accessed, the autofs service creates a trigger node for /share/ws, which is an entry in /etc/mnttab that resembles the following entry:-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=###When the /share/ws directory is accessed, the autofs service completes the process with these steps:Checks the availability of the server's mount service. Mounts the requested file system under /share. Now the /etc/mnttab file contains the following entries.-hosts /share/ws autofs nosuid,nobrowse,ignore,nest,dev=### gumbo:/export/share/ws /share/ws nfs nosuid,dev=#### ##### When multiple layers are defined in the automounter files, the mount process becomes more complex. Suppose that you expand the /etc/auto_shared file from the previous example to contain the following: # share directory map for automounter # ws / gumbo:/export/share/ws /usr gumbo:/export/share/ws/usrThe mount process is basically the same as the previous example when the /share/ws mount point is accessed. In addition, a trigger node to the next level (/usr) is created in the /share/ws file system so that the next level can be mounted if it is accessed. In this example, /export/share/ws/usr must exist on the NFS server for the trigger node to be created.Do not use the soft option when specifying hierarchical layers. Refer to Autofs Unmounting for an explanation of this limitation. The unmounting that occurs after a certain amount of idle time is from the bottom up (reverse order of mounting). If one of the directories at a higher level in the hierarchy is busy, only file systems below that directory are unmounted. During the unmounting process, any trigger nodes are removed and then the file system is unmounted. If the file system is busy, the unmount fails and the trigger nodes are reinstalled.Do not use the soft option when specifying hierarchical layers. If the soft option is used, requests to reinstall the trigger nodes can time out. The failure to reinstall the trigger nodes leaves no access to the next level of mounts. The only way to clear this problem is to have the automounter unmount all of the components in the hierarchy. The automounter can complete the unmounting either by waiting for the file systems to be automatically unmounted or by rebooting the system. The example direct map contains the following:/usr/local -ro \ /bin ivy:/export/local/sun4\ /share ivy:/export/local/share\ /src ivy:/export/local/src /usr/man -ro oak:/usr/man \ rose:/usr/man \ willow:/usr/man /usr/games -ro peach:/usr/games /usr/spool/news -ro pine:/usr/spool/news \ willow:/var/spool/news The mount points /usr/man and /usr/spool/news list more than one location, three locations for the first mount point, two locations for the second mount point. Any of the replicated locations can provide the same service to any user. This procedure is sensible only when you mount a file system that is read-only, as you must have some control over the locations of files that you write or modify. You want to avoid modifying files on one server on one occasion and, minutes later, modifying the “same” file on another server. The benefit is that the best available server is used automatically without any effort that is required by the user.If the file systems are configured as replicas (see What Is a Replicated File System?), the clients have the advantage of using failover. Not only is the best server automatically determined, but if that server becomes unavailable, the client automatically uses the next-best server. Failover was first implemented in the Solaris 2.6 release. An example of a good file system to configure as a replica is man pages. In a large network, more than one server can export the current set of man pages. Which server you mount the man pages from does not matter if the server is running and exporting its file systems. In the previous example, multiple mount locations are expressed as a list of mount locations in the map entry. /usr/man -ro oak:/usr/man rose:/usr/man willow:/usr/man In this example, you can mount the man pages from the servers oak, rose, or willow. Which server is best depends on a number of factors, including the following:The number of servers that support a particular NFS protocol level The proximity of the server The weighting During the sorting process, a count is taken of the number of servers that support each version of the NFS protocol. Whichever version of the protocol is supported on the most servers becomes the protocol that is used by default. This selection provides the client with the maximum number of servers to depend on.After the largest subset of servers with the same version of the protocol is found, that server list is sorted by proximity. To determine proximity IPv4 addresses are inspected. The IPv4 addresses show which servers are in each subnet. Servers on a local subnet are given preference over servers on a remote subnet. Preference for the closest server reduces latency and network traffic.Proximity cannot be determined for replicas that are using IPv6 addresses. Figure 6–5 illustrates server proximity.

The context describes the graphic.

If several servers that support the same protocol are on the local subnet, the time to connect to each server is determined and the fastest server is used. The sorting can also be influenced by using weighting (see Autofs and Weighting).For example, if version 4 servers are more abundant, version 4 becomes the protocol that is used by default. However, now the sorting process is more complex. Here are some examples of how the sorting process works:Servers on the local subnet are given preference over servers on a remote subnet. So, if a version 3 server is on the local subnet and the closest version 4 server is on a remote subnet, the version 3 server is given preference. Likewise, if the local subnet consists of version 2 servers, they are given preference over remote subnets with version 3 and version 4 servers. If the local subnet consists of a varied number of version 2, version 3, and version 4 servers, more sorting is required. The automounter prefers the highest version on the local subnet. In this instance, version 4 is the highest version. However, if the local subnet has more version 3 or version 2 servers than version 4 servers, the automounter “bids down” from the highest version on the local subnet by one version. For example, if the local subnet has three servers with version 4, three servers with version 3, and ten servers with version 2, a version 3 server is selected. Similarly, if the local subnet consists of a varied number of version 2 and version 3 servers, the automounter first looks at the which version represents the highest version on the local subnet. Next, the automounter counts the number of servers that run each version. If the highest version on the local subnet also represents the most servers, the highest version is selected. If a lower version has more servers, the automounter bids down from the highest version on the local subnet by one version. For example, if more version 2 servers are on the local subnet than version 3 servers, a version 2 server is selected. Weighting is also influenced by keyword values in the /etc/default/nfs file. Specifically, values for NFS_SERVER_VERSMIN, NFS_CLIENT_VERSMIN, NFS_SERVER_VERSMAX, and NFS_CLIENT_VERSMAX can make some versions be excluded from the sorting process. For more information about these keywords, see Keywords for the /etc/default/nfs File. With failover, the sorting is checked at mount time when a server is selected. Multiple locations are useful in an environment where individual servers might not export their file systems temporarily.Failover is particularly useful in a large network with many subnets. Autofs chooses the appropriate server and is able to confine NFS network traffic to a segment of the local network. If a server has multiple network interfaces, you can list the host name that is associated with each network interface as if the interface were a separate server. Autofs selects the nearest interface to the client.No weighting and no proximity checks are performed with manual mounts. The mount command prioritizes the servers that are listed from left to right. For more information, see automount1M man page. You can influence the selection of servers at the same proximity level by adding a weighting value to the autofs map. For example:/usr/man -ro oak,rose(1),willow(2):/usr/manThe numbers in parentheses indicate a weighting. Servers without a weighting have a value of zero and, therefore, are most likely to be selected. The higher the weighting value, the lower the chance that the server is selected. All other server selection factors are more important than weighting. Weighting is only considered when selecting between servers with the same network proximity. You can create a client-specific variable by prefixing a dollar sign ($) to its name. The variable helps you to accommodate different architecture types that are accessing the same file-system location. You can also use curly braces to delimit the name of the variable from appended letters or digits. Table 6–7 shows the predefined map variables. Variable Meaning Derived From Example ARCH Architecture type uname -m sun4 CPU Processor type uname -p sparc HOST Host name uname -n dinky OSNAME Operating system name uname -s SunOS OSREL Operating system release uname -r 5.8 OSVERS Operating system version (version of the release) uname -v GENERIC You can use variables anywhere in an entry line except as a key. For instance, suppose that you have a file server that exports binaries for SPARC and x86 architectures from /usr/local/bin/sparc and /usr/local/bin/x86 respectively. The clients can mount through a map entry such as the following: /usr/local/bin -ro server:/usr/local/bin/$CPUNow the same entry for all clients applies to all architectures. Most applications that are written for any of the sun4 architectures can run on all sun4 platforms. The ARCH variable is hard-coded to sun4. A map entry +mapname that is used in a file map causes automount to read the specified map as if it were included in the current file. If mapname is not preceded by a slash, autofs treats the map name as a string of characters and uses the name-service switch policy to find the map name. If the path name is an absolute path name, automount checks a local map of that name. If the map name starts with a dash (-), automount consults the appropriate built-in map, such as hosts. This name-service switch file contains an entry for autofs that is labeled as automount, which contains the order in which the name services are searched. The following file is an example of a name-service switch file.# # /etc/nsswitch.nis: # # An example file that could be copied over to /etc/nsswitch.conf; # it uses NIS (YP) in conjunction with files. # # "hosts:" and "services:" in this file are used only if the /etc/netconfig # file contains "switch.so" as a nametoaddr library for "inet" transports. # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files nis group: files nis # consult /etc "files" only if nis is down. hosts: nis [NOTFOUND=return] files networks: nis [NOTFOUND=return] files protocols: nis [NOTFOUND=return] files rpc: nis [NOTFOUND=return] files ethers: nis [NOTFOUND=return] files netmasks: nis [NOTFOUND=return] files bootparams: nis [NOTFOUND=return] files publickey: nis [NOTFOUND=return] files netgroup: nis automount: files nis aliases: files nis # for efficient getservbyname() avoid nis services: files nis In this example, the local maps are searched before the NIS maps. Therefore, you can have a few entries in your local /etc/auto_home map for the most commonly accessed home directories. You can then use the switch to fall back to the NIS map for other entries. bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonnyAfter consulting the included map, if no match is found, automount continues scanning the current map. Therefore, you can add more entries after a + entry. bill cs.csc.edu:/export/home/bill bonny cs.csc.edu:/export/home/bonny +auto_home The map that is included can be a local file or a built-in map. Remember, only local files can contain + entries. +auto_home_finance # NIS+ map +auto_home_sales # NIS+ map +auto_home_engineering # NIS+ map +/etc/auto_mystuff # local map +auto_home # NIS+ map +-hosts # built-in hosts map You cannot use + entries in NIS+ or NIS maps. You can create an autofs map that executes some commands to generate the autofs mount points. You could benefit from using an executable autofs map if you need to be able to create the autofs structure from a database or a flat file. The disadvantage to using an executable map is that the map needs to be installed on each host. An executable map cannot be included in either the NIS or the NIS+ name service.The executable map must have an entry in the auto_master file./execute auto_executeHere is an example of an executable map:#!/bin/ksh # # executable map for autofs # case $1 in src) echo '-nosuid,hard bee:/export1' ;; esacFor this example to work, the file must be installed as /etc/auto_execute and must have the executable bit set. Set permissions to 744. Under these circumstances, running the following command causes the /export1 file system from bee to be mounted:% ls /execute/src You can modify, delete, or add entries to maps to meet the needs of your environment. As applications and other file systems that users require change their location, the maps must reflect those changes. You can modify autofs maps at any time. Whether your modifications are effective the next time automountd mounts a file system depends on which map you modify and what kind of modification you make. At boot time autofs is invoked by the service svc:/system/filesystem/autofs and autofs checks for the master auto_master map. Autofs is subject to the rules that are discussed subsequently. Autofs uses the name service that is specified in the automount entry of the /etc/nsswitch.conf file. If NIS+ is specified, as opposed to local files or NIS, all map names are used as is. If NIS is selected and autofs cannot find a map that autofs needs, but finds a map name that contains one or more underscores, the underscores are changed to dots. This change allows the old NIS file names to work. Then autofs checks the map again, as shown in Figure 6–6.

The context describes the graphic.

The screen activity for this session would resemble the following example. $ grep /home /etc/auto_master /home auto_home $ ypmatch brent auto_home Can't match key brent in map auto_home. Reason: no such map in server's domain. $ ypmatch brent auto.home diskus:/export/home/diskus1/&If “files” is selected as the name service, all maps are assumed to be local files in the /etc directory. Autofs interprets a map name that begins with a slash (/) as local regardless of which name service autofs uses. The remaining sections of this chapter describe more advanced autofs features and topics. Autofs recognizes some characters as having a special meaning. Some characters are used for substitutions, and some characters are used to protect other characters from the autofs map parser. If you have a map with many subdirectories specified, as in the following, consider using string substitutions. john willow:/home/john mary willow:/home/mary joe willow:/home/joe able pine:/export/able baker peach:/export/bakerYou can use the ampersand character (&) to substitute the key wherever the key appears. If you use the ampersand, the previous map changes to the following: john willow:/home/& mary willow:/home/& joe willow:/home/& able pine:/export/& baker peach:/export/&You could also use key substitutions in a direct map, in situations such as the following: /usr/man willow,cedar,poplar:/usr/manYou can also simplify the entry further as follows:/usr/man willow,cedar,poplar:&Notice that the ampersand substitution uses the whole key string. Therefore, if the key in a direct map starts with a / (as it should), the slash is included in the substitution. Consequently, for example, you could not do the following: /progs &1,&2,&3:/export/src/progs The reason is that autofs would interpret the example as the following: /progs /progs1,/progs2,/progs3:/export/src/progs You can use the universal substitute character, the asterisk (*), to match any key. You could mount the /export file system from all hosts through this map entry. * &:/exportEach ampersand is substituted by the value of any given key. Autofs interprets the asterisk as an end-of-file character. If you have a map entry that contains special characters, you might have to mount directories that have names that confuse the autofs map parser. The autofs parser is sensitive to names that contain colons, commas, and spaces, for example. These names should be enclosed in double-quotes, as in the following: /vms -ro vmsserver: - - - "rc0:dk1 - " /mac -ro gator:/ - "Mr Disk - "