if you have problems with ACL

Thank you! This solved a big problem I couldn't figure out.
The actual syntax that worked for me:
chmod -RN /path

Message was edited by: School ITGuy

My home folder and all of my external drives (2 firewire, 1 USB) are stuck in a locked state. I have tried to use Get Info and then unlock, but the drives won't stay unlocked. A little work in the Terminal.app showed that the folders in my Home directory are listed with the "Everyone Deny Delete" attribute.

So far, Terminal commands I've seen on these boards have not fixed the problem. If I use this command on my home folder, will it remove ACL on all folders in the home folder?

Will this command also resolve the issue I'm having w/ my external drives? I am not very Terminal literate, but I am willing and able to try anything. Let me know if I need to supply more info.

-s

This worked for me, thankfully. If apple is listening, why is there not a way to fix this with a GUI? I accidentally did something by trying to share a sub-directory in my home directory with someone on another computer. So I added them as a user and added them in System Preferences -> Shared. Afterwards I removed them. Don't get me wrong, I am a strong convert; I hate Windows, and Linux is a pain in many ways for desktop work. But this one seems like a simple oversight somewhere.

Problem with this command is that it removes all ACLs from the directory, which can cause other, hard to figure out problems. For example, there is an ACL on ~/Public/Drop Box which sets it up so that any file/folder copied into it will give the owner of the drop box Read&Write privs. Without that ACL, if someone sends you a file and puts it in your Drop Box, you won't be able to do anything with it other then read it. A common problem reported on this board.
Also, the 'everyone deny delete' entry has a specific purpose. Its to prevent people from trying to delete/rename/move folders that are required by the OS. Do a quick search through the Tiger and previous OS boards for how many people tried to rename their home directory or move it to another volume. That is what that ACL is designed to prevent. Yes, there is a bug in the Info Window's Apply To Enclosed function that will propagate that ACL down to all your files/folders in your home directory, but it is easy enough to fix.

A better solution, instead of blindly hitting your home directory with a sledge hammer without really knowing what the cause of your problem is, would be to run the Reset Password util on the Leopard Install DVD to reset the permissions/ACLs on your home directory back to what they should be, or running a couple simple chmod commands in Terminal. I would recommend the Reset Password util to those who don't feel comfortable with Terminal. Either way, here's how you do it:

1) boot from your Leopard install CD.
2) Choose your language.
3) When the menubar appears, select Utilities->Reset Password.
4) In the window that appears, select your boot volume from the list at the top.
5) In the popup button below the volume list, select your user from the list.
6) Click the "Reset" button at the bottom of the window. This will reset the privs back to their default settings.
7) Repeat Steps 5 & 6 for every user on your machine who has this problem (except root).

That should clean things up.

Here is how you would reset the privs in your home directory back to the default settings (what they were when the user was first created) via Terminal. Note this does not change the permissions (other then removing the 'everyone deny delete' ACL) for the contents of the folders in your home directory. That can also be done via Terminal, but I'll save that for another post.

