Finder’s Inherited ACL handling is broken
Support for inherited ACLs on folders is still in disarray in 10.6.7 (and has been since 10.6.5), there have been a few reports here and there, some mentioning Error -41, other saying it was AFP, but I’ve whittled it down and it’s a Finder flaw handling inherited ACLs that was introduced in 10.6.3!
Hands On Demo
Let’s create a folder in your home directory using Terminal to make a nice little nested folder set to play with :
mkdir -p ~/ACLShackles/1/2/3/4/5/6/7/8/9/10/11
Now let’s add an entry to the folder’s ACL, in this case inherited folder and file Read & Write permissions, a common setup for workgroups that share a folder. OS X’s Server Admin sets inheritance by default when adding a user to an ACL, to do this with OS X Client you must use chmod:
chmod +a "$(whoami) allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,file_inherit,directory_inherit" ~/ACLShackles/
Make sure the above is all on one line and paste into Terminal.
Now, that the permissions are set double check with: ls -led ~/ACLShackles
Now duplicate folder structure we made called “1” with Command-D, now try and duplicate “1 copy” — it fails. Finder Error -41.
Looking at the ACL in Terminal isn’t pretty:
ls -leR /Users/brunerj/ACLShackles/1\ copy\ 2
It goes on to 108…
If you don’t like Terminal, I’ve got an Applescript for you: Error41.zip
Just download and, open the resulting Error41.dmg, open and run Error41.scpt to get this result:
Step-by-step illustrated Demo
Let’s try another example and illustrate.
Now, let’s copy in Chess.app, take a look at the permissions with the Inspector (Command-Option-I), notice the Permissions (for this example I added a different user in the ACL to avoid confusion between the Unix permission and the ACL when looking at Finder’s Get Info, it’s the same silhouette):
Looks good, and how it should. Now duplicate Chess.app within this folder with a Command-D:
Uh-oh. Something’s not right. It’s duplicated the original ACE (Access Control Entry) and added one for me the duplicator that seems to mimic my Unix permissions.
Copy the copy.
Much worse. It’s now duplicating my erroneous ACE and the ACE of the test user as well.
Copy the copy.
Oh dear. Fail. Error -41. Checkmate.
Let’s look at that third failed and truncated copy in Finder
Care to see how long an ACL is inside the app?
Yes. 110 ACEs are on “Chess copy 3.app/Contents”!
Comparing other file manager’s behavior
cp doesn’t suffer the same fate as Finder when making copies of copies.
This simulates Finder’s copy of a copy, delete any existing duplicate folders and try this:
cp -Rp 1 1\ copy; cp -Rp 1\ copy 1\ copy\ 2; cp -Rp 1\ copy\ 2 1\ copy\ 3; cp -Rp 1\ copy\ 3 1\ copy\ 4
Take a look inside with ls -leR ~/ACLShackles, nice and clean, one ACE per ACL on each folder the way it should be.
Rixstep’s XFile – doesn’t exhibit this behavior when copying or duplicating either, Rixstep software is quite conscientious about doing the Right Thing™
Path Finder however duplicates ACLs just like Finder, but instead of Error -41 when an ACL gets too long and deep it just hangs instead. What’s interesting is what calls is PathFinder using? They have an SDK but have only taken a cursory look, regardless it’s the same result as Finder.
In conclusion…
For OS X Server environments, this affects crucial workflow behavior where multiple people act upon the same files and folders. ACLs quickly stack up and render Finder unusable. Currently the last known proper behavior for Finder was 10.6.2. Then 10.6.3 and 10.6.4, added the quirk of adding an ACL entry that mimicked the UNIX permissions of the user doing the copy operation, but at least the ACEs weren’t duplicated ad nauseum. But taking the insanity to new heights was 10.6.5, 10.6.6, and now 10.6.7 with the duplication bug that makes working with inherited permissions unbearable. Luckily for OS X Client, this is minimized since Finder does not enable Inheritance for files or folders, but then you lose out on what inherited ACLs could do for you and your workgroup!
Since 10.6.7 is out now, 10.6.8 might be your last chance to have Snow Leopard’s Finder ACL behavior put back in working order. Let Apple know this is important to you, file a bug report at Apple’s Bug Reporter site, you can reference my bug number: 9160099 (you can view it at OpenRadar )
P.S. If you are wondering why I didn’t file this earlier since I am so detailed in the earlier 10.6 behavior? I actually became aware of something wrong in 10.6.5 but I also wasn’t sure what the cause was, Client, Server, AFP, Active Direcroty? Our UIDs are 10 digits long! During that time I hoped the soon to be released 10.6.6 would fix it, but when it didn’t I spent a lot of time just trying to fix it and clean the ACLs, it wasn’t until last week during the final seed of 10.6.7 that I found time to set up a new server and incrementally test 10.6, 10.6.2, 10.6.3, 10.6.4, 10.6.5, 10.6.6, and 10.6.7, recording QT Screen captures for each one and that took some time! My bug report only got in this Sunday. Oh well better late than never! :/
Remedies
It’s easy to nuke all the ACLs in a given folder, but then you’ll probably want them set back up again to be of any use! Anyway this will recursively wipe the ACLs from everything in the folder you’re in, be careful, you could wipe your own access! So it’s best for the server admin to to run from the server itself, then re-propagate the ACLs for the Share (actually you may not be able to delete ACLs from client anyway):
chmod -RN *
Update (3/23/11):
So I left my ACLShackles folder in my home foder and Time Machine failed to backup (backupd error -41, surprise.) so to avoid that, delete ACLShackles and/or turn off Time Machine while you play around with this…
Update (Sep 2011):
Just posting my comment down at the bottom so you don’t have to scroll all the way down there to read it…
