Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#67644 - [pam][pambase] Locked out after one wrong password attempt

Attached to Project: Arch Linux
Opened by Robert Balent (RobertBalent) - Thursday, 20 August 2020, 07:24 GMT
Last edited by Levente Polyak (anthraxx) - Saturday, 22 January 2022, 02:51 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
David Runge (dvzrv)
Levente Polyak (anthraxx)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 39
Private No



After latest pam update I'm being locked out of the account after only one wrong password attempt. It shows that I reached limit of 3 wrong password attempts and that I should wait 10 minutes.

I didn't modified any configuration and I never enabled account lock after wrong passwords.

This seems to be related to fprint package. I have fprintd daemon disabled and don't have any fingerprints configured. But it seems like it's started anyway? After uninstalling it, I'm being locked out of the account after 3 wrong password attempts.

So there are 2 issues:

1. Why is this behavior enabled at all? I never enabled it.
2. Why I'm locked out after 1 wrong password attempt when fprint is installed?


I'm using Gnome and default Gnome login screen.

Package versions:

pam 1.4.0-3
pambase 20200721.1-2
gdm 3.36.3-6
systemd 246.2-1

Log file attached.
This task depends upon

Closed by  Levente Polyak (anthraxx)
Saturday, 22 January 2022, 02:51 GMT
Reason for closing:  Won't implement
Comment by Trit' (trit) - Thursday, 20 August 2020, 15:09 GMT
Same for me: I just locked my XFCE session once, today, and XScreenSaver would not let me type my password, and trying to log in in a TTY console did not work either. I had to log in as root (for the very first time since I have installed Arch on this PC, in July 2016!) and reboot the PC to be able to open my XFCE session again. Luckily, I did not have opened files at this time, so no unsaved data was lost. But for people who had such unsaved important files… :/

I’d say that, when being on a personal PC and not a professional server, there is no need to set a limit to how many wrong attempts can be done before locking completely a user session. It’s the first time I have been locked out of my own PC, and I am not very happy about it.

EDIT: fprint is not installed on my system. I only have pam and pambase, which I have both updated today.

EDIT 2: last pam update added a new file: etc/security/faillock.conf. The 3 wrong attemps limits is stored there (3 is the default, even if the matching line is commented out), but I don’t know how to set it to “no limit at all”.
Comment by Trit' (trit) - Saturday, 22 August 2020, 08:55 GMT
Regarding to (wait, I sincerely think that that bug is related to this one): I have another PC that I just upgraded some minutes ago, ignoring pam and pambase updates. And you know what? VLC, Notepadqq (as samples of Qt5 softwares) run with the good Qt5 theme as defined by qt5ct. Therefore, I think that this pam update is also responsible for the bug in Qt5 applications (it’s really the only difference between my laptop, where pam was updated, and the desktop, where it wasn’t).

Please let that know in the forum, because I am not able to sign in there (the last question fails continuously, despite I am giving the awaited answer).
Comment by Rowisi (Rowisi) - Monday, 24 August 2020, 23:26 GMT
Not only login locked after 3 wrong attempts but also sudo is locked after 3 wrong attempts.

Not sure who and why did they do such a terrible change? Did they ask Linux users before doing such change?
Comment by nl6720 (nl6720) - Tuesday, 25 August 2020, 06:30 GMT
You can set 'deny = 0' in /etc/security/faillock.conf to disable the lockout feature.
Comment by patrick (potomac) - Tuesday, 25 August 2020, 09:10 GMT
I agree with Rowisi, this is a terrible change, "deny = 0" should be the default setting, in order to avoid these problems,

it would be interesting to see if other linux distros (ubuntu, fedora) will follow or not this default setting when they will switch to pam 1.4.0.
Comment by Trit' (trit) - Tuesday, 25 August 2020, 09:35 GMT
“deny = 0” fixed both the lockout and the appearance of the Qt5 applications for me! Thank you a million times, nl6720!!! \o/

