Managing View Policies

Displaying View Policies

Displaying View Policies in VAST Web UI

To see the existing views configured on the cluster, select Element Store and then View Policies from the left navigation menu.

The following information can be displayed for each view policy:

Tip
To display or hide fields, click to the right of a column title, and then click to open a dropdown where you can select or unselect fields.

ID	The ID of the view policy.
Name	The name of the view policy.
Atime Frequency	atime is a metadata attribute of NFS files that represents the last time the file was updated. atime is updated on read operations if the difference between the current time and the file's atime value is greater than the configured atime frequency. 0 means atime is updated on every read operation.
Flavor	The security flavor of the policy. The security flavor determines how file and directory permissions are controlled. For a full description of the security flavors, see Controlling File and Directory Permissions Across Protocols. In brief, the possible values are: NFS. NFS clients can set permission mode bits on files and directories when creating new files and directories or modifying existing files and directories. Attempts by SMB clients to set file and directory permissions are ignored. Files and directories created by SMB clients receive a configurable set of initial permission bits. SMB. SMB clients can set permissions on files and directories. Attempts by NFS clients to set permission bits for files and directories are ignored. Files and directories created on NFS clients inherit permissions set on the parent directory by the SMB client. Mixed Last Wins. This flavor is designed to act as natively as possible to whichever protocol is used to create or modify a file or directory. It allows permissions to be set and modified from all clients. As far as possible, this flavor is designed such that whenever a user changes permissions via a given protocol, the permission change that is applied in VAST permissions is as the user intended. S3 Native. Supports S3 and provides a native experience for S3 usage. Also supports NFSv3 and NFSv4. S3 clients can set S3 ACLs on objects and on the view bucket. Attempts by NFS clients to set permission bits for files and directories are ignored. Access checks are done using the S3 access check algorithm. New objects created by NFS clients or created by S3 without setting ACL receive a default initial S3 object ACL, which gives the owner FullControl. Block. The flavor is intended for views that have the block access protocol enabled. The new flavor is used in the default block view policy that is automatically assigned to replicated block views at the destination peer.
Group Membership Source	Determines the source for retrieving group memberships of NFS users for the purposes of authorizing access to files and directories. Possible values: Client. The GIDs declared in the RPC as the user's leading group and auxiliary groups are trusted and provider-sourced groups are not considered. Providers. Group memberships retrieved from authorization providers are considered as the user's group memberships (as for SMB-only and multiprotocol views). The GIDs declared in the RPC are ignored. Client And Providers. Both the GIDs declared in the RPC and group memberships retrieved from authorization providers are considered. If the GID provided by the client does not match the GID retrieved from the authorization provider, the GID from the client is set. For more information about the impact of this setting, see The VAST Cluster Authorization Flow.
NFS Read Write	The hosts that have read/write access to the view via NFS. An asterisk (*) is a wildcard character that includes all hosts.
NFS Read Only	The hosts that have read-only access to the view via NFS. An asterisk (*) is a wildcard character that includes all hosts.
SMB Read Write	The hosts that have read/write access to the view via SMB. An asterisk (*) is a wildcard character that includes all hosts.
Continuous Available	Indicates whether the view exposes continuously available SMB shares.
SMB Ready Only	The hosts that have read-only access to the view via SMB. An asterisk (*) is a wildcard character that includes all hosts.
S3 Read Write	The hosts that have read/write access to the view via S3. An asterisk (*) is a wildcard character that includes all hosts.
S3 Read Only	The hosts that have read-only access to the view via S3. An asterisk (*) is a wildcard character that includes all hosts.
All Squash	The hosts that have all squash applied to them when accessing the view via NFS. With all squash, all client users are mapped to nobody for all file and folder management operations on the export.
No Squash	The hosts that have no squash applied to them when accessing the view via NFS. With no squash, all operations are supported. Use this option if you trust the root user not to perform operations that will corrupt data.
Root Squash	The hosts that have root squash applied to them when accessing the view via NFS. With root squash, the root user is mapped to nobody for all file and folder management operations on the export.
Trash	The hosts that have access to the trash folder when accessing the view via NFS (NFSv3 only). These hosts have the ability to delete files by moving them into a trash folder, from which they are automatically deleted.
Creation Time	The date and time at which the view policy was created.
Tenant	The tenant associated with the policy.

Displaying View Policies in VAST CLI

