ONTAP 9.14.1 commands
vserver export-policy rule modify
Modify a rule
Availability: This command is available to cluster and Vserver administrators at the admin privilege level.
Description
The vserver export-policy rule modify command modifies a specified export rule in a policy. This command cannot change the position of a rule in a policy; to reorder rules in a policy, use the vserver export-policy rule setindex command. Duplicate match strings in the same rule are not allowed. You can use this command to change the following attributes of an export rule:
-
Access protocol
-
Client match specification
-
Read-only access rule
-
Read-write access rule
-
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 containing the export rule that you want to modify.
-ruleindex <integer>- Rule Index-
This parameter specifies the index number of the export rule that you want to modify. To view a list of rules with their index numbers, use the vserver export-policy rule show command.
[-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. 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 modifies 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.
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
anyornever, you cannot specify any other security types.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 modifies 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.
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
anyornever, you cannot specify any other security types.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. Fujitsu 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.
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.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-
This parameter specifies whether UNIX-type permissions changes on NTFS (Windows) volumes are prohibited (with value
fail) or allowed (with valueignore) when the request originates from an NFS client. The default setting isfail. This parameter is only used if you set the NTFS UNIX security option for the Vserver touse_export_policy; otherwise, it has no effect. [-chown-mode {restricted|unrestricted}]- Change Ownership Mode-
This parameter specifies who is authorized to change the ownership mode of a file. The default setting is
restricted. This parameter is only used if you set the change ownership mode option for the Vserver touse_export_policy; otherwise, it has no effect. The allowed values are :-
restricted - Only root user can 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 modifies the export rule with index number 3 in an export policy named default_expolicy on a Vserver named vs0. The rule is modified to match any clients in the netgroups named group1 or group2 to enable NFSv2 and CIFS support, to enable read-only access by any matching client, to require authentication by NTLM or Kerberos 5 for read-write access, and to enable suid and sgid access.
cluster1::> vserver export-policy rule modify -vserver vs0 -policyname default_expolicy -ruleindex 3 -protocol "nfs2,cifs" -clientmatch "@group1, @group2" -rorule any -rwrule "ntlm,krb5" -allow-suid true
