View Full Version : Permissions Problems

04-07-2009, 12:31 AM
I think SuperDuper! hosed my permissions. I'll post what I posted to the Apple Discussion Forums (The full thread with replies is over here: http://discussions.apple.com/thread.jspa?messageID=9284464#9284464):

So, I just finished setting up a new installation of OS X 10.5.6, and the first thing I noticed was that Macintosh HD was showing up on my desktop with the Time Machine icon, along with my actual external Time Machine drive. So I started investigating what the problem is, and I eventually "solved" it by just pasting the icon file of the proper icon onto the Info Panel of Macintosh HD (although I suspect the cause of the wrong icon might have to do with the following problems). In the process of troubleshooting it, though, I discovered that the permissions for Macintosh HD included a user named "unknown." I had never seen this before, so I started researching it, and I came across this thread: http://discussions.apple.com/thread.jspa?messageID=8311599. So I did what V.K. suggested, and I came up with similar results to the other user after running "ls -ladeO /", so I ran:

sudo chown root:admin /
sudo chmod 775 /

It seems to have stopped the "unknown" user from showing up, but I have some questions as to whether it is actually fixed:

1) When I ran "ls -ladeO /" it showed group 501 like the user saw in that thread. I never had Tiger installed, which V.K. said is usually what creates that group; the iMac came pre-loaded with Leopard. Why was that group created to begin with, and is the group still present even after running that command? How can I get rid of it completely?

2) After running the "chown" and "chmod" commands, the permissions for Macintosh HD are drwxrwxr-x@. I have another Mac running the same OS in the house, and I checked the permissions on Macintosh HD, and they're drwxrwxr-t. What is the difference, and why is it different?

3) To see if the problem was more widespread, I checked the permissions on a number of random folders, and out of the few I checked, Macintosh HD:Library on the other Mac in the house lists: system - Read & Write
admin - Read & Write
everyone - Read only

For the Mac in question, it's:
system - Read & Write
admin - Read & Write
everyone - Read & Write

This makes me think that permissions on more things than just Macintosh HD and Macintosh HD:Library are screwed up. How can I fix the permissions on Macintosh HD:Library, and is there any way I can just revert all the permissions for all system-created folders on the machine to their proper settings? I know Repair Permissions won't do that. If not, is there a way I can check whether the permissions on any other folders are incorrect, and change them manually? What could have caused all this?

Thanks in advance for everyone's help.


04-07-2009, 01:14 AM
Where is SuperDuper! in all this, Jon? I'm certain we didn't "hose your permissions", since we don't change your permissions at all (and "Repair Permissions" in SuperDuper! is actually done by asking Disk Utility to do it).

Group 501 is the normal "1st user", and it gets created when you create an account (whose ID is also 501).

So... I guess I'm unsure of what you're suggesting SD! did!

04-07-2009, 01:49 AM
I'm sorry, I should have been clearer. I don't have any definitive proof that it was SuperDuper!, but it is a new installation, and SuperDuper! is the only thing I can think of that could have caused it. I looked at the log, and it mentioned something about "restoring permissions" (I'm not at that computer right now). Can you think of ANYTHING that could have caused this? I put so much work into setting it up the way I like, I can't bear to start over. And do you know why Disk Utility isn't repairing the permissions on /Library?

04-07-2009, 09:16 AM
SuperDuper! does not change the source drive, Jon -- and if you selected "Repair Permissions", as I said before, we ask Disk Utility to do it, and it does what it does.

I don't know why it's not repairing Library. But the "@" means there are EAs attached, likely a deny-delete ACL. You can see the ACLs by using the "@" option w/ls.