PS: could you report this to the forum again, Robert? Because despite of what V1del thinks, there clearly was a link between pam’s bug and (my, at least) Qt5 bug. And set this “deny” parameter to 0 in /etc/security/faillock.conf fixed everything. It could be good to know, don’t you think? Thank you.
Comment by Jiri Valnoha (waldauf) - Tuesday, 25 August 2020, 13:13 GMT
I have the same problem. Solution 'deny = 0' helped me. But in case I would like to have a locked system for some time after X failed logins so it will not work. I think this is an error that should be fixed.
Comment by Jonathan Kotta (jpkotta) - Friday, 28 August 2020, 17:39 GMT
@Jiri Valnoha (waldauf) you can just set `deny = X` for whatever number X of failed attempts you want. Default is 3. 0 is special, meaning infinity. I think 3 is an aggressive default, and probably too low, but it's not really an error because it's working as intended.
Comment by Lukas Sabota (punkrockguy318) - Friday, 28 August 2020, 19:37 GMT
I think a change in behavior like this warrants some type of notification. This is a pretty disruptive change for people that often mistype their password. "deny = 3" in faillock.conf is a questionable upstream pam default - and if Arch is going to stick with the upstream behavior, I think that the new behavior should be communicated in a package postinstall message or the arch home page.

It's just very confusing for this to happen without notice.

edit: rephrased
Comment by Trit' (trit) - Saturday, 29 August 2020, 11:56 GMT
It’s me, again…

So, I updated pam and pambase on my other Arch PC, I have edited “/etc/security/faillock.conf” to set “deny = 0”, and… I did not work, this time. XScreenSaver showed me a big “Authentication failed!” after I have tested if everything was OK (it wasn’t). After a reboot, VLC (Qt5 app) is not using the good theme (Fusion, the default Qt5 theme, instead of gtk2, as defined in the “QT_QPA_PLATFORMTHEME=qt5ct” variable in “/etc/environment”), except if I run it from a Terminal.

Both PC configurations are the same, pam-related files are identical on both machines, so I don’t know what to do to fix that…
Comment by Henry Nelson (hcnelson99) - Saturday, 29 August 2020, 15:42 GMT
As a further workaround before the default is set to deny = 0, you can unlock an account with "faillock --user $USER --reset"
Comment by Peter Ross (peterross) - Friday, 11 September 2020, 08:29 GMT
I had the same problem, of being completely locked out after the update and got back in to investigate by using the Arch install media. I tracked the problem down to the fact that the update had removed the PAM tally2 module, now that faillock does that work. My config had used tally2 in /etc/pam.d/system-login to count login fails and enforce a login delay after three failures. I commented out those lines where they occurred; problem cured, for me, without changing the defaults in faillock.conf
Comment by Levente Polyak (anthraxx) - Friday, 11 September 2020, 11:11 GMT
locking after 3 wrong attempts is a quite sane upstream default that i don't see why it should diverge downstream. If people are not happy because they mistype frequently then just configure it. This is not post install message material, it simply belongs to the Arch Wiki and that is fully open for contribution.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 13:49 GMT
@anthraxx It would be okay if it was 10 by default but 3 is just too low. The default settings must always be for general users who probably don't mess with /etc. At work or at universities we mistype passwords very frequently and its very common to type the wrong password for computers that are not ours. Linux is no longer for developers only, It has became a general OS for all kind of people to use and 99% of people will not be happy about this.
Comment by Doug Newgard (Scimmia) - Friday, 11 September 2020, 14:03 GMT
Rowisi, I think you're forgetting what distro we're talking about. "general users who probably don't mess with /etc" are not Arch users.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 14:08 GMT
@Scimmia Manjaro users aren't Arch users too? Won't this affect them?

So, if Debian does some breaking changes, won't that affect Debian based distros too?
Comment by Doug Newgard (Scimmia) - Friday, 11 September 2020, 14:13 GMT
No, Manjaro users are NOT Arch users, nobody here cares one bit how it affects Manjaro users.
Comment by Rowisi (Rowisi) - Friday, 11 September 2020, 14:25 GMT
@Scimmia These changes aren't Arch fault either. Linux-pam are doing it, lets just hope they won't change it to 1.
Comment by David C. Rankin (drankinatty) - Saturday, 12 September 2020, 03:01 GMT
The problem is:

# The default is 900 (15 minutes).
# fail_interval = 900

So any 3 wrong passwords in a 15 minute period of time will lock the box according to the faillock.conf. So if you accidentally type a wrong password on login. Type a wrong password with sudo 10 minutes later. and then 4 minutes after than type a wrong password with sudo again -- you are locked -- even though you never had 3 failed passwords at any one prompt. This may be a bit too rigorous for home user use.

It looks like if you are a member of some group, you can stop it from locking by treating that group the same as root with:

# admin_group = <admin_group_name>

