FSx ONTAP SMB 共享权限排查

给 FSx ONTAP SMB 共享添加了 NTFS 安全权限后，用户仍然无法访问共享。这个问题的关键是：Windows SMB 最终权限是共享权限和 NTFS 权限的交集，而且 Kerberos 票据不会在用户保持登录时自动刷新组成员关系。

现象

用户访问 SMB 共享路径时提示没有权限。管理员已经在“安全”选项卡里给目标域组添加了权限，但访问仍失败。

关键概念

SMB 共享访问同时受两层权限控制：

• 共享权限（Share Permissions）
• 安全权限 / NTFS 权限（Security Permissions）

最终生效权限是两者交集。只配置 NTFS 权限，不配置共享权限，用户仍可能被拒绝。

排查步骤

1. 检查共享权限

使用域管理员登录一台已加入域的 Windows 机器，打开：

compmgmt.msc

连接到 FSx SVM DNS 名称，然后进入：

系统工具 -> 共享文件夹 -> 共享

找到目标共享，打开属性，检查“共享权限”选项卡。确认目标用户或组至少有读取权限。

2. 检查 NTFS 权限

再检查“安全”选项卡，确认文件系统权限也包含目标用户或组。

3. 刷新 Kerberos 票据

如果用户刚刚被加入某个域组，当前登录会话里的 Kerberos TGT 可能仍是旧组成员信息。

最稳妥方式是让用户完全注销后重新登录，而不是锁屏或断开 RDP。

也可以尝试清票：

klist purge

但生产排障中，完整注销重登更直观可靠。

为什么会这样

Windows 用户登录后会拿到包含组成员关系的 Kerberos 票据。如果管理员在用户登录期间修改组成员关系，用户现有票据不会立刻自动变成新权限。FSx 看到的仍然是旧身份信息，导致权限判断失败。

总结

FSx ONTAP SMB 共享访问被拒时，建议按这个顺序查：

1. 共享权限是否放行。
2. NTFS 权限是否放行。
3. 用户是否注销重登刷新 Kerberos 票据。

只看“安全”选项卡是不够的，这是 SMB 权限排查里最常见的误区。