Run the viewpolicy list or viewpolicy show command.

Creating View Policies

Creating a View Policy in VAST Web UI

In the VAST Web UI, select Element Store from the left navigation menu and then select View Policies.
To add a new view policy, click Create Policy.
The Add Policy dialog is displayed with the General tab open.

In the General tab, complete the following fields:

Tenant	Specifies which tenant the view policy should serve. A view policy can serve a specific tenant or all tenants. To specify all tenants, select All tenants.
Name	Enter a unique name for the view policy. The name must be unique across all tenants.
Security flavor	The security flavor determines which protocol's access check algorithm is used and which protocol(s) is allowed to set permissions on files and directories. For more information, see Controlling File and Directory Permissions Across Protocols. Select an option from the dropdown: NFS. Treats NFS as a native protocol and other protocols as non-native protocols. Supports NFSv3, SMB and S3. Supports NFSv4 without support for NFSv4 ACLs. SMB. Treats SMB as a native protocol and other protocols as non-native protocols. Supports SMB, NFSv3, NFSv4 and S3. S3 Native. Treats S3 as a native protocol and other protocols as non-native protocols. Supports S3, SMB and NFSv3. Supports NFSv4 without support for NFSv4 ACLs. Mixed Last Wins. Allows file and directory permissions to be set and modified by all clients. Includes support for NFSv4 clients to set NFSv4 ACLs. Supports SMB, NFSv3, NFSv4 and S3. Note There is an advanced setting available which can block either NFSv4 or SMB from setting file permissions. This setting is available via the VAST CLI and is called access flavor. Caution Switching security flavors for views that have S3 Buckets enabled is not allowed. The flavor specified in the policy when the view is created must remain.
Virtual IP pools (optional)	If you want the view policy to allow access only from particular virtual IP pools, select one or more pools from the dropdown, or click Add new Virtual IP Pools to create a new one. Only clients from the selected pools will have access to views controlled with this view policy. Note Ensure that you select pools that belong to the same tenant. After you selected a pool, a grid is displayed showing the pool's IPs. Use the Type of Access column in the grid to specify whether the policy allows read/write (default) or read-only access for the pool. If no virtual IP pools are selected, clients from all pools can access all views associated with this view policy.

Optionally, use the Host-Based Access tab to restrict access to the view on a host basis per protocol.
You can restrict different access types. The NFS access types that you can restrict include read/write and read-only access that apply to NFSv3 and NFSv4, as well as squash permissions and trash folder permission that are only relevant to NFSv3.
On new installations, if a view policy does not have any host-based access rules defined for a specific access protocol, access is denied for all hosts. On upgraded deployments, all hosts are allowed access if no host-based access rules are defined.
Hosts can be entered as IP addresses, FQDNs and netgroups.
Tip
An asterisk ('*') shown to the right of the + Add New Rule button is a wildcard representing all IPs of all hosts: .
To add host-based access restrictions:
1. Under NFS, SMB or S3, find the Access Type category for which you want to add hosts:
  - Read / Write. Read/write access.
    With this type of access, you can specify a reversed rule, e.g. a rule that denies access from the specified host. To create a reversed rule, prepend the IP address with a tilde, for example: ~192.0.2.0
  - Read Only. Read-only access.
  - Squash control (for NFSv3 only):
    No Squash. All operations are supported. Use this option if you trust the root user not to perform operations that will corrupt data.
    Root Squash. The root user is mapped to nobody for all file and folder management operations on the export. This enables you to prevent the strongest super user from corrupting all user data on the VAST Cluster.
    All Squash. All client users are mapped to nobody for all file and folder management operations on the export.
  - Trash folder control (for NFS only):
    Trash Access. This option is displayed if Trash folder access is enabled in the Settings page. Granting this permission gives hosts the ability to delete files by moving them into a trash folder, from which they are automatically deleted. Requires also No Squash. For more information, see Trash Folder Access (for Rapid Parallel File Deletion).
  You can add hosts to any and all of the access types, but within each category no more than one type will be applied to any given host. If a host is specified with multiple entries in mutually exclusive types, the conflict is resolved as follows:
  - An IP overrides a netgroup, a netgroup overrides a CIDR, and a CIDR overrides a wildcard expression.
  - If a conflict remains after the previous rule is applied, then:
    Read Only overrides Read / Write.
    All Squash overrides Root Squash.
    Root Squash overrides No Squash.
