KJK555 wrote:
I agree, using SL install DVD would be a better choice for dealing with the old "jay" directory.
That actually could be done as the last step.
I would still delete and replace the old jay account though.
Unfortunately, simply changing the UID has broken accounts in my experience.
Chances of getting by without problems by not copying the new basic files to the old
account are good. If you have a bootable or time machine system backup, using migration
assistant to import user account settings would probably be the best bet.
Unfortunately there is no really easy way to replace a corrupt account (if it is indeed corrupt).
there is nothing wrong with the OP's account at the moment. all he wants is to change the UID from 502 to 501 to align with a bunch of files currently owned by UID=501 on various disks. I thought that deleting and recreating the user would work to do this quickly provided it would automatically give the recreated user UID=501. as it doesn't want to do that it's best not to touch it and change the ownership on all those other files instead. that's easy to do on the extra drives. it can also be done on the whole system drive using find but I'm not sure what the exact consequences would be. that's why i didn't want to do it.
I have had the best luck with migration assistant or tediously rebuilding the user directory
from a backup, manually (ouch). One way to preserve your old mail and other apps settings
is to simply trash their directories from the new account before copying over to the old
account. What ditto doesn't see, ditto won't copy.
"sudo dscl . -delete /Users UniqueID 501" is just an extra step that probably won't do anything
the command syntax is wrong and won't do anything as far as I can see.
anyway unless the old account is corrupt. Deleting an account using the system preferences
should completely eliminate the account UID, if it doesn't then there probably is corruption.
again the account is not corrupt so this isn't an issue.
Re creating the account should take care of any temp directory problems.
yes, which is why I wanted to do it that way first too. the problem was the deleting and recreating the account gives the old UID back.
Actually, an OS re install may be needed to straighten it all out.
Personally, I have solved the "unknown user" and "runaway ACL" problem long ago.
I disable (remove) UID 99 and use the old "tiger" (10.4.x) permission structure
(user ID = 501 - Group ID =501):
I would never do that. there is no reason or point in going to the deprecated Tiger group structure. while it's not needed here I've changed a lot of accounts (and helped others do the same) with Tiger group structure to the new system using the first method I suggested earlier in the thread by deleting and recreating the accounts and never had any problems with any of them.
uid=501(kj) gid=501(kj) groups=501(kj),402(com.apple.sharepoint.group.1),204(
developer),100(lpoperator),
98(
lpadmin),81(_appserveradm),80(admin),79(_appserverusr),75(_sshd),74(mysql),
61(localaccounts),50(authedusers),12(everyone),4(tty),401(com.apple.access_scree nsharing)
Since I have been using the above permission structure, (10.5.2), I have only had the main user
directory crap out on me once, and that was because of a keychain problem.
