Sharing & Permissions unknown user

right. the point is that your user has UID=502 for some reason and not 501. the first user created always has UID=501. the next 502 and so on. that's why i said that you must have created a new user or changed UIDs in the past. did you? perhaps, you used Migration Assistant and then deleted the originally created user?
do you have any other users on the computer beside teh guest account? if there are no other users you can do the following. create a new admin account. log out of the account jay and log into the new admin account. go to system preferences->accounts. unlock the lock at the bottom. control-click on the account jay and select "advanced options". in the resulting popup change the location of the home directory (it should currently be /users/jay) to some nonexistent folder. just type in /users/jayb or something. click ok. then use the minus sign to delete user jay. it will delete it but will leave the old home directory /users/jay along because it's no longer associated with user jay. then use + to recreate user jay. make sure to give it the same short user name jay and use the same password. you'll get a popup saying that a home directory by that name already exists and asking if you want to use it. say YES. this will recreate that user and will give it UID=501 which is currently unoccupied. this should give you the ownership of all those folders currently listed as being owned by _unknown.

rats! I was afraid of that. this means that some traces of the user with UID 501 were not erased. we can change the UID of your current user to 501 but it's trickier than you might think.
also, it actually just occurred to me that the temp admin user you made may have gotten UID=501. could you check that please. run

id username

where instead of username put the short name of that temp user. what UID is listed there?

ok, now we finally see what's going on. your user name is jay, right? and you must have changed users in the past, I'm guessing you created a new user and deleted the old one? this indicates that this file is owned by user with UID=501 which no longer exists and you get rights to this file via ACLs. there are various ways of dealing with this. we can change the UID of your user to 501. or we can try changing the ownership on all those files on all the drives involved. that could be inconvenient but could be better than changing the UID. what exactly do you have on all those drives? is it just data? do any of the drives contain any TM backups or user home directories? are any of them boot drives?

KJK555 wrote:
If you want to find and change the unknown user you can do it with the find command:

sudo find /Users/jay -user _unknown -exec sudo chown jay: {} ;
#this will find files with "_unknown" user (UID) and change them
to user "jay" in your home directory#

why would you use that instead of

sudo chown -R jay /users/jay

also, as I said, the actual user _unknown with UID=99 is not involved at all here. what's involved is the deleted user with UID=501 which shows up as "unknown" in finder GUI. the command line still lists it as 501 and not _unknown.
as i mentioned before one could use find to change all files everywhere currently owned by UID=501 to 502 but I'm not sure of the consequences and hence hesitant to do it on the system drive.

You can change "/Users/jay" directory to whatever directory you want to search in
and change the user. To change owner to something other than "jay" just change
"jay:" (after chown) to some other user name.

example:
sudo find /Users/george -user _unknown -exec sudo chown george: {} ;

Kj ♘

If you want to find and change the unknown user you can do it with the find command:

sudo find /Users/jay -user _unknown -exec sudo chown jay: {} \;
#this will find files with "_unknown" user (UID) and change them
to user "jay" in your home directory#

You can change "/Users/jay" directory to whatever directory you want to search in
and change the user. To change owner to something other than "jay" just change
"jay:" (after chown) to some other user name.

example:
sudo find /Users/george -user _unknown -exec sudo chown george: {} \;

Kj ♘

something is wrong with your directory services record then. please run this in terminal and post the results

id

where exactly on the hard drive are such files located?
please select one of the files in question and do the following.
open terminal and type

ls -ladeO

in the terminal window. do not press enter yet. press space. then drag the file with the unknown user to the terminal window.
the result will look like this

ls -ladeO /path/to/file

press return and post the results please. this will list the current permissions on the file.

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).
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
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.
Re creating the account should take care of any temp directory problems.

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):

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.

All my data volumes and disk images now use the following permission structure (root directory):
user=root, group=admin, chmod=1775 or 775.
Disk image ownership behavior changes requires a modification to the disk image framework's
/System/Library/PrivateFrameworks/DiskImages.framework/Versions/A/Resources/defa ults.plist
file so that disk mages will mount with owners enabled and act like (simulate) a hard drive
volume's permission structure. Once modified, disk images make great backup media for
faithfully and accurately backing up OS clones using CCC (carbon copy cloner).