2. Click the +Add New Rule button for the access type you want to add hosts to.
3. In the Enter hosts popup, add hosts using any of the following expressions in a comma-separated list:
  Note
  If IP addresses or CIDR subnets are specified, VMS will try to refactor them to a minimum number of subnets. For example, the entries
  10.25.0.0/16
  10.26.0.1, 10.26.0.2, 10.26.0.3
  are refactored as
  10.25.0.0/16, , 10.26.0.1, 10.26.0.2/31
  When refactoring, Read-Only entries take precedence over Read/Write.
  Refactoring is done after any change to the View Policy in which the list of IPs or CIDRs is changed. The refactoring process can take a few minutes, only after which is it reflected in the displayed list. Refactoring does not change the access granted by the ACL.
  - A single IP address or hostname of a single host.
  - A fully qualified domain name (FQDN).
    Note
    The following rules apply when specifying FQDNs:
    Maximum total length of an FQDN; 255 characters.
    Each domain name label is limited to 63 characters.
    Allowed characters: a-z, 0-9, hyphen (-).
    A label cannot start with a hyphen.
  - A subnet indicated by CIDR notation. For example: 1.1.1.1/24.
  - A range of IPs indicated by an IP address with '*' as a wildcard in place of any of the 8-bit fields in the address. For example, 3.3.3.*, or 3.3.*.*.
  - (NFS only) A netgroup, prefixed with an '@'. For information about using netgroups, see Using Netgroups to Authorize Hosts.
4. Click Add or press Enter.
  The entries are added.
To remove an entry, hover to the right of the entry until a removal button appears and click it:

Go to the NFS tab to make NFS settings:

Under Common NFS settings:

Group Membership Source	The source to trust for users' group memberships during the permission checking process: Client. Groups declared in the RPC as the user's leading group and auxiliary groups are trusted and provider-sourced groups are not considered. This option is supported only for views that are exposed exclusively to NFSv3. Providers. Group memberships retrieved from authorization providers are considered as the user's group memberships (as for SMB-only and multiprotocol views). The GIDs declared in the RPC are ignored. This option must be used for views that have SMB enabled. Similarly, where NFSv4 is enabled in the view, if Kerberos Authentication Minimal protection level is set to Kerberos Auth-only, Kerberos Integrity or Kerberos Privacy then this option must be used. Client and Providers. Groups declared in the RPC and group memberships retrieved from authorization providers are considered. If the GID provided by the client does not match the GID retrieved from the authorization provider, the GID from the client is set. Note If Kerberos authentication is used by NFSv4 clients, the groups declared in the RPC are ignored.
Enforce TLS encryption	Enable this setting if you want to enforce (m)TLS encryption between the NFSv3 or NFSv4 client and the cluster. Note TLS encryption requires further setup in addition to this view policy setting. For details, see Configuring TLS Encryption with NFS. When this setting is enabled, the Kerberos Authentication Minimal protection level option must be set to System or None.
Relaxed TLS enforcement	Applicable only if Enforce TLS encryption is enabled, this setting allows non-TLS connections on auxiliary NFSv3 subprotocols such as MOUNT, NLM, NSM and RQUOTA.
Enforce mTLS encryption	Enforces mTLS authentication for NFS. If enabled, the cluster denies access for clients that do not present an appropriate client certificate. This also applies to clients accessing the cluster from allowed client virtual IPs configured for the tenant. This flag can only be set for view policies that do not span multiple tenants. Note Enabling this option also causes TLS encryption to be enforced.

Under NFSv3:

POSIX ACL

Enables full support of extended POSIX Access Control Lists (ACL) for NFSv3 clients.

By default, VAST Cluster supports the traditional POSIX file system object permission mode bits (minimal ACL mode) in which each file has three ACL entries defining the permissions for the owner, owning group, and others, respectively. To learn more about POSIX ACL, see https://linux.die.net/man/5/acl.

If NFS security flavor is enabled, any POSIX ACLs set on directories are inherited by files created in the directory by SMB and S3 clients rather than the permission mode bits set in the view policy.

Note the following limitations:

