ACL Tips and FAQs

The following parameters are the minimum required in the nfs.conf configuration file on macOS NFS clients for lock reclaims to function correctly (change your settings in nfs.conf, if not set properly):

Issue

If you are getting access-denied errors from an SMB share after creating and adding shares, and cannot even see the ownership on a share when this happens,

The problem is that when no ACL is found on the share-path then Samba is restricting access to the POSIX owner permissions of the StorNext directory (usually set to "root" or "sysadmin" by the Appliance Controller). This is not the default behavior when using a Windows/Mac server or Windows/Mac StorNext clients, which default to an "Everyone" ACL for access.

Resolution

To match expectations when using Windows/Macs with SMB, there is now an option to return a default "Everyone" ACL from the SNFS SMB VFS plugin when no ACL exists in the file system for a share. The "Everone" ACL is a pre-defined SID for WIndows/Macs/StorNext clients.

If your environment currently restricts share-access with the SMB "valid users", "write list", or if you have real ACLs set in the file system already, this change does not affect your environment. Access will continue to be restricted as before.

The default "Everyone" ACL behavior can be reverted again if necessary by setting this option on a SMB share or globally, log in to the command line of the system and enter:

To revert back to using Posix permissions, log in to the command line of the system and enter:

You cannot view or modify Access Control Lists (ACLs) that have been enabled for an SMB share from a macOS client, even when using Finder or the chmod / ls command from the client.

Resolution

To view or configure ACLs, you must do so from Xsan clients or Linux and Unix native StorNext clients. See (Optional) Step 4: Enable SID Mapping for Full ACL Support.

The StorNext 5.4.x release did not correctly support ACLs. A binary patch was released to address the issue. See the StorNext 5.4.0.1 Release Notes.

Yes. When an ACL is set, it takes precedence over the POSIX FX permissions.

If you remove the ACL, then the Appliance Controller will use the POSIX FX permissions again.

The Appliance Controller's default range for group IDs (GIDs) is 10,000 to 50,000. If you are using Apple Open Directory (OD) as your authentication service, the OD GIDs may be set outside of the Appliance Controller's GID range.

To resolve the issue, your system administrator needs to adjust the Appliance Controller's GID range to accommodate the OD GID range.

Resolution

1. og in to the controller console as the StorNext admin user. See Log in to the Appliance Controller CLI.
2. At the prompt, enter the following command to reset the low end of the GID range:

   reg set cifs.idmap.tdb_range_low <number>

3. At the prompt, enter the following command to reset the high end of the GID range:

   reg set cifs.idmap.tdb_range_high <number>

   Example #1:

   > reg set cifs.idmap.tdb_range_low 500

   Example #2:

   > reg set cifs.idmap.tdb_range_high 60000

If you enable either of the following SMB options to a share, the ACL permissions applied to the share may not work:

admin users

write list

Resolution

To resolve the issue, remove these options from the SMB share.

You can disable SID mapping if you no longer want to use ACLs with your OpenLDAP server. However, when you disable SID mapping under these circumstances, ACLs that have already been applied to folders and subfolders will remain, and in most cases, will be enforced.