Skip to main content
A newer release of this product is available.

vserver export-policy rule create

Contributors
Suggest changes
PDFs

Create a rule

Availability: This command is available to cluster and Vserver administrators at the admin privilege level.

Description

The vserver export-policy rule create command creates an export rule and adds it to a policy. To create an export rule, you must specify the following items:

  • Vserver

  • Export policy

  • Clients that match the rule

  • Read-only access rule

  • Read-write access rule

You can optionally specify the following items:

  • Index number; that is, the location of the export rule in the policy

  • Access protocol

  • Anonymous ID

  • Superuser security type

  • Whether suid access is enabled

  • Whether creation of devices is enabled

  • Whether UNIX-type permissions changes on NTFS (Windows) volumes are prohibited or allowed when the request originates from an NFS client (advanced privilege and higher only)

  • Whether ownership changes are restricted or not (advanced privilege and higher only)

Parameters

-vserver <vserver name> - Vserver

This parameter specifies the Vserver on which the export policy is located.

-policyname <export policy name> - Policy Name

This parameter specifies the name of the export policy to which you want to add the new export rule. The export policy must already exist. To create an export policy, see the vserver export-policy create command.

[-ruleindex <integer>] - Rule Index

This optional parameter specifies the index number of the export rule that you want to create. If you specify an index number that already matches a rule, the index number of the existing rule is incremented, as are the index numbers of all subsequent rules, either to the end of the list or to an open space in the list. If you do not specify an index number, the new rule is placed at the end of the policy's list. Valid values are values from 1 to 4294967295.

[-protocol <Client Access Protocol>,…​] - Access Protocol

This optional parameter specifies the list of access protocols for which you want to apply the export rule. Possible values include the following:

  • any - Any current or future access protocol

  • nfs - Any current or future version of NFS

  • nfs3 - The NFSv3 protocol

  • nfs4 - The NFSv4 protocol

  • cifs - The CIFS protocol

You can specify a comma-separated list of multiple access protocols for an export rule. If you specify the protocol as any, you cannot specify any other protocols in the list. If you do not specify this parameter, the value defaults to any . If you enable NFSv4, you will not be able to apply the policy to which this rule belongs to a FlexGroup, as FlexGroups do not support NFSv4 protocol access.

-clientmatch <text> - List of Client Match Hostnames, IP Addresses, Netgroups, or Domains

This parameter specifies list of the match strings specifying the client or clients to which the export rule applies. Duplicate match strings in the same rule are not allowed. The maximum number of clientmatches that can be created is 4096. You can specify the match string in any of the following formats:

  • As a hostname; for instance, host1

  • As an IPv4 address; for instance, 10.1.12.24

  • As an IPv6 address; for instance, fd20:8b1e:b255:4071::100:1

  • As an IPv4 address with a subnet mask expressed as a number of bits; for instance, 10.1.12.0/24

  • As an IPv6 address with a subnet mask expressed as a number of bits; for instance, fd20:8b1e:b255:4071::/64

  • As an IPv4 address with a network mask; for instance, 10.1.16.0/255.255.255.0

  • As a netgroup, with the netgroup name preceded by the @ character; for instance, @eng

  • As a domain name preceded by the . character; for instance, .example.com

Note: Entering an IP address range, such as 10.1.12.10-10.1.12.70, is not allowed. Entries in this format are interpreted as a text string and treated as a hostname.

-rorule <authentication method>,…​ - RO Access Rule

This parameter specifies the security type for read-only access to volumes that use the export rule. Possible values include the following:

  • sys - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume if the security type of that incoming request is AUTH_SYS. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes sys.

  • krb5 - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume if the security type of that incoming request is Kerberos v5. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes krb5.

  • krb5i - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume if the security type of that incoming request is Kerberos v5 with integrity service. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes krb5i.

  • krb5p - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume if the security type of that incoming request is Kerberos v5 with privacy service. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes krb5p.

  • ntlm - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume if the security type of that incoming request is CIFS NTLM. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes ntlm.

  • any - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume regardless of the security type of that incoming request. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) remains the same as the security type of the incoming request.

    Note If the security type of the incoming request is AUTH_NONE, read access will be granted to that incoming request as an anonymous user.

  • none - For an incoming request from a client matching the clientmatch criteria, allow read access to the volume as an anonymous user if the security type of that incoming request is not explicitly listed in the list of values in the rorule. The effective security type of the incoming request (to be used subsequently in evaluation of rwrule/superuser) becomes none.

  • never - For an incoming request from a client matching the clientmatch criteria, do not allow any access to the volume regardless of the security type of that incoming request.

You can specify a comma-separated list of multiple security types for an export rule. If you specify the security type as any or never , you cannot specify any other security types.

Note For an incoming request from a client matching the clientmatch criteria, if the security type doesn't match any of the values listed in rorule (as explained above), access will be denied to that incoming request.
-rwrule <authentication method>,…​ - RW Access Rule