The POSIX ACL setting is supported only with the NFS security flavor.
If POSIX ACL is enabled, POSIX ACLs may be used via NFSv3 only. They cannot be used via NFSv4.
If clients have created files and directories with POSIX ACLs using NFSv3 and then they start to access those files and directories via NFSv4, the POSIX ACLs will have no effect.
Support for NFSv4 ACLs requires Mixed Last Wins security flavor and is not available concurrently with POSIX ACLs for NFSv3.
If POSIX ACL is disabled, the setfacl Linux command is blocked.

Under NFSv4:

NFS case insensitivity

When enabled, VAST Cluster does not honor case in the names of file or directories accessed through NFSv4.

Caution
Toggling this option on or off for an existing view may have unpredictable results.

Kerberos Authentication Minimal protection level

Determines the minimum NFSv4 security level to allow for NFSv4 mounts:

System. Allows client mounts using either the AUTH_SYS RCP security flavor (the traditional default NFS authentication scheme) or with any of the three Kerberos security modes (krb5, krb5i, or krb5p).
None. Allows client mounts with the AUTH_NONE (anonymous access), or AUTH_SYS RCP security flavors, or with any of the three Kerberos security modes (krb5, krb5i, or krb5p).
Kerberos Auth. Allows client mounts with Kerberos authentication only and allows any of the three Kerberos security modes (krb5, krb5i, or krb5p).
Kerberos Integrity. Allows client mounts only if they use either Kerberos 5 authentication with privacy checking (krb5p) or Kerberos 5 authentication with integrity (krb5i).
Kerberos Privacy. Allows client mounts only if they use Kerberos 5 authentication with privacy checking (krb5p), the highest level Kerberos security mode.

If you intend to use this view policy for S3-enabled views, go to the S3 tab and set the following:
- Bucket listing permissions:
  - In the Bucket listing permission (users) field, enter any user names of users who should be able to list buckets that are created using this policy.
    When an S3 user sends a bucket listing request, the command returns a list of all buckets the user owns and all buckets that they have listing permission for, even if they do not have permission to access those buckets.
  - In the Bucket listing permission (groups) field, enter any group names of user groups who should be able to list buckets that are created using this policy.
- Use for new S3 buckets: Toggle on to use this policy as the default view policy for new buckets created via VAST S3 API, where the user is not associated with an S3 endpoint.
- Enable S3 special chars support: Allows or prohibits S3 object names containing character combinations that are not compatible with other access protocols, such as names containing // or /../.
- Settings for view policies with S3 Native security flavor:
  - Use full path in identity policies: When enabled, NFS and SMB clients are allowed or denied access based on the full resource names specified in the identity policies. This means that the identity policy can refer to particular files and directories, rather than to the bucket as a whole. When disabled, only the bucket name from the identity policy is taken into account.
  - Check access for listings based on identity policies: When enabled, NFS and SMB clients are able to list bucket views and their subdirectories regardless of individual object permissions. When disabled, listing a directory is allowed or denied based on the identity policies.

If you intend to use this view policy for SMB-enabled views, go to the SMB tab and set the following:

SMB continuous availability

This option is for use with SMBv3.

When enabled, the SMB share exposed by the view is set as continuously available, which allows SMB3 clients to request use of persistent file handles and keep their connections to this share in case of a failover event.

Note
This option requires that the client uses SMBv3.

Disable client leases

Enable this option to disable SMB caching leases for SMB clients and select the type(s) of lease that you want to disable:

Handle leases. Select to disable handle leases so that SMB clients cannot delay closing handles on files or directories.
Note
Disabling handle leases may impact client resiliency to network and server failures.
Read leases. Select to disable read leases so that SMB clients cannot cache data read from the server.
Write leases. Select to disable write leases so that SMB clients cannot cache data written to the server or set byte-range locks on files and directories.

If you selected NFS as the security flavor, optionally go to the Permissions for New Files and Directories tab to determine how file mode permission bits and the directory mode permission bits must be set on files/objects and directories created by protocols other than NFS.
- To configure the permissions manually, leave the Set Manually (Default POSIX Modebits) option toggled on and make the settings you want under File/Object Permissions and Directory Permissions below.
  To learn more about permissions and how they are transposed between the protocols, see Controlling File and Directory Permissions Across Protocols.
- To have permission bits inherited from the parent directory, toggle the Inherit ACL from parent option on.

In the Auditing tab, you can enable any auditing settings that are not enabled globally that you want to enable in the view policy.

Note
Before you can configure any auditing settings in a view policy, minimal global auditing settings must be configured first.
Any auditing settings that are enabled globally are automatically enabled on all views.

