You can configure an ACL policy by choosing from the available settings options. Environment settings
UNIX only
Causes cluster permissions to operate with UNIX semantics, as opposed to Windows semantics. Enabling this option prevents ACL creation on the system.
Balanced
Causes cluster permissions to operate in a mixed UNIX and Windows environment. This setting is recommended for most cluster deployments.
Windows only
Causes cluster permissions to operate with Windows semantics, as opposed to UNIX semantics. Enabling this option causes the system to return an error on UNIX chmod requests.
Configure permission policies manually
Allows you to configure the individual permissions policy settings available under Permission Policies.
Permission policies settings ACL creation over SMB
Specifies whether to allow or deny creation of ACLs over SMB. Select one of the following options.
Do not allow the creation of ACLs over Windows File Sharing (SMB) Prevents ACL creation on the cluster.
Allow the creation of ACLs over SMB Allows ACL creation on the cluster. Note
Inheritable ACLs on the system take precedence over this setting: If inheritable ACLs are set on a folder, any new files and folders created in that folder will inherit the folder's ACL. Disabling this setting does not remove ACLs currently set on files. If you want to clear an existing ACL, run the chmod -b <mode><file> command to remove the ACL and set the correct permissions.
chmod on files with existing ACLs
Controls what happens when a chmod operation is initiated on a file with an ACL, either locally or over NFS. This setting controls any elements that set UNIX permissions, including File System Explorer. Enabling this policy setting does not change how chmod operations affect files that do not have ACLs. Select one of the following options.
Remove the existing ACL and set UNIX permissions instead
For chmod operations, removes any existing ACL and instead sets the chmod permissions. Select this option only if you do not need permissions to be set from Windows.
Remove the existing ACL and create an ACL equivalent to the UNIX permissions Stores the UNIX permissions in a Windows ACL. Select this option only if you want to remove Windows permissions but do not want files to have synthetic ACLs.
Remove the existing ACL and create an ACL equivalent to the UNIX permissions, for all users/groups referenced in old ACL
Stores the UNIX permissions in a Windows ACL. Select this option only if you want to remove Windows permissions but do not want files to have synthetic ACLs.
Merge the new permissions with the existing ACL
Causes Windows and UNIX permissions to operate smoothly in a balanced environment by merging permissions that are applied by chmod with existing ACLs. An ACE for each identity (owner, group, and everyone) is either modified or created, but all other ACEs are unmodified. Inheritable ACEs are also left unmodified to enable Windows users to continue to inherit appropriate permissions. UNIX users can set specific permissions for each of those three standard identities, however.
Deny permission to modify the ACL
Prevents users from making NFS and local chmod operations. Enable this setting if you do not want to allow permission sets over NFS.
Ignore operation if file has an existing ACL
Prevents an NFS client from making changes to the ACL. Select this option if you defined an inheritable ACL on a directory and want to use that ACL for
permissions. CAUTION
If you try to run the chmod command on the same permissions that are currently set on a file with an ACL, you may cause the operation to silently fail—The operation appears to be successful, but if you were to examine the permissions on the cluster, you would notice that the chmod command had no effect. As a workaround, you can run the chmod command away from the current permissions and then perform a second chmod command to revert to the original permissions. For example, if your file shows 755 UNIX permissions and you want to confirm this number, you could run chmod 700 file; chmod 755 file.
ACLs created on directories by UNIX chmod
On Windows systems, the access control entries for directories can define fine- grained rules for inheritance; on UNIX, the mode bits are not inherited. Making ACLs that are created on directories by the chmod command inheritable is more secure for tightly controlled environments but may deny access to some Windows users who would otherwise expect access.
Select one of the following options. l Make them inheritable
l Do not make them inheritable chown/chgrp on files with existing ACLs
Changes a file or folder's owning user or group. Select one of the following options. Modify the owner and/or group
Causes the chown or chgrp operation to perform as it does in UNIX. Enabling this setting modifies any ACEs in the ACL associated with the old and new owner or group.
Modify the owner and/or group and ACL permissions
Cause the NFS chown or chgrp operation to function as it does in Windows. When a file owner is changed over Windows, no permissions in the ACL are changed.
Ignore operation if file has an existing ACL
Prevents an NFS client from making changes to the owner or group. Note
Over NFS, the chown or chgrp operation changes the permissions and the owner or owning group. For example, consider a file owned by user Joe with rwx--- (700) permissions, signifying rwx permissions for the owner, but no permissions for anyone else. If you run the chown command to change ownership of the file to user Bob, the owner permissions are still rwx but they now represent the permissions for Bob, rather than for Joe, who lost all of his permissions. This setting does not affect UNIX chown or chgrp operations performed on files with UNIX permissions, and it does not affect Windows chown or chgrp operations, which do not change any permissions.
Access checks (chmod, chown)
In UNIX environments, only the file owner or superuser has the right to run a chmod or chown operation on a file. In Windows environments, you can implement this policy setting to give users the right to perform chmod operations, called the change permissions right, or the right to perform chown operations, called the take
ownership right. Note
The take ownership right only gives users the ability to take file ownership, not to give ownership away.
Select one of the following options. Allow only owners to chmod or chown
Causes chmod and chown access checks to operate with UNIX-like behavior. Allow owner and users with 'take ownership' right to chown, and owner and users with 'change permissions' right to chmod
Causes chmod and chown access checks to operate with Windows-like behavior.
Advanced settings
Treatment of 'rwx' permissions
In UNIX environments, rwx permissions signify two things: A user or group has read, write, and execute permissions; and a user or group has the maximum possible level of permissions.
When you assign UNIX permissions to a file, no ACLs are stored for that file. A Windows system processes only ACLs; Windows does not process UNIX permissions. Therefore, when you view a file's permissions on a Windows system, the cluster must translate the UNIX permissions into an ACL. This type of ACL is called a
synthetic ACL. Synthetic ACLs are not stored anywhere; instead, they are dynamically generated as needed and then they are discarded. If a file has UNIX permissions, you may notice synthetic ACLs when you run the ls file command on the cluster to view a file’s ACLs.
When you generate a synthetic ACL, the cluster maps UNIX permissions to Windows rights. Windows supports a more granular permissions model than UNIX does, and it specifies rights that cannot easily be mapped from UNIX permissions. If the cluster maps rwx permissions to Windows rights, you must enable one of the following options. The main difference between rwx and Full Control is the broader set of permissions with Full Control.
Select one of the following options. Retain 'rwx' permissions
Generates an ACE that provides only read, write, and execute permissions. Treat 'rwx' permissions as Full Control
Generates an ACE that provides the maximum Windows permissions for a user or a group by adding the change permissions right, the take ownership right, and the delete right.
Group owner inheritance
Operating systems tend to work with group ownership and permissions in two different ways: BSD inherits the group owner from the file's parent folder; Windows and Linux inherit the group owner from the file creator's primary group. If you enable a setting that causes the group owner to be inherited from the creator's primary group, you can override it on a per-folder basis by running the chmod command to set the set-gid bit. This inheritance applies only when the file is created. For more information, see the manual page for the chmod command.
Select one of the following options.
When an ACL exists, use Linux and Windows semantics, otherwise use BSD semantics
Controls file behavior based on whether the new file inherits ACLs from its parent folder. If it does, the file uses the creator's primary group. If it does not, the file inherits from its parent folder.
BSD semantics - Inherit group owner from the parent folder
Causes the group owner to be inherited from the file's parent folder. Linux and Windows semantics - Inherit group owner from the creator's primary group
Causes the group owner to be inherited from the file creator's primary group. chmod (007) on files with existing ACLs
Specifies whether to remove ACLs when running the chmod (007) command. Select one of the following options.
chmod(007) does not remove existing ACL
Sets 007 UNIX permissions without removing an existing ACL. chmod(007) removes existing ACL and sets 007 UNIX permissions
Removes ACLs from files over UNIX file sharing (NFS) and locally on the cluster through the chmod (007) command. If you enable this setting, be sure to run the chmod command on the file immediately after using chmod (007) to clear an ACL. In most cases, you do not want to leave 007 permissions on the file.
Owner permissions
It is impossible to represent the breadth of a Windows ACL's access rules using a set of UNIX permissions. Therefore, when a UNIX client requests UNIX permissions for a file with an ACL over NFS, an action known as a stat, it receives an imperfect approximation of the file's true permissions. By default, executing an ls -l command from a UNIX client returns a more open set of permissions than the user expects. This permissiveness compensates for applications that incorrectly inspect the UNIX permissions themselves when determining whether to attempt a file- system operation. The purpose of this policy setting is to ensure that these applications proceed with the operation to allow the file system to properly determine user access through the ACL.
Select one of the following options.
Approximate owner mode bits using all possible group ACEs
Makes the owner permissions appear more permissive than the actual permissions on the file.
Approximate owner mode bits using only the ACE with the owner ID
Makes the owner permissions appear more accurate, in that you see only the permissions for a particular owner and not the more permissive set. This may cause access-denied problems for UNIX clients, however.
Group permissions
Select one of the following options for group permissions: Approximate group mode bits using all possible group ACEs
Makes the group permissions appear more permissive than the actual permissions on the file.
Approximate group mode bits using only the ACE with the group ID
Makes the group permissions appear more accurate, in that you see only the permissions for a particular group and not the more permissive set. This may cause access-denied problems for UNIX clients, however.
No "deny" ACEs
The Windows ACL user interface cannot display an ACL if any deny ACEs are out of canonical ACL order. To correctly represent UNIX permissions, deny ACEs may be required to be out of canonical ACL order.
Select one of the following options.
Do not modify synthetic ACLs and mode bit approximations
Specifies to not modify synthetic ACL generation; “deny” ACEs will be generated when necessary.
CAUTION
This option can lead to permissions being reordered, permanently denying access if a Windows user or an application performs an ACL get, an ACL modification, and an ACL set (known as a round trip) to and from Windows. Remove “deny” ACEs from ACLs. This setting can cause ACLs to be more permissive than the equivalent mode bits
Does not include deny ACEs when generating synthetic ACLs. This setting can cause ACLs to be more permissive than the equivalent mode bits.
Access check (utimes)
You can control who can change utimes, which are the access and modification times of a file, by selecting one of the following options.
Allow only owners to change utimes to client-specific times (POSIX compliant) Allows only owners to change utimes, which complies with the POSIX standard, an approach that is probably familiar to administrators of UNIX systems. Allow owners and users with ‘write’ access to change utimes to client-specific times
Allows owners as well as users with write access to modify utimes—a less restrictive approach that is probably familiar to administrators of Windows systems.
Read-only DOS attribute
Deny permission to modify files with DOS read-only attribute over Windows Files Sharing (SMB)
Duplicates DOS-attribute permissions behavior over only the SMB protocol, so that they use the read-only attribute over SMB.
Deny permission to modify files with DOS read-only attribute over both UNIX (NFS) and Windows File Sharing (SMB)
Duplicates DOS-attribute permissions behavior over both NFS and SMB protocols. For example, if permissions are read-only on a file over SMB, permissions are read-only over NFS.
Displayed mode bits
Use ACL to approximate mode bits
Presents the OneFS approximation of the NFS mode bits, based on ACL permissions in the security descriptor.
Always display 777 if ACL exists-
If the approximated NFS permissions are less permissive than those in the security descriptor, you may want to use this setting so the NFS client does not stop with the access check before performing its operation. Use this setting when a third-party application may be blocked if the ACL does not provide the proper access.