The user password is incorrect but has not been changed

I use KDE Plasma. Last time during a package update via the Welcome app, the AUR did not accept my password when installing updates, even though I haven’t changed it recently. Logging in with Su, I changed my password to the old one. I then read that if the password request is interrupted for some reason with ctrl-c, then this can cause such an error. Is this really the case, and if so, what can be done in this case so that you don’t have to change the user password every time as root?

And it’s also true to a package update to certain packages can result in a linkage error preventing the password being verified with sudo.
Either that or I persistently manage to not type my password correctly till I reboot (don’t think so).

It seems that this is only a special feature of KDE, but it happened to me for the first time, even though I’ve been using Plasma for a while.

Running this command has helped me in the past faillock --reset

Thanks. I also read this somewhere on a forum. I was just wondering about the reason for this strange wrong password error, whether it is related to KDE or independent of the desktop environment, if anyone knows the answer to this. Although I have also read that this can be specifically a KDE error, I even read something similar years ago on KDE’s own forum.

I don’t think it is related to KDE. I have been using Linux for 6-7 years now and I have had this problem occur across multiple distros and desktop environments. Like you, I read the solution on some old forum a long time ago. I try to do some internal documentation as I learn things while using linux and this is just something I had written down.

It occurs sometimes when cancelling a graphical password prompt or when typing my password in wrong enough times. Sometimes letting sudo timeout will trigger it. I’m pretty sure it is usually a combination of these events in my case. These days it is pretty rare that I run into this. It’s been years since the last time it has happened.

I don’t know any exact cause for it though. Not to mention the whole faillock --reset thing doesn’t seem to be documented very well. At least, not in the sense that people not familiar with the issue will easily discover it. The best I can do for you is link you to a website that explains what the command does. For example: https://www.baeldung.com/linux/unlocking-account-failed-attempts.

It my opinion, it seems to be a low level linux thing. Perhaps it is configured at the distro level or maybe it is the default setting for some common package that many linux distros share, but most distros don’t change this default. That’s if it is even configurable. I’m not really sure and haven’t looked into it too deeply. This has just been my experience with the issue.

If you press Ctrl+C during a password request it counts as a failed login and increment the faillock counter.

You can of course modify the configuration to allow for a higher count.

The lock time is 10 minutes - after which the faillock counter is reset.

Edit the file /etc/security/faillock.conf to adjust to your preferences.

It has happened several times that during the update via the Welcome application, because the bandwidth of the mobile internet is low, so I am not at the computer when I have to enter my user password when updating the packages in the AUR, so a timeout occurs, and after a certain time the process is interrupted. However, in this case, I have not yet experienced that the next time I asked for a sudo password in the terminal, I would have received the message that the password I typed was wrong.

This is interesting because what you write is because sometimes I press ctrl-c when I check the updates within the Welcome application and it asks for the root password in the terminal to install, but I interrupt the operation due to the low battery level of my laptop, so not my own my own password is affected.

The error came up again, even though I obviously didn’t make a mistake when entering my user password three times in a row. The faillock --reset command helped. It is interesting that I have not yet experienced this issue in other distributions.