passwd/shadow or group/gshadow mismatch?
Why would you use Excel?
cut -d: -f1 /etc/passwd | sort > p.out
sudo cut -d: -f1 /etc/shadow | sort > s.out
diff p.out s.out
rm p.out s.out
Or in Bash:
diff <(cut -d: -f1 /etc/passwd | sort) <(sudo cut -d: -f1 /etc/shadow | sort)
and you can do the same kind of thing for /etc/group
and /etc/gshadow
.
You need to run GUI System>Administration>Users and Groups
with elevated permissions. Is it asking you for a password?
Related videos on Youtube
weak
Updated on September 17, 2022Comments
-
weak almost 2 years
I'm running RHEL 5. When using the GUI System>Administration>Users and Groups, I get the error:
The user database cannot be read. This problem is most likely caused by a mismatch between /etc/passwd and /etc/shadow or /etc/group and /etc/gshadow. The program will exit now.
Some research showed that I need to use vipw and vigr respectively to find an inconsistency between these two sets, which I did - to make it easy I copied each from [vipw | vigr] to an excel file and did =exact(%1, %2). There are no inconsistencies.
What gives?
// Edits //
sudo pwck -r yeilds several users without home directories:
user adm: directory /var/adm does not exist user news: directory /etc/news does not exist user uucp: directory /var/spool/uucp does not exist user gopher: directory /var/gopher does not exist user ftp: directory /var/ftp does not exist user pcap: directory /var/arpwatch does not exist user sabayon: directory /home/sabayon does not exist user oprofile: directory /home/oprofile does not exist user avahi-autoipd: directory /var/lib/avahi-autoipd does not exist
I assume this is normal for service accounts.
However, sudo grpck -r yields some interesting output (sanitized):
no matching group file entry in /etc/gshadow add group 'g0' in /etc/gshadow ?No 'u1' is a member of the 'g1' group in /etc/group but not in /etc/gshadow 'u2' is a member of the 'g1' group in /etc/group but not in /etc/gshadow 'u3' is a member of the 'g1' group in /etc/group but not in /etc/gshadow no matching group file entry in /etc/group delete line 'users:::'? No no matching group file entry in /etc/group delete line 'u4:!::'? No no matching group file entry in /etc/group delete line 'u1:!::'? No no matching group file entry in /etc/group delete line 'u2:!::'? No no matching group file entry in /etc/group delete line 'u3:!::'? No no matching group file entry in /etc/group delete line 'u5:!::'? No no matching group file entry in /etc/group delete line 'u6:!::'? No no matching group file entry in /etc/group delete line 'u7:!::'? No grpck: no changes
So, clearly we found some problems. It looks to me that automated repair would be destructive in some cases.
-
Dennis Williamson almost 14 yearsIt looks like you found your problem.
-
-
weak almost 14 yearsBecause it's what I know - Your way is definitely slick, but I needed a way to quickly and systematically find differences or prove that there weren't any. For me, Excel was that way. I almost facepalmed when I read your elevated permissions bit. I opened a console, switched to root via su, and then ran /usr/bin/system-config-users. Same error as before.
-
Dennis Williamson almost 14 years@Tony: run
sudo pwck -r
andsudo grpck -r
to show you any errors in these files. What do they say (summarize the result or add it to your original question). -
weak almost 14 yearsI answered yes to all of the delete requests from grpck, and now the GUI works. Hopefully users don't call :)