Authorization issues

You might receive an unexpected “access denied” error either for native access to file system or for using the SMB or NFS protocols. Possible steps for troubleshooting the issue are described here.

Note: ACLs used in the object storage protocols are separate from the file system ACLs, and troubleshooting in that area should be done differently. For more information, see Object issues.

Verify authentication and ID mapping information

As a first step, verify that authentication and ID mapping are correctly configured. For more information, see Verifying the authentication services configured in the system.

Verify authorization limitations

Ensure that Access Control Lists (ACLs) are configured as required by IBM Storage Scale. For more information, see Authorization limitations. Also, check for more limitations of the NFSv4 ACLs stored in the file system. For more information, see Exceptions and limitations to NFS V4 ACLs support.

Verify stored ACL of file or directory

Read the native ACL stored in the file system by using this command:

mmgetacl -k native /path/to/file/or/directory

If the output does not report an NFSv4 ACL type in the first line, then consider changing the ACL to the NFSv4 type. For more information on how to configure the file system for the recommended NFSv4 ACL type for protocol usage, see Authorizing file protocol users. Also, review the ACL entries for permissions related to the observed “access denied” issue.

Note: ACL entries are evaluated in the listed order for determining whether access is granted, and that the evaluation stops when a “deny” entry is encountered. Also, check for entries that are flagged with “InheritOnly”, since they do not apply to the permissions of the current file or directory.

Verify group memberships and ID mappings

Next review the group membership of the user and compare that to the permissions granted in the ACL. If the cluster is configured with Active Directory authentication, then first have the user authenticate and then check the group memberships of the user. With Active Directory, authentication is the only reliable way to refresh the group memberships of the user if the cluster does not have the latest and complete list of group memberships:


/usr/lpp/mmfs/bin/wbinfo -a 'domainname\username'
 id 'domainname\username'

If the cluster is configured with a different authentication method, then query the group membership of the user:

id 'username'

If the user is a member of many groups, compare the number of group memberships with the limitations that are listed in the IBM Storage Scale FAQ. For more information, see https://www.ibm.com/docs/en/STXKQY/gpfsclustersfaq.html.

If a group is missing, check the membership of the user in the missing group in the authentication server. Also, check the ID mapping configuration for that group and check whether the group has an ID mapping that is configured and if it is in the correct range. You can query the configured ID mapping ranges by using this command:

/usr/lpp/mmfs/bin/mmuserauth service list

If the expected groups are missing in the output from the ID command and the authentication method is Active Directory with trusted domains, check the types of the groups in Active Directory. Not all group types can be used in all Active Directory domains.

If the access issue is sporadic, repeat the test on all protocol nodes. Since authentication and ID mapping is handled locally on each protocol node, it might happen that a problem affects only one protocol node, and hence only protocol connections that are handled on that protocol node are affected.

Verify SMB export ACL for SMB export

If the access issue occurs on an SMB export, consider that the SMB export ACL can also cause user access to be denied. Query the current SMB export ACLs and review whether they are set up as expected by using this command:

/usr/lpp/mmfs/bin/mmsmb exportacl list

Collect trace for debugging

Collect traces as a last step to determine the cause for authorization issues. When the access problem occurs for a user using the SMB protocol, capture the SMB trace first while recreating the problem (the parameter -c is used to specify the IP address of the SMB):

/usr/lpp/mmfs/bin/mmprotocoltrace start smb -c x.x.x.x

Re-create the access denied issue

/usr/lpp/mmfs/bin/mmprotocoltrace stop smb

For analyzing the trace, extract the trace and look for the error code NT_STATUS_ACCESS_DENIED in the trace.

If the access issue occurs outside of SMB, collect a file system trace:


/usr/lpp/mmfs/bin/mmtracectl –start

Re-create the access denied issue

/usr/lpp/mmfs/bin/mmtracectl --stop