Permissions Hell

CubaMark · Oct 21st, 2003, 11:09 AM

"I have seen the Devil, and he is CHMOD."

A week or so ago I migrated one of our centre's staff from an iMac DV 500 to a new 1Ghz eMac (the one that didn't arrive DOA).

I'm sure there was a better way to do this, but I went for the straightforward route: Set up file sharing on the iMac, logged in from the eMac, and copied the entire User folder onto the eMac's desktop.

Next step was to create a new User account on the eMac which would become the new Admin user (the existing user account was downgraded at the end of this process to a non-admin account) and move the respective Desktop, Library, etc. folders into place under the new User, replacing the default ones created.

We are now in permissions hell.

Folders are locked which shouldn't be. Permissions for folders (like, "Desktop" and "Pictures") belong to the wrong user (or to the System). Things are very, very wrong.

I've run Disk Permissions a zillion times (once as Root for good measure). I've tried BatCHMOD to fix permissions. I've gone into the terminal and did the handy-dandy "sudo su / cmod -R username /Users/username" command.

Things looked like they were straightening out until late yesterday, when Safari discovered it couldn't download anything to the desktop ("Could not create file"). Turns out the "Desktop" folder had incorrect permissions ("system").

So - anybody wanna suggest a quick and easy fix to this mess? Certainly I can create another new user, but how do I keep permissions straight when I move the files to their new homes?

M

Script Kiddie · Oct 21st, 2003, 04:10 PM

I think you mean the chown command, not chmod.

Assuming user's short name is "fred" and home dir is /Users/fred and his group is "staff"

As root
1) cd /Users
2) chown -R fred.staff fred

Second thing to remember is you have to rename
fred's keychain.

cd /Users/fred/Library/Keychains
and rename the file to "fred"

PosterBoy · Oct 21st, 2003, 04:31 PM

For future reference, using an app like Carbon Copy Cloner might work easier and without the permissions issues that you have now.

--PB

CubaMark · Oct 21st, 2003, 04:48 PM

Chmod, Chown, Clown, Clod whatever - I was raised in a GUI, not the command-line!

But yes, I meant <u>Chown</u>

Thanks for the adjustment to the command, SK, that wasn't part of the hint that I picked up on one of the sites...

And PB, yeah, CCC - I guess I just think of it as a backup utility, as I haven't had to use it yet. I'll look into it on the next migration...

M

Moscool · Oct 21st, 2003, 07:43 PM

I recently migrated an iMac15 to a new iMac15 using carbon copy through a FW cable and one machine acting as a passive drive ('T' boot): it was a dream. Only problem was that the new machine needed 10.2.7 and the old one had 10.2.6. Meant I had to reinstall the system on the more recent machine, but it did it all by itself and things worked very smoothly from there on.

A side question on permissions: I am having problems with files in my shared folder when I repair permissions. I need to manually re-authorise read-write and/or reattribute an owner. Anything I can do when I run my weekly cleanup?

Script Kiddie · Oct 21st, 2003, 08:17 PM

	Quote:
	A side question on permissions: I am having problems with files in my shared folder when I repair permissions. I need to manually re-authorise read-write and/or reattribute an owner. Anything I can do when I run my weekly cleanup?

What sort of "repairing" are we talking about?
The Shared folder has different permissions than users because it has to allow everyone to write to it. In Unix-speak we say the sticky bit is set. You can always tell if a directory is sticky by observing a "t" at the end of the directory permissions string like so:

drwxrwxrwt 44 root wheel 1496 May 19 08:20 Shared/

whereas a normal directory like skiddie is not sticky, the last char is "x", not "t"

drwxr-xr-x 13 skiddie staff 442 Jun 22 11:34 skiddie/

Do you think now that the repair is breaking the sticky bit?

Moscool · Oct 22nd, 2003, 03:29 AM

Need to check. I'll follow-up on this thread next time it happens. Thanks.