Hence we will not see any details of user in /etc/passwd file and i believe this could not be the reason since other directories and user/owner names a re properly displayed.
My question here is: how/when/why the numbers comes in place instead of user/owner name.
It's quite possible to have files belonging to users or groups with no corresponding entry in /etc/passwd or /etc/group, nothing prevents it. Anything with sufficient privileges can create files belonging to any ID and group whether represented by anything in passwd or group or not; those only control login permissions through the traditional login system.
touch this ; sudo chown 9999 this
All users and groups are just numbers anyway. If ls doesn't find matching entries in passwd and/or group it will just display numbers. As long as whatever login manager involved sets correct access permissions on login based on the relevant user and group numbers, and the numbers used internally and externally don't overlap, things can be kept consistent without knowing all names locally.
Thanks for the information!
As i said in my earlier note, all of the application users are maintained through LDAP. Since LDAP no users information are maintained in /etc/passwd file. However, if i create a file or diectory and it is having my name(owner name) and all other settings as normal. Almost all users have proper info on their files/dirs. Only few users having numbers as per my example and they are also LDAP.
Please clarify me and let me know if you need any other info from my end to clarify me.
Thanks for the info!
I thought the same but in my case, all user s are LDAP and not maintained locally. So how system determines that this user has been deleted and let represent the userid as number. And for your information, still many user directories/files are showing properly with userid/owner name in its properties.
It's abstracted behind the getpwent() call and its related calls, looks like:
GETPWENT(3) Linux Programmer's Manual GETPWENT(3)
NAME
getpwent, setpwent, endpwent - get password file entry
SYNOPSIS
#include <sys/types.h>
#include <pwd.h>
struct passwd *getpwent(void);
void setpwent(void);
void endpwent(void);
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
getpwent(), setpwent(), endpwent(): _BSD_SOURCE || _SVID_SOURCE ||
_XOPEN_SOURCE > = 500
DESCRIPTION
The getpwent() function returns a pointer to a structure containing the
broken-out fields of a record from the password database (e.g., the
local password file /etc/passwd, NIS, and LDAP). The first time it is
called it returns the first entry; thereafter, it returns successive
entries.
...
So ls doesn't reach in and grab login names from /etc/passwd manually, it just calls getpwent() from glibc, which is capable of getting login info from any valid sources. Finding no corresponding UID in either, ls just prints the UID/GID.
Didn't know getpwent() did that. That's a pretty good reason to use these functions instead of just parsing /etc/passwd yourself!
It seems the above is related to Linux anyways i believe thats a not a big deal here.
I am worried about why the ls is not listing the user name for specific ID alone and returns the user name for other files/directories successfully or why the getpwent() fails to retrieve this alone.