Magic appearing ACLs of FFFFEEEE-DDDD-CCCC-BBBB-AAAA00...

[alavelle]

XSan 1.4.2
10.5.8 clients
10.5.8 server running OD (separate from MDC)

Weird issue where an ACL seems to magically change to a generic ACL seen via ls -alen

FFFFEEEE-DDDD-CCCC-BBBB-AAAA0000040A
and
FFFFEEEE-DDDD-CCCC-BBBB-AAAA0000040B
and
FFFFEEEE-DDDD-CCCC-BBBB-AAAA00000402

This then gets mapped back to the current logged in user (in most cases) or at least the user that was logged in when the xsan volume was mounted - not sure. Seen via ls -ale

Either way

dscl /Search -list /Users GeneratedUID
dscl /Search -list /Groups GeneratedUID

on any of the workstations doesn't show it as being a valid UID.

The ACL works for a while, then seems to change on its own.

Removing it and re-doing it seems to fix it, but haven't determined what in the heck is causing the issue.

Anyone seen something like this?

Searching the forums is leading me in the direction of possibly bad hardware somewhere in the mix?

Wondering if it's an Open Directory server issue? DSCL queries seem to work fine as far as I can see.

-Adam

[maximumjack]

We have seen a similar issue with the ACL's on our Xsan volume.
We are running 10.6.4 on our controllers and clients and users and groups are through Active Directory.
A call to Apple Enterprise support resulted in this being a known issue (in our case at least). Basically when a client machine is restarted (or the controller for that matter) the Xsan volume is mounted very early in the boot process and the Active Directory info is not yet available from the Directory Services process, so there is no way for the system to 'parse' the ACL's correctly. The result is ACL's that look like :

0: FFFFEEEE-DDDD-CCCC-BBBB-AAAA82000800 allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit

The work around for us is to make sure that the Xsan volume is unmounted before a machine is shutdown/restarted, that way when the machine restarts the Directory Service process is in place before the Xsan volume is mounted. The actual mounting of the Xsan volume is now done by a loginhook that uses the xsnctl command.

Hope this helps.

paul

[mjsanders]

I do not have this user ID in my 10.6 system, but since all (default) background users like _sshd, root, _spotlight, etc also start with FFFFEEE-DDDD I guess that it is supposed to be some background user (default groups start with ABCDE..), maybe only available on one of the workstations?

My guess is that an application installs a new background user, and this user's UUID is added to all folders created/edited with this application or workflow

Could you give more info about the type of folder you see these ACL's on?
that should help us (and you) where to look for the source.

The ls-alen command will always show you the number of the users/groups and what if you run ls -ale ? If you do not see a user/group name it means that this workstation does not know the user/group related to this UUID.

If you see an UUID in the ls -lae output, does not automatically mean that there is a directory services issue, it only indicates that not all Xsan clients have the same setup for Directory Services. (including the MDC's), so look into the Directory Setup for all workstations and MDC's

A workaround could be to delete all ACLs from a folder with a (scripted) chmod -N command. (if you can live with just the posix permissions)

[alavelle]

Doing

dscl /Search -list /Users GeneratedUID |grep FFFFEEEE-DDDD-CCCC-BBBB-AAAA0000040A

Doesn't show any results on any of the clients or servers.


ls -alde /Volumes/XSan/Media

0: edit1 allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directory_inherit


Shows different usernames depending on the workstations/server.

I've removed ACLs and added them back and it seemed to end up in the same situation a few days later where they reverted to the mystery GUID of FFFFEEEE-DDDD-CCCC-BBBB-AAAA000...

Were using just Open Directory, no Active Directory in the mix.

Even dismounting and re-mounting the volume on a workstation while the system is running doesn't change anything.

[maximumjack]

Did you try un-mounting the volume, then restarting the client machine, waiting until Directory Services was available (if you show the Network Accounts Available text at the login screen there should be a green light next to it), then logging in as a user and mounting the volume (either via Xsan Admin or using 'xsanctl mount name_of_your_volume')?

[jbuckner]

We've been having this issue with our Xsan setup and I tested the unmount/restart/mount solution and it worked great!

My concern is for one of my servers that's resharing our Xsan volume via AFP. No one ever logs onto it so I couldn't use a LoginHook to fix it.

1. Is there a way to create a "ShutdownHook" for the server?
2. If I created a launchd script to do my mounting on startup, could I just put in a 'sleep 20' into the script to wait to mount the xsan?

BTW, if anyone's interested, this is the script I created for my Login/Logout Hooks:

##############################
#!/bin/sh

XSAN_VOLUME="VolumeName"
RECIPIENT="xsanadmin@mailhost.edu"
SUBJECT="Xsan: $HOSTNAME unmount output"

/Library/Filesystems/Xsan/bin/xsanctl unmount $XSAN_VOLUME 2>&1 | mailx -s "$SUBJECT" $RECIPIENT

[brianwells]

The script included in this Apple support article worked for me:

Xsan 2: ACEs on Xsan volumes may appear as hexadecimal code
http://support.apple.com/kb/TS3556

Unfortunately, the script was posted without proper line breaks. Here is a copy that has been cleaned up:

http://www.briandwells.com/files/xsand_delay.rb

And here are the instructions with line breaks added:

[jbuckner]

Thanks for posting the script in a usable form. I switched from my Login/LogoutHook to using it and it's working well.

The only service I have that's using the SAN is Appleshare and it seems to be handling the late loading fine, but I'm going to keep an eye on it.