FSx ONTAP SMB Share Permission Troubleshooting

After adding NTFS security permissions to an FSx ONTAP SMB share, users are still unable to access it. The key to this issue is: the effective Windows SMB permission is the intersection of share permissions and NTFS permissions, and Kerberos tickets do not automatically refresh group membership while the user remains logged in.

Symptoms

Users receive a permission denied message when accessing the SMB share path. The administrator has already added permissions to the target domain group in the "Security" tab, but access still fails.

Key Concepts

SMB share access is controlled by two permission layers simultaneously:

• Share Permissions
• Security Permissions / NTFS Permissions

The effective permission is the intersection of both. If only NTFS permissions are configured without share permissions, users may still be denied.

Troubleshooting Steps

1. Check Share Permissions

Log in to a domain-joined Windows machine with a domain administrator account and open:

compmgmt.msc

Connect to the FSx SVM DNS name, then navigate to:

System Tools -> Shared Folders -> Shares

Find the target share, open its properties, and check the "Share Permissions" tab. Confirm that the target user or group has at least Read permission.

2. Check NTFS Permissions

Then check the "Security" tab to confirm the file system permissions also include the target user or group.

3. Refresh Kerberos Tickets

If a user was just added to a domain group, the Kerberos TGT in their current login session may still contain old group membership information.

The most reliable approach is to have the user fully log off and log back in, rather than just locking the screen or disconnecting RDP.

You can also try purging tickets:

klist purge

But in production troubleshooting, a full logoff and logon is more straightforward and reliable.

Why This Happens

After a Windows user logs in, they receive a Kerberos ticket containing group membership information. If an administrator modifies group memberships while the user is logged in, the user's existing ticket will not automatically reflect the new permissions. FSx still sees the old identity information, causing the permission check to fail.

Summary

When FSx ONTAP SMB share access is denied, investigate in this order:

1. Whether share permissions allow access.
2. Whether NTFS permissions allow access.
3. Whether the user has logged off and back in to refresh Kerberos tickets.

Only checking the "Security" tab is not enough — this is the most common mistake in SMB permission troubleshooting.