Why is a user's home directory owned by their UID and not their short name?

Question

Level 1

14 points

Why is a user's home directory owned by their UID and not their short name?

Some time ago we upgraded from Leopard Server to Snow Leopard Server. Along the way I missed the warning/note about some authentication changes, and therefore ran into problems creating new users. Upon creation of a new OD user and trying to create their home directory I received an error. Through this community I was led to an Apple support article that described re-kerberizing the server. I ran that last night and lo and behold... success! New users AND new home directories.

Came in this morning and had one of the new users login. Beauty! Second user... d'oh! Third user... d'oh! For the sake of argument we'll call these users:

newuser1 (UID 1298)

newuser2 (UID 1300)

newuser3 (UID 1301)

The names have been changed, but the UIDs are real. Yes, I know they're not sequential. I created a bad user account as 1299 and deleted it.

Running "ls -al" in the folder with all of the home directories yields something like the following:

drwxr-xr-x    12 1295       staff    408 Aug 25 08:12 newuser1
drwxr-xr-x    12 1300       staff    408 Nov  3 17:22 newuser2
drwxr-xr-x    12 1301       staff    408 Nov  3 17:22 newuser3
drwxr-xr-x+   16 olduser1   staff    544 Oct  6 16:19 olduser1
drwxrwxrwx+   26 olduser2   staff    884 Sep 16 11:42 olduser2
drwxr-xr-x+   22 olduser3   staff    748 Apr 29  2011 olduser3
drwxr-xr-x+   16 olduser4   staff    544 Mar  8  2011 olduser4

A quick eye will notice that the home directories are not owned by the short user name for the new users. A quicker eye will notice that newuser1's UID does not match the UID of their home directory owner! The weirder part is that newuser1 is the one that doesn't get an error on login!!!

Just to try something I ran "chown -R newuser1:staff newuser1/" and was given the following reply:

chown: newuser1: Invalid argument

I'm so lost! Where else do I need to look? Why doesn't the server recognize the short names of these new users? I can use an old user's name as a parameter in chown.

Any ideas on how to fix any of this? Any and all assistance is always appreciated!

Posted on Nov 4, 2011 7:31 AM

Reply

Answer 1

Nov 4, 2011 11:55 AM in response to JWells

Try:

chown -R newuser1:staff /Users/newuser1

Do you possibly have matching short-users in the local directory and in the OD directory?

I'd consider starting over; if you've been hacking and slashing here for a while, then it can be more expedient to nuke and pave and reload and get DNS services working and then get OD working and then start reloading users.

Reply

Answer 2

JWells Author

Level 1

14 points

Nov 4, 2011 1:35 PM in response to MrHoffman

I ran the command on the volume where the home directory is located. The error that I received was not about the file path argument to the command, it was about the short user name that I was trying to use with the group staff. Be that as it may, I tried your suggestion and re-ran the command using the /Full/path/to/newuser1 and received the same result.

There are no matching names in the local directory. The only local accounts are for services/daemons and an administrator.

Starting over is not an option. I have too many users and, quite frankly, I'm terrified at the prospect of having to reconnect each home directory to the proper new user when that's precisely the problem that I'm having right now.

Thank you for your reply and your promptness. Often my questions go unanswered in any way shape or form. Any other thoughts?

Reply

Answer 3

Nov 8, 2011 5:08 AM in response to JWells

First a bit of background to help clarify terminology.

Your using Open Directory to define user accounts, Open Directory is based on OpenLDAP which in turn is based on LDAP. LDAP has three fields which help identify a user account. These are

cn (aka. Common Name)

uid

uidNumber

cn typically contains a users full name e.g. Fred Smith

uid contains a users shortname e.g. fsmith

uidNumber contains a unique integer number e.g. 1300

Now Mac OS X and Linux are derived from Unix (technically Mac OS X is a real version of Unix) and Unix before LDAP used to use a text file called /etc/passwd containing three similar identifiers for each user although in the password file the unique number field was here called UID whereas in LDAP it is called uidNumber, hence a possible confusion.

See http://www.cyberciti.biz/faq/understanding-etcpasswd-file-format/

