user and groups not displayed!!!!

[Sprint Unix Team]

I have a wierd problem. When I do a 'ls -l' or a 'll' the output shows the UID and GID instead of the user and group names. A sample output is below :
$ ll
total 618
drwxrwxrwx 2 0 sys 96 Apr 19 12:33 CDROM
lrwxr-xr-t 1 0 sys 8 Jul 14 2000 bin -> /usr/bin
drwxrwxrwx 2 0 sys 96 Apr 19 12:57 carbon
drwxrwxrwx 2 0 sys 96 Jul 14 2000 cdrom
dr-xr-xr-x 12 2 bin 4096 Mar 7 18:04 dev
dr-xr-xr-x 25 2 bin 6144 May 2 10:48 etc
drwxr-xr-x 24 121 users 1024 Apr 30 17:11 home
lrwxr-xr-t 1 0 sys 8 Jul 14 2000 lib -> /usr/lib
drwxr-xr-x 2 0 root 96 Jun 21 2000 lost+found
drwxrwxrwx 3 0 sys 96 Mar 22 12:04 ndm
dr-xr-xr-x 2 0 root 96 Jun 21 2000 net
drwxrwxrwt 6 0 root 4096 Oct 5 2000 netapp3
dr-xr-xr-x 33 2 bin 1024 May 2 11:41 opt
drwxr-xr-x 7 0 root 1024 Mar 22 12:12 opt1
dr-xr-xr-x 12 2 bin 3072 Jul 14 2000 sbin
dr-xr-xr-x 6 2 bin 1024 Oct 4 2000 stand
drwxrwxrwx 11 2 bin 8192 May 2 18:02 tmp
dr-xr-xr-x 2 0 root 96 Jun 21 2000 tmp_mnt
dr-xr-xr-x 25 2 bin 1024 Mar 22 12:04 usr
dr-xr-xr-x 20 2 bin 1024 Aug 15 2000 var
drwxrwxr-x 6 0 web 1024 Aug 15 2000 webstore
-rw-rw-rw- 1 0 sys 286720 Jul 17 2000 webstore.tar

Can anybody tell me the reason and solution for this???

[A. Clay Stephenson]

Check the permissions of /etc/passwd and /etc/group. You may not have read permission set for group and/or other.
If this is an NIS client, see if ypcat passwd
works.
Clay

[A. Clay Stephenson]

If appears that you can read the group file but not the passwd file; I should have looked more carefully.

[Sprint Unix Team]

I think the previous output is confusing. May be this is a better one..

sidorg@copper ~ : ls -al
total 18
drwxrwxrwx 6 121 users 1024 May 2 15:43 .
drwxr-xr-x 24 121 users 1024 Apr 30 17:11 ..
-rw-rw-rw- 1 121 users 2880 Apr 27 09:46 .cshrc
-rw-rw-rw- 1 121 users 358 Apr 17 15:43 .login
-rw-rw-rw- 1 121 users 763 Apr 17 15:43 .profile
-rw-rw-rw- 1 121 users 94 Apr 27 09:27 .rhosts
-rw------- 1 121 users 38 May 2 15:33 .sh_history
drwxr-xr-x 2 121 users 96 Apr 17 15:54 .ssh
drwxrwxrwx 2 121 users 96 Apr 17 15:57 BOX
drwxrwxrwx 2 121 users 96 Apr 17 16:00 bin
drwxrwxrwx 6 121 users 96 May 2 15:43 tmp

Hope this helps!!!

[A. Clay Stephenson]

Okay, same answer. The second column is the link count, that's ok. The next column is the uid (that's bad), the next column is the group that looks ok. You can read the passwd file.

Do an ls -l on /etc/passwd and check the permissions for group and other
or
Do the same ls -l as root; it the user mapping works it has to be the /etc/passwd permissions.

[A. Clay Stephenson]

Hi guys, I am making one silly assumption. You do have a passwd file? Have you run pwck?

[James R. Ferguson]

Hi:

On obvious (?) possibility is that user #121 (uid) has simply been deleted from /etc/passwd but his/her files left on the system. In this case, there is no way to translate uid to name.

Another possiblity is that someone miskeyed and 'chowned' the files and directories (recursively ?) to uid 121...although the times I've done this it's usually to something like "555" when I meant to 'chmod'...

...JRF...

...JRF...

[Sprint Unix Team]

ok. My problem is still unsolved. I compared the file permission with another system and appears to be the same.

I have the output for ls -l /etc/passwd as both root and a user
#ls -l /etc/passwd
-r--r--r-- 1 0 sys 2181 May 2 10:48 /etc/passwd

$ ls -l /etc/passwd
-r--r--r-- 1 0 sys 2181 May 2 10:48 /etc/passwd

[A. Clay Stephenson]

Curiouser and curiouser. This could be a NIS problem. Do you know if you are using NIS? It's unusual to map root with NIS but it is allowed. Enter the command 'domainname' and see it it returns anything. If it returns something meaningful then NIS is in play and we need to look there. You might also have a corrupt passwd entry. The search is linear so 1 bad entry could cause the name lookups to fail.
Try the pwck command to check the integrity of /etc/passwd; it's safe.

[Vincenzo Restuccia]

Try chmod 777 /etc/passwd.

[Thierry Poels_1]

uh? Vincenzo?
chmod 777 /etc/passwd ? that opens the door to everybody; anyone will be able to remove the password from anyone, including root.
I certainly do agree that /etc/passwd must be readable by anyone.
regards,
Thierry

[Sprint Unix Team]

Okay GUYS,
Here is the solution to the problem. Kill pwgrd daemon and do a restart - /usr/sbin/pwgrd. Iam not sure the exact location of this...

The reason for is (according to HP) when the /var filesystem is full, it corrupts certain files..

For more details do man pwgrd.

[A. Clay Stephenson]

Glad to hear it guys. I amazed that you didn't see other problems with processes which couldn't create tmp files in /var/tmp.

Just goes to prove, first thing do a bdf.

Clay