When viewing the ACL in Xsan Admin, Server Admin, or the command line "ls" utility, the expected user or group might be replaced with a hexadecimal code similar to the text in this example:
drwxrwx---+ 3 root wheel 2048 Oct 15 00:09 /Volumes/MyXsanVolume 0: FFFFEEEE-DDDD-CCCC-BBBB-AAAA82000000 allow list,search,readattr,readextattr,readsecurity 1: group:ETS-W2K3\xsan_admins allow list,search,readattr,readextattr,readsecurity
The transient GUID is a placeholder that doesn't represent any user or group, so the affected ACEs are not enforced.
The system log might also contain "unable to map SID" entries like the following:
kernel: xsanfs_getsecurity: cvp 0xffffff8021ac3400 nt_sd_key 0xec995c516e: unable to map SID S-1-5-21-4096-987654321-987654321-2002 (error 2)
When this happens, Xsan ACEs might not resolve properly. Use the steps for the symptoms below to resolve the issue.
User or group does not exist
When a user or group is removed from a directory service, any ACEs defined for that user or group remain in the filesystem and the ACE appears as a transient GUID. When this happens, delete the affected ACE or reset it to an existing network user or group.
Issues communicating with directory server
Network user or group ACEs on Xsan volumes don't resolve if the network directory server is unreachable. Check that your directory server is online, and check the network connection between the Xsan client and the directory server.
Local users or groups
ACEs defined with a local user or group don't resolve correctly except on the Mac where they were created. To ensure that ACLs resolve correctly on each SAN computer, set up or join a network directory of users and groups like Open Directory or Active Directory. Only use users and groups from the network directory in Xsan ACLs.