*sudo chmod -R +a "everyone deny delete" ~/* +Note: 'sudo' will cause it to ask for your admin password, but when you type it will not show the text. This is normal. Just make sure you type your password correctly. This command will add the 'every deny delete' ACL to everything inside your home directory. This is done so that the next command will succeed. If the next command encounters a file/folder that doesn't have this ACL on it, it will fail and bail out, ultimately leaving your home directory half fixed.+

*sudo chmod -R -a "everyone deny delete" ~/* +Note: This will remove the 'everyone deny delete' ACL from all files and folders in your home directory, the next command will add it back to where it needs to be+

*sudo chmod +a "everyone deny delete" ~/ ~/Desktop ~/Documents ~/Downloads ~/Library ~/Movies ~/Music ~/Pictures ~/Public ~/Sites* +Note: This only applies the 'everyone deny delete' ACE to the folders listed, not their contents. These folders are required by the system, this ACE prevents you (or anyone else) from renaming, moving or deleting them (because they are required by the OS).+

*sudo chown -R <your username>:staff ~/* +Note: This will make you the owner of everything inside your home directory and staff (a group consisting of all the admin users on your machine) the group.+

*sudo chmod 755 ~/ ~/Public ~/Sites* +Note: This will set your home directory, Public and Sites directories permissions back to what they were when you first created your user. It gives you Read&Write access, the group (staff) Read Only, and Everyone else Read Only access.+

*sudo chmod 700 ~/Desktop ~/Documents ~/Downloads ~/Library ~/Movies ~/Music ~/Pictures* +Note: This will set these folders permissions back to what they were when you first created your user. This gives you Read&Write access, and the group (staff) and everyone else No Access.+

*sudo chmod +a "<your username> allow list,add file,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr, writeextattr,readsecurity,writesecurity,chown,file_inherit,directoryinherit" ~/Public/Drop\ Box* +Note: This adds the ACL onto your Drop Box that I described above. There are no spaces after the comma's on purpose. If you add extra spaces you'll get an error that the ACL isn't recognized.+

Just copy/paste the bold text, one at a time, into a Terminal window and press return. That should do it. Good luck...

Message was edited by: petrock

riodeg242 wrote:
This worked for me, thankfully. If apple is listening, why is there not a way to fix this with a GUI?

See my post below for a method to reset your home directory privs via a GUI. All be it, its a hidden GUI, but a GUI none the less.

riodeg242 wrote:
I accidentally did something by trying to share a sub-directory in my home directory with someone on another computer. So I added them as a user and added them in System Preferences -> Shared. Afterwards I removed them.

So what went wrong? What you described doesn't sound like anything weird. Do you have a thread covering your issue?

staff (a group consisting of all the admin users on your machine)

Minor correction(?): At least on my Mac, all new standard as well as admin accounts are created as members of the staff group (GID: 20). This gives standard users the ability to see (read) the root level folders of other standard & admin accounts (but of course not to open any of those folders that restrict read access to the owner).

Also, when I used the permissions reset in the Password Reset utility on my normal user account, it reset the group of the account's home folder & its 7 default root folders with no non-owner access (Desktop, Documents, Downloads, Library, Movies, Music, & Pictures) to wheel rather than staff. The Drop Box was also set to group wheel, although Public & Sites were not. The Drop Box also did not get any ACL entries. As best as I can tell, no children of the 7 default folders inherited the wheel group & no other folders I created at the root user level or their children had their permissions changed in any way.

Regarding that last statement, I have a few folders in my home folder besides the 9 defaults, some set to admin group, some to staff, with assorted permissions I have set for various reasons. The admin group ones were all created in Tiger, the staff ones in Leopard. The Public folder also had items besides the Drop Box in it. I don't know if any of this had anything to do with the wheel group resets or the anomalous Drop Box stuff.

Either way, other users with additional folders at the root user level and/or nested folders with permissions they have intentionally changed or added should be wary of using the recursive Terminal commands (those with the "-R" option) to set all subfolder permissions alike or to remove all of their ACL's. The permissions reset in the Password Reset utility is more benign in this respect, but its wheel group changes will still have to be reset to staff & the missing ACL for the Drop Box added (if either or both occur for others) if you want to restore all the normal defaults of a new account but retain your custom ones as well.

Given all this, I think someone, ideally Apple, should create a little utility that at least reports any non-default permissions or ACL's it finds in home folders, much like Disk Utility's Permissions check does for many items outside of the home folder. A 'repair' feature would be trickier but just knowing what's non-standard would be useful.

Thanks for the post in follow-up. I could not find any posts regarding my specific issue, so I sorta pieced together information from various posts I did find. I do understand about the ACLs, and only did the command to the directory that was having troubles. The most important aspect of this, and made my life easier, was that it was a subdirectory of the ~/Documents directory. So all but the problem directory in my home directory were uneffected by either the command or the issue.

As for the first suggestion with the install CD, I tried that and nothing changed. It seems (though I didn't have time to confirm) that the install CD just dealt with permissions, not file attributes or ACLs.

I am familiar with the chmod, chown, chgrp commands from linux, and these did not work. At least as far as permissions. So my guess from reading the forums was that the ACLs (file attributes to me) were the culprit. And indeed they were.

The main reason for my post is that if Apple wishes to maintain the image of being very user friendly, this would be something important to address. Finding out why it happened is part, but more importantly how to fix it. People should have tools at their hands to fix things. In your follow-up post, it seems you would agree. Something to display where folders are "non-standard" in Apple's eyes and then the ability to fix it atomically or "brute forcely".

BTW, no Linux distro is any better, but I would have hoped Apple would have something. And like I've said, I hate Windows, but at least M$'s File Properties has that ability, while Mac OS X's "Get info" does not.

R C-R wrote:

staff (a group consisting of all the admin users on your machine)

Minor correction(?): At least on my Mac, all new standard as well as admin accounts are created as members of the staff group (GID: 20). This gives standard users the ability to see (read) the root level folders of other standard & admin accounts (but of course not to open any of those folders that restrict read access to the owner).

Your right. My mistake.

R C-R wrote:
Either way, other users with additional folders at the root user level and/or nested folders with permissions they have intentionally changed or added should be wary of using the recursive Terminal commands (those with the "-R" option) to set all subfolder permissions alike or to remove all of their ACL's.

This reminds me of an old saying: +sudo doesn't kill OS's, users who enter their admin password do+ 🙂

R C-R wrote:
the missing ACL for the Drop Box added (if either or both occur for others)

This ACL isn't added for upgrade installs or migrated users. Only new users created by Leopard.

R C-R wrote:
Given all this, I think someone, ideally Apple, should create a little utility that at least reports any non-default permissions or ACL's it finds in home folders, much like Disk Utility's Permissions check does for many items outside of the home folder. A 'repair' feature would be trickier but just knowing what's non-standard would be useful.

Agreed.

petrock,

Thanks a lot for your post on this!

However, I'm having problems entering the commands that contain <your username>.

I just get:

chmod: Unable to translate '<star-affinity>' to a UID/GID

or

-bash: star-affinity: No such file or directory

Is it because I have a - in my username?

I remember it refused to enter - in the username when I first started up my computer (from clean install of OS X) but then when I created a new account in System Preferences -> Accounts it was ok to use - in the username.

You think this has got anything to do with it? My hyphen in the username?

Let me offer two fool proof versions of petrock's commands-

For-

sudo chown -R <your username>:staff ~/

instead use:

sudo chown -R `id -u`:`id -g` /Users/`id -un`

For-

sudo chmod +a "<your username> allow list,addfile,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directoryinherit" ~/Public/Drop

instead use:

sudo chmod +a "`id -un` allow list,addfile,search,delete,add_subdirectory,delete_child,readattr,writeattr,readextattr,writeextattr,readsecurity,writesecurity,chown,file_inherit,directoryinherit" ~/Public/Drop