The 3 in 15 minutes by default will catch a lot of people. There should be a way to limit it to 3 in 15 minutes at a single prompt. That would be much better than any 3 fails in 15 minutes.
Comment by Allen (allencch) - Saturday, 12 September 2020, 05:21 GMT
The problem I faced was when xscreensaver was activated, but I didn't enter the password for some time. Then the account is locked for 15 minutes. Only after 15 minutes, I can only unlock the xscreensaver.
Comment by Rowisi (Rowisi) - Saturday, 12 September 2020, 06:57 GMT
Even though it is so easy to change the configuration, I try as much as possible to not mess with /etc files and stick to default configurations and the reason is that if breaking changes happen I don't want it to save as s *.pacnew file and then I will have to use a live usb and mount partition to fix it.
Comment by John (graysky) - Saturday, 12 September 2020, 12:29 GMT
@Allen - Same. Switching to xfce4-screensaver here solved that issue for me. Only applicable if you're running xfce4 obviously.
Comment by Olav Seyfarth (nursoda) - Saturday, 12 September 2020, 22:23 GMT
There are TWO issues: [1] defaults (personally I agree that 3 in 15' is hard, should be reset on success) and [2] something's triggering this despite of NOT 3 false attempts. Let's focus on that, please: Today, I pressed the power button on my laptop, sending it to sleep. After a while, I pressed power button again to wake it, and ended up with a SDDM login screen WITHOUT password entry field or any possibility to do anything (on that graphical terminal). Background image was there, but the usual password field was missing. So I switched to another text terminal, found out about the lockout (I had not, if I hadn't changed to text console), and killed the screenlocker (since I didn't know "faillock --reset", thanks hcnelson99). As a workaround I set deny=0, but what caused it in the first place and why did this not hit us before?
Comment by loqs (loqs) - Saturday, 12 September 2020, 22:59 GMT
@nursoda pam_tally / pam_tally2 recorded failures but the default configuration did not take any other action.
There were also limitations in when pam_tally2 could record failures, the tallylog was only acessible by root so none root authenticating services such as screenlockers would error attempting to access the file and failures would never be recorded.
It could also be an issue in the pambase changes or an issue in the pam_faillock module itself.
Comment by Olav Seyfarth (nursoda) - Sunday, 13 September 2020, 00:41 GMT
Understood, and appreciated. For the record: In my case, pam_tally2 is not even installed. So, as this hits users (not only admins), who is able to investigate the cause and what evidence is needed to do so? Personally, I never really got into the whole pam mechanism, and I'm not trying to. All I wanted to do here is to refocus that this [A] should not happen (yes, we may blame the upstream update) and [B] that this does NOT ("only") happen when entering a wrong password three times in a row. So, discussion about 3 or 10 Minutes default is out of scope for this bug.
Comment by loqs (loqs) - Sunday, 13 September 2020, 02:01 GMT
pam_tally and pam_tally2 were deprecated in the pam 1.4 release and not built by default. The suggested replacement in the upstream release notes [1] is pam_faillock.
pam_faillock is not a drop in replacement for pam_tally / pam_tally2. pam_tally / pam_tally2 used a single call [2] while pam_faillock takes at least two [3]
this was one of the reasons for the pambase 20200721.1-2 changes that accompanied the pam 1.4.0-3 update.

Has anyone experienced the issue when there has been no GUI active or at least no GUI with a login or authentication prompt?

Comment by Tobias Mädel (Manawyrm) - Wednesday, 16 September 2020, 18:19 GMT
This is an absolutely insane default. It is not acceptable at all as the default configuration, even less so as a regular system update.

HID events are also triggered by other devices like wireless headphones (in my case), which often emit spurious events/keypresses.
In my case, xscreensaver was activated multiple times by the HID input from the headphones and caused a 10 minute lockdown of my machine, which I had to fix with a reboot from a VTY.
This caused a small amount of lost data because the computer was logging measurements while I was away.
Comment by David Rosenstrauch (darose) - Thursday, 17 September 2020, 13:59 GMT
@Manawyrm I was experiencing that as well. I would close the lid on my machine, then come back to it a few hours later, only to find that I was locked out for the next 10 minutes. I wound up setting 'deny = 0' in /etc/security/faillock.conf to disable this.
Comment by Chris Billington (chrisjbillington) - Sunday, 20 September 2020, 07:23 GMT
I've locked myself out a bunch of times and don't really know why. It's definitely not from actually entering my password wrong.

I have also wondered if it might have something to do with suspending my laptop whilst sudo is prompting for a password. Or perhaps whilst yay is running with the sudoloop option, and is waiting for (non-password) input. Haven't figured it out, but will be setting deny=0 until such a time this no longer occurs with defaults.
Comment by rainer (raneon) - Wednesday, 07 October 2020, 15:47 GMT
I've been locked out of my systems now multiple times too and I'm not sure why. Almost out of nothing my password is not accepted anymore.

On my laptop it happened after suspend and I'm pretty sure I didn't type the password 3 times wrong withing 15 minutes.

On my servers I see this issues too, and I believe it is somehow related to the cockpit ssh bridge. But it doesn't make sense as my user password is accepted during the login to the cockpit dashboard and would be correctly forwarded to the other cockpit machines.
Comment by M (mjr) - Sunday, 25 October 2020, 01:04 GMT
This just affected me. Got locked out with some work open. Thankfully I forgot to disable the root account on this newish install so I could get back in and set "deny = 0" without waiting or losing work.

This seems like a pretty bad default.
Comment by rainer (raneon) - Sunday, 25 October 2020, 10:10 GMT
This is still affecting my systems. I'm getting constantly locked out when using cockpit on my servers. Can we please get a fix or at least a proper advise how to fix this?
Comment by Kerrick Staley (KerrickStaley) - Thursday, 29 October 2020, 04:44 GMT
rainer: Based on previous comments, the fix is to set "deny = 0" in /etc/security/faillock.conf and raise the issue with PAM upstream if you think the default behavior does not make sense. PAM's page is at It looks like they have a mailing list that you can register for at .
Comment by rainer (raneon) - Friday, 30 October 2020, 23:24 GMT
Kerrik: I'm aware about this workaround, thanks. I would like to know how Arch Linux as a distribution will address this. I'm not in a position to tell the pam developers how to do their job as I'm just a normal user that is affected by this issue without knowing any details.
Comment by webdawg (webdawg) - Wednesday, 11 November 2020, 22:52 GMT

Archlinux is the exact opposite of what you are talking about.

Though, why wasn't a change like this posted in the news? I was surprised also. I guess I could see why....
Comment by rainer (raneon) - Wednesday, 11 November 2020, 23:21 GMT
webdawq: As a long time Arch Linux user I'm fine with doing setups during installation or when changes are necessary so that my systems fit my needs. But this is about a changed behavior where a normal upgrade broke several functionalities. Hence I did request that there is some communication. Not every user is always aware about all the details and has the time to figure it out for himself. Especially if the bug cannot be linked directly to one package as it is not obvious. So I still have the expectation that if something breaks we communicate openly and that there is then some form of communication (news/wiki, ...).

So let me quote the link you've posted:
"It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. All users are encouraged to participate and contribute to the distribution. Reporting and helping fix bugs is highly valued and patches improving packages or the core projects are very appreciated"
Comment by Trit' (trit) - Wednesday, 18 November 2020, 10:08 GMT
The new version 1.5 has finally fixed my problem with Qt5 applications not having the good theme in XFCE on one of my PCs (cf. It was a bug in pam_env’s code.
Comment by Tobias Mädel (Manawyrm) - Friday, 26 March 2021, 22:03 GMT
This just happened to me again and it caused a lot of confusion (especially as "sudo" can't handle this gracefully and won't show a notice/error message).
It's an insane default for a Linux system and is very unexpected to happen on any distribution.

Comment by Greyson Christoforo (greyltc) - Saturday, 17 April 2021, 19:16 GMT
On my system, sudo password prompt timeouts seem to be incrementing the faillock counter. That seems to explain unexpected lockouts.
Comment by Spencer Harmon (spencerharmon) - Friday, 14 May 2021, 01:53 GMT
Joining in the chorus of "please don't break my thing" if I didn't enable faillock, it's because I didn't want it.
Comment by Martin Sandsmark (sandsmark) - Sunday, 27 June 2021, 10:18 GMT
Attaching a patch against the pambase package fixing the issue (the issues are caused by changes arch does, not modifying any upstream source).

Also not requiring systemd_home by default anymore either (search the BBS for why that is a good idea I guess).

pam_faillock also has an undocumented built-in delay, so passing nodelay to pam_unix doesn't work anymore (nor editing /etc/login.defs).

pam_faillock is obviously not ready for default deployment, IMHO, there's way too many issues and undocumented and unexpected behavior.
Comment by loqs (loqs) - Sunday, 27 June 2021, 13:00 GMT
@sandsmark are you going to open an upstream bug report or pull request for the undocumented built-in delay?

Is the issue you are referring to with systemd-home the journal message? If so the module can be added to Noextract, pam will then skip it.
Or you could open a feature request against the systemd package asking for the module to be split out.
It it is some other issue please provide a link or preferably use FS#65819.

Does anyone have a reproducible case for the lock out after single attempt? If so please report it upstream.
Comment by Alexandre Sicard (libricoleur) - Friday, 27 August 2021, 15:44 GMT
This keeps happening to me time and time again on every Arch system I lay my hands on. People have complicated passwords. People mess up their typing. Blocking the whole account for 15 minutes without any warning after just 3 failures is *not* an acceptable default.
Comment by David Rosenstrauch (darose) - Friday, 27 August 2021, 15:51 GMT
Edit /etc/security/faillock.conf and put a "deny = 0" in there and this problem will go away. Yes, I also question whether this is a smart default setting. (Depends on how paranoid you want to be about security.) But it's just that - a default setting, and one that you can easily override. If you don't like it, change it.
Comment by Alexandre Sicard (libricoleur) - Friday, 27 August 2021, 16:27 GMT
Thank you @darose. This is what I have been doing on the systems I manage, but there is always that one machine where I forgot to do it and then it bites me again. It is really terrible when you are in the middle of some work and the only thing you can do is wait 15 minutes or reboot, and it can happen quite easily with sudo.
Like many other people in this thread I believe this is not a good default behaviour, hence I am asking for it to change. It would be a bit better if sudo did not increment the counter, at least.
Comment by Trit' (trit) - Saturday, 28 August 2021, 10:25 GMT
Was it not fixed in v1.5? I thought it was only on v1.4…
Comment by David Rosenstrauch (darose) - Saturday, 28 August 2021, 12:51 GMT
@libricoleur I can understand your thinking that this is a dumb default value. But wasn't this an upstream change? Arch usually ships with upstream defaults. So I'd think that the place to push for a change would be in an upstream bug, not here.
Comment by Jeff Hatfield (nomasteryoda) - Tuesday, 21 December 2021, 14:49 GMT
I know this has been a stale discussion, but this is something the security world sets. Given that standard of 3 fails followed by lock, I would reason that Red Hat pushed for this obnoxious change. Normal folks using their computers shouldn't have to worry about this kind of security and the standard security idea of "if it is not in your possession, it is already too late" holds here.
Comment by eternalfloof (eternalfloof) - Friday, 31 December 2021, 11:41 GMT Comment by Philipp (hollunder) - Wednesday, 12 January 2022, 09:14 GMT
The upstream bug has been closed and they say it's Arch's fault and Arch's responsibility to provide a different config.
Please do, this has severely tripped me up on several machines. The main problem is that there is no indication as to what is going on, login is simply not working as if the wrong password was entered.
Comment by Greyson Christoforo (greyltc) - Wednesday, 12 January 2022, 09:28 GMT
I've just filed a new issue for PAM,
I have a feeling that solving this would go a long way to preventing the problems people are seeing here. I'm fairly sure this is the only reason I keep getting unexpectedly locked out.
Comment by Philipp (hollunder) - Wednesday, 12 January 2022, 16:10 GMT
Thanks Greyson, this would help a bit maybe, but not solve the general problem.

I would like the default configuration to disable the lockout or at least significantly increase the number of attempts.
I guess 10 attempts would be more reasonable. It is easy to reach three attempts via fat finger, caps lock, forgot which pw is used on the given machine or for various other reasons.

The other big issue is the lack of feedback, for me as a user it is a silent lockout. I do not know whether that is solvable by Arch though.
Comment by Leo P. (jpegxguy) - Thursday, 20 January 2022, 21:34 GMT
I just bumped into this. Really annoying, and silent in sudo's case, so you don't know what's wrong. At least in the login prompt it tells you.

deny = 0 should definitely be the default on arch at least

or does it have to do with the fact that I autologin?
Comment by Levente Polyak (anthraxx) - Saturday, 22 January 2022, 02:51 GMT
Arch Linux does not distinguish different flavors for servers, workstations or other specific subsets. We provide sane and secure default setups, however components itself remain vanilla configuration. The user base is expected to be able to configure their environment as desired to deviate from upstream defaults as they please.
If a particular installation is deemed to be a workstation and meant to be setup "less paranoia" then its upstream provides a sufficiently easy way to do so plus we provide specific instructions in the wiki how it can be adjusted to meet personal needs.