I had done an update to my system 2 days ago but not rebooted or logged out/in.
Today we had a power outage and of course that forced a restart.
When I attempt to log in I get a failed authentication on the plymouth login screen.
I tried using a text screen to log in and can do so as root, but not as my regular user.
My regular user gets the authentication failure message when trying to log in that way.
I tried creating a new user with adduser and that user also gets the authentication failure message when trying to log in.
I have tried resetting my password but there is no change in the issue.
I also performed a restorecon -R / to reset selinux context on the entire system and have tried setting selinux to permissive with setenforce 0 but that also has had no effect.
Does anyone have an idea where I may look for changes that would prevent a regular user from logging in but still allow root to connect via text screen login?
There may be some hints in journalctl such as fsck running for a long time on first boot after the power hit.
Living in an area prone to hurricanes and winter storms, a UPS has largely eliminated unsafe shutdowns, so all my practical experience with unsafe shutdowns is in the distant past. I do recall having to restore the last full backup followed by nearly a month of daily incremental backups, all on a robotic tape library with a constant stream of users asking when the system would be back.
Do the users run the same shell program as root? Is there garbage in any of /etc/passwd, /etc/shadow, etc. rootâs entries are usually at the start of these files, so might have escaped corruption affecting the entries near the end of the file.
No corruption seen on any of the files
I watched the boot process and it successfully ran fsck during the startup
Just for assurance I repeated the fsck on /home with fsck -f and no errors are reported.
I also cannot ssh into or out of that system with either password or my usual key.
The only clue I can find in journalctl I am unable to cut&paste since I have no way to get the data to my other system.
I have selinux in permissive mode and I see an audit message that reads something like msg='op=PAM:accounting grantors=? acct=ME exe="/usr/bin/login" hostname=.... adr=? terminal=/dev/tty4 res=failed'
The line immediately before is similar with op=PAM:authentication grantors=pam_unix with res=success
and the line following is from login with the authentication failure
That one also looks fine. It is the âlocalâ profile, which you can verify with authselect current. Previous Fedora releases would select âsssdâ as the default profile.
Your /etc/authselect/system-auth looks like what I have on 2 desktop systems. I recall some changes related to pam a couple moths ago, but wonât have time to investigate for a while.
The date shown with `ls -ld /etc/pam.d/system-auth is different than yours. I have Nov 14 while you show Oct 22.
I did updates on Nov 15 and Nov 17 and a distro-sync on Nov 11
I had rebooted on Nov 15 with no problems until the power outage today. So the suspect is something that was changed with my update on Nov 17.
I cannot provide the list of packages updated as text until I am able to use ssh/rsync to transfer the data.
It seems pretty obvious that something in that update caused this problem but as yet I cannot identify it. I wonât be upgrading my other 2 systems until after this problem is resolved.
Still no progress.
I have done a full dnf reinstall * after doing a dnf distro-sync as well as switching authselect between the sssd and local profiles yet any regular user is prevented from login.
ssh and rsync are prevented from operation as well, probably a result of the same issue.
This is the only related data I can find in the logs
Both entries above, the first on the local system and the second with a remote ssh attempt) clearly show that PAM (or authselect) is denying access even though I am 100% certain that the passwords are correct.
This is almost to the point that I am considering a full reinstall on my daily driver. Not a pleasant task with all the extras I have in use!
I did not. I had already run a forced fsck on the system and home partitions manually. The file systems are not mounting read-only.
The only errors seem to be failed authentication by any user other than root.
Keyboard layout is the same as it has been for years. I have even tried different keyboards, and the same keyboard will log me in as root but not as my other user.
Authentication Success, Accounting Failure: The logs consistently show "USER_AUTH res=success" followed by "USER_ACCT res=failed". This means the system successfully verifies the user's password (authentication), but something goes wrong during the accounting phase (which typically involves logging the login attempt and updating system resources).
It shows password is correct, but accounting failed
Pam.d? So something on accounting fails to log in user in
Got also possible idea systemctl status multi-user.target
It has been years since I have dealt with that file and its effects. Thanks tremendously for the reminder as that was indeed the issue.
The real question remaining is how that file was created though.?
I have no clue at this point.
We used to use that when preparing for an update on multi-user systems to keep the system idle during the update, but this is not one of those situations.
If the time argument is used, 5 minutes before the system goes down the /run/nologin file is created to ensure that further logins shall not be allowed.