So from a Unix perspective when looking at POSIX file permissions, it is right to say a file or directory ownership is defined based on the UID field, but from an Open Directory perspective it is actually owned based on the uidNumber field but they actually in reality mean the same thing.

The reason things are owned based on the number and not a users shortname is that back in the days of /etc/passwd file use it used to be much easier to change a users shortname, and even now, it is possible in Open Directory for a single user account to have multiple different shortnames all of which would be linked to a single unchanging uidNumber value.

So the command

sudo chown -R shortname directory

actually tells 'Unix' to lookup shortname find the matching UID (or for LDAP uidNumber) and set the directory and its contents to be owned by that account.

Since the directory will be owned by a 'number' it will not matter which of perhaps multiple shortnames the user actually logs in as since each shortname will match the same number.

By the way

sudo chown -R shortname directory/

with a trailing / is not necessary, that is the trailing slash is not required although it should do no harm.

Reply

Answer 4

JWells Author

Level 1

14 points

Nov 8, 2011 7:12 AM in response to John Lockwood

John,

Thank you for that extremely detailed and thorough explanation. It's all good information, but does not address my issue.

In my question I asked why a directory listing in the home volume showed new user's home directories as owned by their numeric UID/uidNumber as opposed to their shortname. I believe it's related to the reason why when I tried to use chown on those directories, the server responded that the shortname I was trying to use was an invalid argument.

Looking at that directory listing there should be nothing wrong as the UID/uidNumber does match what's in the directory for those shortnames. However, the new users are unable to login. Again, the other symptom is that the server does not recognize the user's shortname as a parameter to a command.

Any other thoughts?

Reply

Answer 5

Nov 8, 2011 7:45 AM in response to JWells

A file or folder will typically show just the number as the owner when the account that used to own it has been deleted. Because the file or folder is owned by the number not the shortname, when the matching account is deleted the operating system can no longer lookup the number to find the matching name to show, so it then can only show the underlying number.

This is suggesting in your case that accounts 1295, 1300, and 1301 have been deleted. It suggests that (using your example text) accounts olduser1, olduser2, olduser3 and olduser4 still exist.

Apart from the possibility the accounts 129 etc. no longer exist, another possibility is that if you have two servers, and this is showing on a second server which is not the OD Master, that this second server has lost its connection to the OD Master and hence can no longer lookup the account. If this is happening on the OD Master itself then that might indicate a more serious problem with Open Directory itself.

Reply

Answer 6

JWells Author

Level 1

14 points

Nov 8, 2011 7:55 AM in response to John Lockwood

Therein lies the issue! Those users had not been deleted. They had, in fact, only just been created! The server that is exhibiting this behavior is the OD Master and that's why I'm confused/concerned.

I forget exactly in which thread I saw it, but I ran across something that mentioned wonky OD behavior being solved by "recreating" the replica tree by demoting and promoting replicas. I did that and magically, the folders are now owned by the user's shortnames again. I don't understand why this would have corrected the issue on the master.

Logins work now, and the issue appears to have gone away. However, issues that resolve without an explainable solution tend to worry me. If this issue comes back will recreating the replica tree fix it again? If so, what's the real root problem here? I'm at a loss to answer that question, but at least new users can access the system.

Reply

Answer 7

Nov 8, 2011 8:23 AM in response to JWells

It would be worth checking which OD server is being shown in Workgroup Manager. It could be the replica, or the OD Master. On the OD Master itself if it shows as /LDAPv3/127.0.0.1 this means the loopback address which means itself.

You could while checking things deliberately select the other address i.e. on the master select the replica, and vice versa, to compare what gets shown. When things are bad you will see a different list of accounts because they are no longer in sync.

Similarly check via the Directory Utility to see which server is listed first, the one listed first is the one that gets used first for checking accounts, if it was a bad replica rather than the master that might explain things. Remember this applies separately to each server, the replica could have itself listed first.

I have had someone comment to me that while trying to mix say 10.5 with 10.6 is absolutely verbotten in terms of trying to make a replica, that trying to mix say 10.6.5 with 10.6.8 is also a bad thing, i.e. they should both be identical versions.

Anyway I am glad to here it is working again. I advise checking the health of the replica in Server Admin over the next few days and then rechecking the view in Workgroup Manager of both as a further check.

Reply