Runaway ACl's are generally caused by incorrect group permissions in the /Applications directory.
All apps should have group set as "admin". Apps in your ~/home/Applications directory
though are excepted. They normally belong to the user. Whether the "unknown user" can
cause ACL problems in SL, I don't know, but in 10.5.x, ACL problems were sometimes accompanied
by "unknown user" troubles. So far SL has squeaked by with much fewer ACL issues than 10.5.x.

Kj ♘

Hi V.K.:

The "sudo find /Users/jay -user _unknown -exec sudo chown jay: {} \;"
is just an example. I would not actually use that on the home directory,
although it would work, but it would not change any other files/directories
with improper ownership such as "root", it would only change files/directories
with "_unknown" ownership, which does make it desirable for fixing data drives.
A person would be wise to, beforehand to use only the find portion of the command
to locate potential files that need changing:
"sudo find /path/to/file -user _unknown" will find them nicely.
Actually "sudo find /path/to/file -uid 501" may work better for the OP.

Yes, I was a bit off on my syntax on dscl
this would be correct:
sudo dscl . -delete /Users/test_account UniqueID 501
followed by
sudo dscl . -delete /Users/test_account
(it takes both commands to wipe out all account info).

Of course since the OP named his new test account the same as his old test account,
that is probably why he has no access to and cannot release user ID 501, so I definitely
don't recommend using dscl before fixing the account name conflict.

In fact the best way fix account problems is through Apple's GUI program Workgroup
Manager (in the server admin toolkit). Now that I use WGM so much, I've gotten rusty
using dscl. dscl is pretty crude compared to WGM. Remnant account info will show up
in WGM and dealing with it is easier. Changing names and user account info is a snap
in WGM and much less likely to "brick" the account than with other methods.
http://support.apple.com/kb/DL968

Just my personal opinion, but I don't see any practical use for the "_unknown user"
account, and if it causes a security problem or something else, I haven't been able to
verify it. I find that can cause confusion and complexity in dealing with actual file ownership.

Kj ♘

