Background
I have a couple of Mac workstations at the office. One is used extensively for photo editing (CS4). At any rate, I’m trying to set up a new e-mail account.
The Symptoms
Even though I entered the new password correctly SEVERAL times, it never worked when “Remember password in keychain” was selected. I thought it was a fluke.
I tried setting it up again today. However, I spent almost an hour tracking this one down. I noticed that, after editing the account settings that a dialog window would appear and claim that it was not possible to save the settings. It claimed that the permissions on ~/Library/Preferences were not correct. I heeded it’s warning well.
The Investigation
I popped open my swiss army knife: AppleKey + Space “Terminal” [return]. There, I looked at the file permissions for
ls lah
Everything looked fine. The owner was the user, the group was the domain administrator. No anomalies-or so I thought.
The seemingly coincidental success with not using the “Remember my password in keychain” got me thinking; I tried to add a new item to the keychain. The login keychain. I was dumbfounded when greeted with the following message: “An error has occured. Unable to add an item to the current keychain… [Unix Permissions]”. What the heck was wrong? The owner is right, group is irrelevant, and the permissions mask was 600.
The Discovery
On a hunch, I did: “ls -leh” on a suspect directory. And there it was:
drwx------+
The + at the end of the permissions mask isn’t just for show. It’s not a sticky bit either. It’s the extended attribute for ACLs. Yes. Macs use ACLs. There’s almost no information about this online. You can get more information by using the man pages:
man chmod
And I saw it:
0 group:everyone deny delete
There was one other ACL for domain administrators. But this one was it. Macs, Unix, and Linux machines in particular typically use the write to temporary and copy-back method of writing files. It helps reduce corruption and in this case, probably enabled the system to run as long as it did without major incident. Sadly, with this technique, the final copy, which is actually a move, never completes successfully. The result is that preferences for “well behaved” applications fail to save. Keychain wouldn’t update either due to the same principle.
The Solution
You have to eliminate that one particular ACL in the ~/Library folder. Doing so enables you to write again. Denies always over-rule the allows.
chmod -R -a "everyone deny delete" ~/Library
Remember, I’m not responsible for what happens if you use that. Do your research and be sure yourself.
The Aftermath
Keychain now accepts new items. Mail now accepts new passwords. Preferences save without incident.
This entire episode was the result of ACL’s being improperly applied. I’m not sure how it happened but I do have a guess.
The Possible Reason
About a month back, we tried a tablet. It was a WaCom Bamboo tablet. The software was designed for CS3. We tried it with CS4. That was a mistake. To be fair, it never said it worked with CS4. It said CS3 and then stopped at that platform. I goofed.
CS4 became extremely unstable. Photoshop crashed many more times each day than normal. InDesign refused to open at all. Uninstalling the suite using the uninstaller and Adobe’s secret clean-up script (which told me that it took no action) did not fix it. I had to remove all the preferences that bore the mark of Adobe (anything with “adobe” in the name of the .plist file or folder). I reinstalled it and it worked as though it were brand new again (after updates).
However, this was not before I performed a “Disk Permissions Repair” as suggested by forums. This utility is located in your Applications > Utilities > Disk Utility under your Mac drive. I believe that doing this action resulted in the mis-placed ACL’s.
I hope this helps someone who is or has suffered this problem before.