| Skip Navigation Links | |
| Exit Print View | |
|
man pages section 4: File Formats Oracle Solaris 11.1 Information Library |
| Skip Navigation Links | |
| Exit Print View | |
|
|
man pages section 4: File Formats Oracle Solaris 11.1 Information Library |
- file containing parameter values for NFS-related daemons
/etc/default/nfs
The settings formerly managed by the nfs file have been moved to SMF properties and are now managed by sharectl(1M). The functionality described here is provided for backward compatibility only.
The nfs file resides in directory /etc/default and provides startup parameters for the nfsd(1M), nfsmapid(1M), mountd(1M), and lockd(1M) daemons.
The nfs file format is ASCII; comment lines begin with the crosshatch (#) character. Parameters consist of a keyword followed by an equals (=) sign followed by the parameter value, of the form:
keyword=value
The following parameters are currently supported in the nfs file:
The NFS client only uses NFS versions in the range specified by these variables. Valid values or versions are: 2, 3, and 4. By default these variables are unspecified (commented out) and the client's default minimum is Version 2. The default maximum is Version 4. You can override this range on a per-mount basis by using the -o vers= option to mount_nfs(1M).
The NFS server only uses NFS versions in the range specified by these variables. Valid values or versions are: 2, 3, and 4. As with the client, the default is to leave these variables commented out and the default minimum version is 2, while the default maximum version is 4.
By default, this variable is commented out and the NFS server provides delegations to clients. The user can turn off delegations for all exported filesystems by setting this variable to off (case-sensitive). This variable only applies to NFS Version 4.
By default, nfsmapid uses the DNS domain of the system. This setting overrides the default. This domain is used for identifying user and group attribute strings in the NFS Version 4 protocol. Clients and servers must match with this domain for operation to proceed normally. This variable only applies to NFS Version 4. See “Setting NFSMAPID_DOMAIN,” below for further details.
Sets the maximum number of concurrent, connection-oriented connections. The default is unlimited and is obtained by not setting (that is, commenting out) NFSD_MAX_CONNECTIONS. Equivalent to the -c option in nfsd.
Set connection queue length for the NFS over a connection-oriented transport. The default value is 32, meaning 32 entries in the queue. Equivalent to the -l option in nfsd.
Start nfsd over the specified protocol only. Equivalent to the -p option in nfsd. ALL is equivalent to -a on the nfsd command line. Mutually exclusive of NFSD_DEVICE. One or the other of NFSD_DEVICE and NFSD_PROTOCOL must be commented out. For the UDP protocol, only version 2 and version 3 service is established. NFS Version 4 is not supported for the UDP protocol.
Start NFS daemon for the transport specified by the given device only. Equivalent to the -t option in nfsd. Mutually exclusive of NFSD_PROTOCOL. One or the other of NFSD_DEVICE and NFSD_PROTOCOL must be commented out.
Maximum number of concurrent NFS requests. Equivalent to last numeric argument on the nfsd command line. The default is 1024.
Set connection queue length for lockd over a connection-oriented transport. The default and minimum value is 32.
Maximum number of concurrent lockd requests. The default is 1024.
Retransmit timeout, in seconds, before lockd retries. The default is 5.
Grace period, in seconds, that all clients (both NLM and NFSv4) have to reclaim locks after a server reboot. This parameter also controls the NFSv4 lease interval and overrides the deprecated setting LOCKD_GRACE_PERIOD. The default is 90.
Deprecated. Same as GRACE_PERIOD=num above. The default is 90.
As described above, the setting for NFSMAPID_DOMAIN overrides the domain used by nfsmapid(1M) for building and comparing outbound and inbound attribute strings, respectively. This setting overrides any other mechanism for setting the NFSv4 domain. In the absence of a NFSMAPID_DOMAIN setting, the nfsmapid(1M) daemon determines the NFSv4 domain as follows:
If a properly configured /etc/resolv.conf (see resolv.conf(4)) exists, nfsmapid queries specified nameservers for the domain.
If a properly configured /etc/resolv.conf (see resolv.conf(4)) exists, but the queried nameserver does not have a proper record of the domain name, nfsmapid attempts to obtain the domain name through the BIND interface (see resolver(3RESOLV)).
If no /etc/resolv.conf exists, nfsmapid falls back on using the configured domain name (see domainname(1M)), which is returned with the leading domain suffix removed. For example, for widgets.sales.acme.com, sales.acme.com is returned.
If /etc/resolv.conf does not exist, no domain name has been configured (or no /etc/defaultdomain exists), nfsmapid falls back on obtaining the domain name from the host name, if the host name contains a fully qualified domain name (FQDN).
If a domainname is still not obtained following all of the preceding steps, nfsmapid has no domain configured. This results in the following behavior:
Outbound owner and owner_group attribute strings are encoded as literal id's. For example, the UID 12345 is encoded as 12345.
nfsmapid ignores the “domain” portion of the inbound attribute string and performs name service lookups only for the user or group. If the user/group exists in the local system name service databases, then the proper uid/gid is mapped even when no domain has been configured.
This behavior implies that the same administrative user/group domain exists between NFSv4 client and server (that is, the same uid/gid's for users/groups on both client and server). In the case of overlapping id spaces, the inbound attribute string could potentially be mapped to the wrong id. However, this is not functionally different from mapping the inbound string to nobody, yet provides greater flexibility.
The NFS domain property is managed in Location profiles (refer to netcfg(1M) for more information about location profiles). These profiles are either fixed, meaning the network configuration is being managed in the traditional way, or reactive, meaning the network configuration is being managed automatically, reacting to changes in the network environment according to policy rules specified in the profiles.
When a fixed location (there can currently be only one, the DefaultFixed location) is active, changes made to the SMF repository will be applied to the location when it is disabled, and thus will be restored if that location is later re-enabled.
When a reactive location is active, changes should not be applied directly to the SMF repository; these changes will not be preserved in the location profile, and will thus be lost if the location is disabled, or if the system's network configuration, as managed by svc:/network/physical:default and svc:/network/location:default, is refreshed or restarted. Changes should instead be applied to the location itself, using the netcfg(1M) command; this will save the change to the location profile repository, and will also apply it to the SMF repository (if the change is made to the currently active location).
The NFS domain setting is stored in the nfsv4-domain property of a location profile.
lockd(1M), mount_nfs(1M), mountd(1M), netcfg(1M), nfsd(1M), nfsmapid(1M), sharectl(1M)
|