1st, backup your system (if you haven't already done so).

Login to your new (503) admin test account.

Open System Preferences > Accounts.
Delete the "jay" account.
Close.

In terminal:
sudo dscl . -delete /Users UniqueID 501
#if there is any remnants of group 501, this will get them#
next
sudo mv /Users/jay /Users/jay_old
#rename jay account to jay_old#
next
sudo chmod -R -N /Users/jay_old
#remove any ACl's from the old jay account#

Open System Preferences > Accounts.
Create a new "jay" account.
#make sure the new account UID is 501 and short name is "jay",
Control click on account, click advanced options to set#

Log out - login to new "jay" account
in terminal
id
#should show account ID as 501#

if all is Kosher
Logout - login to test account again.

in Terminal:
sudo ditto /Users/jay /Users/jay_old
#copies new generated basic account files to old jay account#
next
sudo mv /Users/jay /Users/jay_new
#rename new account-to be deleted later#
next
sudo mv /Users/jay_old /Users/jay
#rename fixed "jay" account#

Should work now, your basic user preferences will be set at default
values though, you will have to customize them again.

Kj ♘

This is NOT how I would do this. first, deleting user jay in system preferences without further preparation will delete or rename its home directory. you just can't do it as is without saying something. this will overwrite many preference files with default values. NOT a good idea for many files. for example, for Mail that would delete all current email accounts. also I think

sudo dscl . -delete /Users UniqueID 501

is wrong syntax and won't do anything. and the main reason I'm reluctant to go this way is because that changing UID by hand does not address some things. in particular, the user temp directory will be owned by the old UID. this can mess things up. this can be dealt with but there also may be problems with sharing as some sharing preferences won't be updated and I don't know how to deal with those.
But if one does go that way then I would suggest the following method.
1. log out of the account jay and log into a temp admin account.
2. go to system preferences->account. unlock the lock, control-click on user jay and select "advanced options". change the UID from 502 to 501 in the popup.
then run the following in terminal

sudo -RN /users/jay
sudo chown -R jay:staff /users/jay

3.then boot from the SL install DVD and use the password reset Utility to reset permissions and ACLs on jay's homedirectory.
4. then reboot and log in as jay and run the following in terminal

cd $TMPDIR/..
sudo chown -R jay .

the last command will change the ownership on the temp directory of user jay to align with the new UID.

but as i said, those may still lead to some issues so it might be better to change ownership on all other drives to jay and leave the UID=502 as is.

Message was edited by: V.K.

Hi KJK 555

KJK555 wrote:
Hi V.K.:

The "sudo find /Users/jay -user _unknown -exec sudo chown jay: {} \;"
is just an example. I would not actually use that on the home directory,
although it would work, but it would not change any other files/directories
with improper ownership such as "root", it would only change files/directories
with "_unknown" ownership, which does make it desirable for fixing data drives.
A person would be wise to, beforehand to use only the find portion of the command
to locate potential files that need changing:
"sudo find /path/to/file -user _unknown" will find them nicely.
Actually "sudo find /path/to/file -uid 501" may work better for the OP.

yes, that would work. it actually also understands "sudo find /path/to/file -name 501"

Yes, I was a bit off on my syntax on dscl
this would be correct:
sudo dscl . -delete /Users/test_account UniqueID 501
followed by
sudo dscl . -delete /Users/test_account

the first command is redundant. the second will delete the user. but in the OP's case it's not necessary because the user with UID 501 can be deleted via GUI.

(it takes both commands to wipe out all account info).

no, it doesn't. the second command is all you need if you use dscl. the first simply deletes the UID entry in that accounts directory services record. it's superseded by the second command.

Of course since the OP named his new test account the same as his old test account,
that is probably why he has no access to and cannot release user ID 501, so I definitely

I don't understand what you mean. he created one test account that got UID 501. then he created another test account (with a different name) that got UID 503. then he deleted the first test account using GUI. that should have released UID 501. then he deleted his main user that had UID 502. then he recreated the main user and it again got UID 502. I don't understand why this happens. same or different user name should make no difference here. i just did the same procedure as an experiment. I have deleted an account with UID=503. (I have accounts with UID=504 and 505). then i created a new user with a different name. it got the first available free UID which was 503. this didn't happen with the OP in the exact same situation and I don't know why.

don't recommend using dscl before fixing the account name conflict.

In fact the best way fix account problems is through Apple's GUI program Workgroup
Manager (in the server admin toolkit). Now that I use WGM so much, I've gotten rusty
using dscl. dscl is pretty crude compared to WGM. Remnant account info will show up
in WGM and dealing with it is easier. Changing names and user account info is a snap
in WGM and much less likely to "brick" the account than with other methods.
http://support.apple.com/kb/DL968

Just my personal opinion, but I don't see any practical use for the "_unknown user"
account, and if it causes a security problem or something else, I haven't been able to
verify it. I find that can cause confusion and complexity in dealing with actual file ownership.

as i said before "unknown" user is not really involved here. I don't understand why you keep bringing it up.


Kj ♘

glad to hear you've fixed it!

but be VERY careful using "apply to enclosed items".
NEVER use "apply to enclosed items on ANY system created folders, your startup drive or the time machine drive. That includes folders like your Documents folder, your Desktop folder etc. use it only on folders you made yourself. system created folders often have hidden ACLs and using "apply to enclosed items" on them will propagate those ACLs to everything inside and buy you a lot of trouble. this is why I never mentioned it as it can easily lead to trouble.
the terminal method I suggested earlier is a safer one (it does require using terminal of course ).

I would change the ownership on those other drives. but before we go into this what exactly do you have on them? are they boot drives? TM drives? you *should not* change ownership on any such drives. but for drives which are just used for storage you can run the following in terminal

sudo chown -R jay:staff /volumes/"volume name"

put the volume name in the command. KEEP the quotes. this will make your user the owner of everything on that drive. but let me repeat, do NOT do this for system or TM drives. only for data storage drives.