So a couple days ago I noticed I had no permission to access one of my directories. Since it was a directory that I use in command line mode I naturally checked the permissions that way:
$ ls -ld Downloads drwxrwxr-x 81 david david 27370 Feb 23 11:18 Downloads/
Looks ok! So it works, right?
$ cat > Downloads/eat -bash: Downloads/eat: Permission denied
What?
After puzzling for a few moments I decide to get info in Finder:
Oooo. I didn’t know OS X had ACLs. I don’t really like ACLs in general because they seem too complicated for normal usage.
Well, I’ll just click that nice little minus sign button and delete all the extra ACL things. Except that the minus sign button just straight up doesn’t work. I’ve unlocked it and typed in my password so I should have root permission at that point but the dumb button just doesn’t do anything. Something must be screwed up. Sigh. Back to the command line…
So I do some googling and fine you can check the ACLs at the command line with ls -e.
$ ls -e Downloads/ ls: invalid option -- e Try `ls --help' for more information.
What? Oh yeah, I put GNU ls on my machine so I could do color ls (turns out Leopard ls can do color with -G). Ok, let’s use the system ls:
$ /bin/ls -ld Downloads/ drwxrwxr-x+ 81 david david 27370 Feb 23 11:18 Downloads/
Aha!. There’s a + on the end of the permissions to show me ACLs exist.
$ /bin/ls -lde Downloads/ drwxrwxr-x+ 81 david david 27370 Feb 23 11:18 Downloads 0: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 1: group:everyone deny add_file,delete,add_subdirectory,delete_child,writeattr,writeextattr,chown 2: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 3: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 4: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 5: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 6: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity 7: user:root allow list,add_file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity ...
The list goes on exactly like that up to 127! Ok. That looks a bit screwey! So I figure out that you can manipulate ACLs with chmod, but annoyingly chmod doesn’t have an option to just wipe all the ACLs clean. Grrr… Ok, so I get to write a little loop in shell:
$ while /bin/ls -ld Downloads | f 1 | grep -q '+'; do chmod -a# 0 Downloads; done
f is a little program I stole from here.
So… Did it work?
$ /bin/ls -led Downloads/ drwxrwxr-x 81 david david 27370 Feb 23 11:18 Downloads/
Yes!
Now let’s make that a shell function so I can run it easier:
clear-acls() { while /bin/ls -ld $1 | f 1 | grep -q '+'; do chmod -a# 0 $1; done }
Now I can just do clear-acls Music and fix my music directory, which is also screwed up.
It also occurred to me that fixing the permissions with Disk Utility might work as well, so I am trying that now. The progress bar is not moving and it has been saying it will be done in “less than a 1 minute†for the past 10 minutes. Nice. Does anything work in Leopard?
Half an hour later… Disk Utility fixed some ACLs, but only on system directories. My home directory still has a bunch of folders with weird ACLs on them. I have no idea who put them there (I can only assume some stupid Apple bug, probably in Time Machine–what else scans my whole disk?), but at least I can manually fix it when it happens.