Clients cannot reach the FSx file server via a DNS alias. Packet capture shows the network path is fully reachable; the failure is in Kerberos — the KDC cannot find the service principal for the alias. The root cause is the alias missing a HOST/ SPN registered on the FSx AD computer object.

When creating FSx for Windows File Server using a self-managed Active Directory, if Single-AZ 2 or Multi-AZ file system creation fails and reports Get-ADComputer: Unable to contact the server, focus on checking TCP 9389 connectivity from the FSx subnet to the domain controllers.

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.