This view allows you to set options to control ACL behavior as well as control access to the root directory of the filesystem. This view is only available for filesystems.
Controls basic acess control for the root of the filesystem. These settings can be managed in-band via whatever protocols are being used, but they can also be specified here for convenience. These properties cannot be changed on a read-only filesystem, as they require changing metadata for the root directory of the filesystem.
The owner of the root directory. This can be specified as a user ID or user name. For more information on mapping Unix and Windows users, see the Identity Mapping service. For Unix-based NFS access, this can be changed from the client using the chown command.
The group of the root directory. This can be specified as a group ID or group name. For more information on mapping Unix and Windows groups, see the Identity Mapping service. For Unix-based NFS access, this can be changed from the client using the chgrp command.
Standard Unix permissions for the root directory. For Unix-based NFS access, this can be changed from the client using the chmod command. The permissions are divided into three types.
For each access type, the following permissions can be granted.
As of the 2011.1 software release, the following additional behavior is associated with the "write" permission for all directories:
Child files within the directory can be deleted (same as the ACL D permission), unless the sticky bit is set on the directory, in which case the child files can be deleted only if requested by the owner of the file
Times associated with a file or directory can be changed (same as the ACL A permission)
Extended attributes can be created, and writes are allowed to the extended attributes directory (same as the ACL W permission)
In the BUI, selecting permissions is done by clicking on individual boxes. Alternatively, clicking on the label ("user," "group," or "other) will select (or deselect) all permissions within the label. In the CLI, permissions are specified as a standard Unix octal value, where each digit corresponds to (in order) user, group, and other. Each digit is the sum of read (4), write (2), and execute (1). So a permissions value of 743 would be the equivalent of user RWX, group R, other WX.
As an alternative to setting POSIX permission bits at share creation time, administrators may instead select the "Use Windows Default Permissions" option, which will apply an ACL as described in the root directory ACL section below. This is a shortcut to simplify administration in environments that are exclusively or predominately managed by users with Windows backgrounds and is intended to provide behaviour similar to share creation on a Windows server.
For information on ACLs and how they work, see the root directory ACL documentation.
When an ACL is modified via chmod(2) using the standard Unix user/group/other permissions, the simplified mode change request will interact with the existing ACL in different ways depending on the setting of this property.
When a new file or directory is created, it is possible to inherit existing ACL settings from the parent directory. This property controls how this inheritance works. These property settings usually only affect ACL entries that are flagged as inheritable - other entries are not propagated regardless of this property setting. However, all trivial ACL entries are inheritable when used with SMB. A trivial ACL represents the traditional Unix owner/group/other entries.
When using SMB to create a file in a directory with a trivial ACL, all ACL entries are inherited. As a result, the following behavior occurs:
Inheritance bits display differently when viewed in SMB or NFS. When viewing the ACL directory in SMB, inheritance bits are displayed. In NFS, inheritance bits are not displayed.
When a file is created in a directory using SMB, its ACL entries are shown as inherited; however, when viewed through NFS, the directory has no inheritable ACL entries.
If the ACL is changed so that it is no longer trivial, e.g., by adding an access control entry (ACE), this behavior does not occur.
If the ACL is modified using SMB, the resulting ACL will have the previously synthetic inheritance bits turned into real inheritance bits.
All of the above behavior is subject to change in a future release.
Fine-grained access on files and directories is managed via Access Control Lists. An ACL describes what permissions are granted, if any, to specific users or groups. The appliance supports NFSv4-style ACLs, also accessible over SMB. POSIX draft ACLs (used by NFSv3) are not supported. Some trivial ACLs can be represented over NFSv3, but making complicated ACL changes may result in undefined behavior when accessed over NFSv3.
Like root directory access, this property only affects the root directory of the filesystem. ACLs can be controlled through in-band protocol management, but the BUI provides a way to set the ACL just for the root directory of the filesystem. There is no way to set the root directory ACL through the CLI. You can use in-band management tools if the BUI is not an option. Changing this ACL does not affect existing files and directories in the filesystem. Depending on the ACL inheritance behavior, these settings may or may not be inherited by newly created files and directories. However, all ACL entries are inherited when SMB is used to create a file in a directory with a trivial ACL.
An ACL is composed of any number of ACEs (access control entries). Each ACE describes a type/target, a mode, a set of permissions, and inheritance flags. ACEs are applied in order, starting at the beginning of the ACL, to determine whether a given action should be permitted. For information on in-band configuration ACLs through data protocols, consult the appropriate client documentation. The BUI interface for managing ACLs and the effect on the root directory are described here.
When the option to use Windows default permissions is used at share creation time, an ACL with the following three entries is created for the share's root directory: