Share Protocols - NFS

Exceptions to the overall sharing modes may be defined for clients or collections of clients. When a client attempts access, its access will be granted according to the first exception in the list that matches the client; or, if no such exception exists, according to the global share modes defined above. These client collections may be defined using one of three types:

For each specified client or collection of clients, you will then express two parameters: whether the client shall be permitted read-only or read-write access to the share, and whether the root user on the client shall be treated as the root user (if selected) or the unknown user.

If netgroups are used, they will be resolved from NIS (if enabled) and then from LDAP (if enabled). If LDAP is used, the netgroups must be found 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. Management of netgroups can be complex; consider using IP subnet rules or DNS domain rules instead where possible.

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.

Share Protocols - CLI

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 from the tables above. It should begin with one of "ro", "rw", or "off", as an analogue to the global share modes described for the BUI. For example,

set sharenfs=ro

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 may also be appended. Remember that in the CLI, property values containing the "=" character must be quoted. Therefore, to define the mapping of all unknown users to the uid 153762, you might specify

set sharenfs="ro,anon=153762"

Additional exceptions can be specified by appending text of the form "option=collection", where "option" is one of "ro", "rw", and "root", defining the type of access to be granted to the client collection. The collection is specified by the prefix character from the table above 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

set sharenfs="ro,anon=153762,rw=.sf.example.com,root=@192.168.44.0/24"

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:

set sharenfs="ro,rw=engineering"

Security modes are specified by appending text in the form "option=mode" where option is "sec" and mode is one of "sys", "krb5", "krb5:krb5i", or "krb5:krb5i:krb5p".

set sharenfs="sec=krb5"

Security Modes

Security modes are set on per-share basis and can have performance impact. The following table describes the Kerberos security settings.

Combinations of Kerberos flavors may be specified in the security mode setting. The combination security modes let clients mount with any Kerberos flavor listed.

For more information about NFS and Kerberos, see:

• http://www.ietf.org/rfc/rfc2623.txt (NFSv2 and NFSv3 Security)

• http://www.ietf.org/rfc/rfc3530.txt (NFSv4 Protocol)

Character Set Encodings

Normally, the character set encoding used for filename is unspecified. The NFSv3 and NFSv2 protocols don't specify the character set. NFSv4 is 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:

• cp932

• euc-cn

• euc-jp

• euc-jpms

• euc-kr

• euc-tw

• iso8859-1

• iso8859-2

• iso8859-5

• iso8859-6

• iso8859-7

• iso8859-8

• iso8859-9

• iso8859-13

• iso8859-15

• koi8-r

• shift_jis

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:

set sharenfs="rw,euc-kr=*"

Will share the filesystem with 'euc-kr' as the default encoding. The following:

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.