Administrator Guide

Quota rules
Data reduction
Snapshots
NDMP backup
Replication
File Security Styles
The Windows and UNIX/Linux operating systems use dierent mechanisms for resource access control. Therefore, you assign each
NAS volume a le security style (NTFS, UNIX, or Mixed) that controls the type of access controls (permission and ownership) for
the les and directories that clients create in the NAS volume.
A NAS volume supports the following security styles:
UNIX – Controls le access using UNIX permissions. A client can change permissions only by using the chmod and chown
commands on the NFS mount point.
NTFS – Controls le access by Windows permissions. A client can change the permission and ownership using Windows (File
PropertiesSecurity tab).
Mixed – Supports both NTFS and UNIX security styles. If you choose this option, the default security of a le or directory is the
last one set. Permissions and access rights from one method to another are automatically translated. (For example, if a Windows
administrator sets up le access permissions on a le through an SMB share, a Linux user can access the le system through
NFS and change all the le permissions.) Therefore, this option is not recommended in production environments, except where
you are not concerned about le access security and just need some NAS volume space to store les temporarily.
Both NTFS and UNIX security styles allow multiprotocol le access. The security style determines only the method of storing and
managing the le access permissions information within the NAS volume.
If you need to access the same set of les from both Windows and UNIX or Linux, the best way to implement multiprotocol access is
by setting up individual user mapping rules or by enabling automatic user mapping. Ownership and access permissions are
automatically translated based on user mapping settings and le access credentials.
Modifying the le security style of a NAS volume aects only those les and directories created after the modication.
Thin and Thick Provisioning for NAS Volumes
In addition to the thin provisioning applied to the NAS pool, NAS volumes can be thinprovisioned. With thin provisioning (the
default), storage space is consumed on the Storage Centers only when data is physically written to the NAS volume, not when the
NAS volume is initially allocated. Thin provisioning oers the exibility to modify NAS volumes to account for future increases in
usage. However, because it is possible for the storage space used by the NAS volumes to exceed the Storage Center space
allocated to the NAS pool, you must monitor available capacity on the Storage Centers to ensure that the
FluidFS cluster always has
sucient free space available. You can also specify a portion of the NAS volume (reserved space) that is dedicated to the NAS
volume (no other volumes can take the space). The total reserved space of all NAS volumes cannot exceed the available capacity of
the NAS pool.
If a le is deleted from a thin-provisioned NAS volume, the free space as seen in Storage Manager increases. The freed-up capacity
is also visible and available to clients in the SMB shares or NFS exports. However, the Storage Center does not report any capacity
freed up in the NAS pool unless you enable the SCSI Unmap feature.
Thick provisioning allows you to allocate storage space on the Storage Centers statically to a NAS volume (no other volumes can
take the space). Thick provisioning is appropriate if your environment requires guaranteed space for a NAS volume.
Choosing a Strategy for NAS Volume Creation
When you dene multiple NAS volumes, you can apply dierent management policies — such as data reduction, data protection, le
security style, and quotas — based on your needs.
Consider the following factors to help choose the right strategy based on your environment’s requirements:
General requirements
NAS volumes can be created, resized (increased or decreased), or deleted.
400
FluidFS NAS Volumes, Shares, and Exports