From the Protocols dropdown, select one or more protocols to enable auditing of protocol operations. Possible values: NFSv3, NFSv4, SMB, S3 and NDB (Database).

Under Operations to audit, choose one or more categories of operations to be audited for the protocol(s) for which auditing is enabled:

Create/Delete Files/Directories/Objects	Operations that create or delete files, directories, or objects.
Modify Data	Operations that modify data. This includes operations that change the file size.
Modify Metadata	Operations that modify metadata.
Read Data	Operations that read data.
Read Metadata	Operations that read metadata.
Session create/close	For sessions that use Kerberos 5 authentication (krb5, krb5i, or krb5p), the session creation and closing operations.

Optionally change the Audit record options:

Log full path

If enabled (default for all protocols), audit records contain the full Element Store path to the requested resource. This may affect performance. When disabled, the view path is recorded.

Log username

Disabled by default.

If enabled, audit records contain the username.

Optionally modify Advanced settings:

Name length limit	Affects the maximum allowed length of a component in a file path, and also the maximum allowable length of NFSv4 extended attributes. Choose between: Lowest Common Denominator (default). Imposes the lowest common denominator length limit of all VAST Cluster-supported protocols, regardless of the specific protocol enabled on a specific view. With this (default) option, the limit is 255 characters. For NFSv4.2 extended attributes, the limits are 128 characters for an attribute name (without the namespace prefix), and 256 characters for an attribute value. Native Protocol Limit. Imposes no limitation on file path component length beyond that of the client protocol. Caution If you select this mode in a view policy and then expose a view using this policy to a previously not exposed protocol, that view might contain files that won't be accessible by the newly added protocol, due to the limitations of that protocol. For NFSv4.2 extended attributes, the limits are 250 characters for an attribute name (without the namespace prefix), and 3750 characters for an attribute value.
Allowed Characters	Determines which characters are allowed in file names and NFSv4.2 extended attributes. Choose between: Lowest Common Denominator (default). Allows only characters allowed by all VAST Cluster-supported protocols, regardless of the specific protocol enabled on a specific view. For NFSv4.2 extended attributes: Attribute key names may include only ASCII characters except for the following characters: 0x00 - 0x1F, \ / : * ? " < > \| , + = [ ] ; Attribute values may include any ASCII characters. Native Protocol Limit. Imposes no limitation beyond that of the client protocol. Caution If you select this mode in a view policy and then expose a view using this policy to a previously not exposed protocol, that view might contain files that won't be accessible by the newly added protocol, due to the limitations of that protocol.
Atime Update interval	Sets the interval to update the atime attribute. atime is a metadata attribute of NFS files that represents the last time the file was updated. atime is updated on read operations if the difference between the current time and the file's atime value is greater than the configured atime frequency. Consider that a very low value might have a performance impact if high numbers of files are being read. If set to 0, atime is updated on every read operation. Default: 3600s.
Accessible .snapshot Folder In Subdirectories	This setting enables accessible .snapshot directories under all directories in the view. In subdirectories of protected paths, these directories provide links to any existing snapshots of parent directories even if there is no protected path on the subdirectory itself. This provides easier access from each directory to snapshots of parent directories. If disabled, access to a .snapshot directory under each directory is only enabled if the directory has a protected path on it.

Click Create.
The view policy is created and added to the list.

Creating a View Policy in VAST CLI

Use the viewpolicy create command to create a new view policy.

Modifying View Policies

Modifying a View Policy in VAST Web UI

In the VAST Web UI, select Element Store from the left navigation menu and then select View Policies.
Open the Actions menu for the view policy you want to edit, and select Edit to open the Update Policy dialog.
Review and change the view policy settings as appropriate. For detailed information about each setting, see Creating View Policies.
Click Update to save your changes.

Modifying a View Policy in VAST CLI

To modify a view policy via the VAST CLI, use the viewpolicy modify command.

Deleting View Policies

You can delete both user-defined and default view policies. A default view policy can be deleted only if the policy does not have any views attached to it.

To delete a view policy:

In VAST Web UI:
1. From the left navigation menu, select Element Store and then View Policies.
2. Right-click the policy you want to delete, and select Remove.
3. Click Yes to confirm the deletion.
In VAST CLI, run the viewpolicy delete command.

Documentation Index