Open topic with navigation

Disconnected: You’re looking at a local copy of the Appliance Controller Documentation Center. The most current version is online at www.quantum.com/accdocs.

# ACL Tips and FAQs

Why Don't Lock Reclaims Issued on a Mac OS With POSIX Locks Function Correctly?

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):

nfs.statd.send_using_tcp = 1

nfs.client.mount.options = resvport,vers=3

After upgrading to Appliance Controller 2.x, why am I getting access-denied errors from an SMB share after creating or adding shares?

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:

snfs:enable default acl = no

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

share change smb global snfs:enable default acl = false

Why Can't I Access ACLs for an SMB Share from My macOS?

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.

Why Can't I Get ACLs to Work Correctly from StorNext 5.4?

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.

Will ACLs Override my POSIX FX Permissions?

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

Example

If a folder has the `777` POSIX FX permission set for it in the StorNext file system and an ACL configured for `readonly`, the Appliance Controller uses the `readonly` permission and ignores the `777` permission.

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

Why Aren't My Group ACL Settings Working?

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

Why Aren't ACL Permissions Being Applied to My NAS SMB Share?

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.

Why Are ACLs Still Applied To My Files?

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.

6-68456-07_RevA | Initial publication date: Friday, December 22, 2017 | Last updated on Monday, January 12, 2026.

Open topic with navigation