This parameter specifies the security type for read-write access to volumes that use the export rule. Possible values include the following:

  • sys - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume if the effective security type (determined from rorule) of that incoming request is AUTH_SYS.

  • krb5 - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5.

  • krb5i - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5 with integrity service.

  • krb5p - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5 with privacy service.

  • ntlm - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume if the effective security type (determined from rorule) of that incoming request is CIFS NTLM.

  • any - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume regardless of the effective security type (determined from rorule) of that incoming request.

    Note If the effective security type (determined from rorule) of the incoming request is none, write access will be granted to that incoming request as an anonymous user.

  • none - For an incoming request from a client matching the clientmatch criteria, allow write access to the volume as an anonymous user if the effective security type (determined from rorule) of that incoming request is none.

  • never - For an incoming request from a client matching the clientmatch criteria, do not allow write access to the volume regardless of the effective security type (determined from rorule) of that incoming request.

You can specify a comma-separated list of multiple security types for an export rule. If you specify the security type as any or never , you cannot specify any other security types.

Note For an incoming request from a client matching the clientmatch criteria, if the effective security type (determined by rorule) doesn't match any of the values listed in rwrule (as explained above), write access will be denied to that incoming request.
[-anon <text>] - User ID To Which Anonymous Users Are Mapped

This parameter specifies a UNIX user ID or user name that the user credentials are mapped to when evaluation of rorule or superuser parameters result in user being mapped to the anonymous user. The default setting of this parameter is 65534, which is normally associated with the user name "nobody" or "nfsnobody" in Linux environments. NetApp appliances use 65534 as the user "pcuser", which is generally used for multiprotocol operations. Because of this difference, if using local files and NFSv4, the name string for users mapped to 65534 might not match. This discrepancy might cause files to be written as the user specified in the /etc/idmapd.conf file on the client (Linux) or /etc/default/nfs file (Solaris), particularly when using multiprotocol (CIFS and NFS) on the same datasets. The following notes apply to the use of this parameter:

  • To disable access by any client with a user ID of 0, specify a value of 65535 which is associated with the user nobody.

[-superuser <authentication method>,…​] - Superuser Security Types

This parameter specifies a security type for superuser access to files. The default setting of this parameter is none . Possible values include the following:

  • sys - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume if the effective security type (determined from rorule) of that incoming request is AUTH_SYS.

  • krb5 - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5.

  • krb5i - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5 with integrity service.

  • krb5p - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume if the effective security type (determined from rorule) of that incoming request is Kerberos v5 with privacy service.

  • ntlm - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume if the effective security type (determined from rorule) of that incoming request is CIFS NTLM.

  • any - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow superuser access to the volume regardless of the effective security type (determined by rorule) of that incoming request.

    Note If the effective security type (determined from rorule) of the incoming request is none, access will be granted to that incoming request as an anonymous user.

  • none - For an incoming request from a client matching the clientmatch criteria and with the user ID 0, allow access to the volume as an anonymous user if the effective security type (determined from rorule) of that incoming request is none.

You can specify a comma-separated list of multiple security types for superuser access. If you specify the security type as any , you cannot specify any other security types.

Note For an incoming request from a client matching the clientmatch criteria and with the user ID 0, if the effective security type doesn't match any of the values listed in superuser (as explained above), the user ID is mapped to anonymous user.
[-allow-suid {true|false}] - Honor SetUID Bits in SETATTR

This parameter specifies whether set user ID (suid) and set group ID (sgid) access is enabled by the export rule. The default setting is true .

[-allow-dev {true|false}] - Allow Creation of Devices

This parameter specifies whether the creation of devices is enabled by the export rule. The default setting is true .

[-ntfs-unix-security-ops {ignore|fail}] - NTFS Unix Security Options (privilege: advanced)

This parameter specifies whether UNIX-type permissions changes on NTFS (Windows) volumes are prohibited (fail) or allowed (ignore) when the request originates from an NFS client. The default setting is fail .

[-chown-mode {restricted|unrestricted}] - Change Ownership Mode (privilege: advanced)

This parameter specifies who is allowed to change the ownership mode of a file. The default setting is restricted . The allowed values are:

  • restricted - Only root may change the ownership of the file.

  • unrestricted - Non-root users may change file ownership provided the on-disk permissions allow the operation.

Examples

The following example creates an export rule with index number 1 in an export policy named read_only_expolicy on a Vserver named vs0. The rule matches all clients in the domains named example.com or example.net. The rule enables all access protocols. It enables read-only access by any matching client and requires authentication by AUTH_SYS, NTLM, or Kerberos 5 for read-write access. Clients with the UNIX user ID zero are mapped to user ID 65534 (which normally maps to the user name nobody). It does not enable suid and sgid access or the creation of devices.

cluster1::> vserver export-policy rule create -vserver vs0 -policyname read_only_expolicy -ruleindex 1
-protocol any -clientmatch ".example.com,.example.net" -rorule any -rwrule "ntlm,krb5,sys" -anon 65534 -allow-suid false
-allow-dev false