This section contains the following topics:
For more information about the NFS protocol, use these topics:
For information about other supported protocols, see the following sections:
Each share has protocol-specific properties that define the behavior of different protocols for that share. These properties can be defined for each share or inherited from a share's project. The following table shows NFS protocol properties and possible values.
Exceptions to the global sharing mode may be defined for clients or collections of clients by setting client-specific share modes or exceptions. To restrict access to certain clients, set the global sharing mode to none and increasingly grant access to smaller and smaller groups. For example, you could create a share with the global sharing mode set to none, which denies access to all clients, and then grant read-only access to a subset of the clients. Further, you could grant read/write access to an even smaller subset of the clients and, finally, only trusted hosts might have read/write and root-enabled access.
Client-specific share modes take precedence over the global share mode. A client is granted access according to the client-specific share mode that is specified in an exception. In the absence of exceptions, the client is granted access according to the global share mode.
For each client or collection of clients, you specify whether the client has read-only or read-write access to the share. If you are setting an NFS exception, you also specify whether the client has root user privileges or is treated as a user without root access.
Netgroups can be used to control access for NFS exports. However, managing netgroups can be complex. Consider using IP subnet rules or DNS domain rules instead.
If netgroups are used, they will be resolved from NIS or LDAP, depending on which service is enabled. If LDAP is used, each netgroup must be located at the default location, ou=Netgroup,(Base DN), and must use the standard schema.
The username component of a netgroup entry typically has no effect on NFS; only the hostname is significant. Hostnames contained in netgroups must be canonical and, if resolved using DNS, fully qualified. That is, the NFS subsystem will attempt to verify that the IP address of the requesting client resolves to a canonical hostname that matches either the specified FQDN, or one of the members of one of the specified netgroups. This match must be exact, including any domain components; otherwise, the exception will not match and the next exception will be tried. For more information on hostname resolution, see DNS.
As of the 2013.1.0 software release, UNIX client users may belong to a maximum of 1024 groups without any performance degradation. Prior releases supported up to 16 groups per UNIX client user.
In the CLI, all NFS share modes and exceptions are specified using a single options string for the sharenfs property. This string is a comma-separated list of values. It should begin with one of ro, rw, on, or off, as an analogue to the global share modes described for the BUI.
The following example sets the share mode for all clients to read-only. The root users on all clients will access the files on the share as if they were the generic "nobody" user.
Either or both of the nosuid and anon options can also be appended. Therefore, to define the mapping of all unknown users to the uid 153762, you might specify the following:
Additional NFS exceptions can be specified by appending text of the form "option=collection", where "option" is one of ro, rw, or root, defining the type of access to be granted to the client collection. The collection is specified by the prefix character from Client Types table and either a DNS hostname/domain name or CIDR network number. For example, to grant read-write access to all hosts in the sf.example.com domain and root access to those in the 192.168.44.0/24 network, you might use:
Netgroup names can be used anywhere an individual fully qualified hostname can be used. For example, you can permit read-write access to the "engineering" netgroup as follows:
Normally, the character set encoding used for filename is unspecified. The NFSv3 and NFSv2 protocols do not specify the character set. NFSv4.0 and NFSv4.1 are supposed to use UTF-8, but not all clients do and this restriction is not enforced by the server. If the UTF-8 only option is disabled for a share, these filenames are written verbatim to the filesystem without any knowledge of their encoding. This means that they can only be interpreted by clients using the same encoding. SMB, however, requires filenames to be stored as UTF-8 so that they can be interpreted on the server side. This makes it impossible to support arbitrary client encodings while still permitting access over SMB.
In order to support such configurations, the character set encoding can be set share-wide or on a per-client basis. The following character set encodings are supported:
The default behavior is to leave the character set encoding unspecified (pass-through). The BUI allows the character set to be chosen through the standard exception list mechanism. In the CLI, each character set itself becomes an option with one or more hosts, with '*' indicating the share-wide setting. For example, the following:
hostname:shares default> set sharenfs="rw,euc-kr=*"
Will share the filesystem with 'euc-kr' as the default encoding. The following:
hostname:shares default> set sharenfs="rw,euc-kr=host1.domain.com,euc-jp=host2.domain.com"
Use the default encoding for all clients except 'host1' and 'host2', which will use 'euc-kr' and 'euc-jp', respectively. The format of the host lists follows that of other CLI NFS options.
Note that some NFS clients do not correctly support alternate locales; consult your NFS client documentation for details.
Security modes are set on a per-share basis. The following list describes Kerberos security settings:
krb - End-user authentication through Kerberos V5
krb5i - krb5 plus integrity protection (data packets are tamper proof
krb5p - krb5i plus privacy protection (data packets are tamper proof and encrypted)
Security modes are specified by appending text in the form "option=mode" where option is sec and mode is the security setting. For example:
hostname: shares default> set sharenfs="sec=krb5"
Combinations of Kerberos types can be specified in the security mode setting. The combination security modes let clients mount with any Kerberos type listed, as shown in the following table.
To set reserved ports for system authentication, use resvport as shown in this example:
Note that resvport can only be used with the system authentication security mode sec=sys.