Password auth failing randomly on Lock Screen

[sepulworld]

Anyone else having this issue. My computer will go into the lock screen. I entered the password which I know is 100% correct but it says authentication failed. I'll try multiple times.

Eventually reboot the computer and things are fine after that.

Issue will happen again after some random amount of time (days or weeks for me).

I'm on a Beelink SER 8

[petarm]

I have just faced the same issue.

[aneksz]

This happens to me on login as well, not only the lock screen. After several attempts, it eventually works. I've disabled the idle lock completely for the same reason, as it was happening on the lock screen too.

[dotsilva]

I faced a similar issue, but it was in terminal, i knew it was the correct password, but it failed, so i typed it in plain text and ctrl+shif+c / ctrl+shift+v it and still failed. Then i restarted the laptop and it worked again.

[aneksz]

My issue is the encryption, it seems to get corrupt for some reason. Since I'm using a PC and not a laptop, I've installed a fresh minimal copy of Arch, without the encryption and then installed Omarchy. Which disables the need for a password login, and loads Omarchy automatically.

[sepulworld]

What service is in charge of idle lock? Maybe we need to check issue tracker there

[sepulworld]

Looks like hypridle. Maybe there are some clues in the logs

https://wiki.hypr.land/Hypr-Ecosystem/hypridle/

Hopefully the reboot doesn't clear the logs. Assuming systemCTL controls it. So logs should be there. I'll dig around and see if I find anything.

[aneksz]

I've changed this line in hypridle.conf inhibit_sleep = 3 to 0 which disables it. I've also stopped hypridle from starting in the hyprland.conf just in case.

[mlive1992]

I also have the same issue and it is happens on both lockscreen and terminal randomly for me!

[sepulworld]

Let's document how to turn up trace or debug mode on hypridle and hyprlock. Then if we all flip it on, maybe we'll catch some information in the logs after a reboot.

[paul-fornage]

I had this happen once too, but I use Omarchy on 3 machines all day, so it can't be common. I actually had someone else try the password and they failed too. Fixed after a nervous reboot.

Have not had it happen in terminal/sudo

[dotsilva]

The random failing happened to me today again and while typing the password very carefully something came to my mind "what if for some reason it is trying to read the Enter as part of the password and because this it fails?" i have not the technical knowledge to investigate, but i would like to contribute my 2 cents with this hypothesis. Anyway, it is not something that happen very often and the reboot fixed it each time.

[mrdrbrdr]

I Think i know why This happens. What language have you mapped to your keyboard?

I’ve mapped Danish to laptops keyboard, but when I’m either on lock screen or the Linux booting from a USB, it is consistently mapped to English.

this results in special characters not being consistent, and hence your pc won’t accept your password

[paul-fornage]

I thought of this too, but I am on US only, and it still doesn't explain the inconsistent nature of the problem.

If everyone else has international keyboards, I won't rule out me being slow in the head or some other problem in my case, but I don't think this is the case.

[dotsilva]

I Think i know why This happens. What language have you mapped to your keyboard?

I’ve mapped Danish to laptops keyboard, but when I’m either on lock screen or the Linux booting from a USB, it is consistently mapped to English.

this results in special characters not being consistent, and hence your pc won’t accept your password

It is possible too, but not because of the English part. The thing is my "kb_layout" is "br" and i am used to use caps:lock instead of shift while typing password, but in Omarchy defaults the caps key is compose for emojis, so it is possible, at least in my case.

[jcarlosbecker]

Having the same problem...waiting for solution....

[topazrn]

I experienced this problem immediately after restarting my system following the upgrade to v3.0.1. I was also unable to log in on the second TTY. To rule out a keyboard layout issue, I typed my password in the username prompt and confirmed it was not the cause. A subsequent restart resolved the problem, and I am now able to log in successfully.

[dotsilva]

In my case was the caps key, confirming the theory commented above! Yesterday i was failing the login password, so i typed carefully and it still failed, then i decided to test this and instead of caps look i choose shift for caps letters and it worked, but i would like to say i made a mistake in my other comment, the caps thing is not from my keyboard layout, its because i changed it from the emoji stuff to caps:lock and when the system decides to use the defaults, it comes to its default emoji thing and my password fails, so, at least for my case, this mystery seems to be solved.

[cellexec]

Also have this problem. Currently i've disabled it, til we know how to fix it... :/

[cellexec]

BTW! I might figure it out.... 🎉

My password has multiple symbols or uppercase letters, that need to press Shift. However if multiple symbols/letters in sequence use the Shift key, it sort of get "consumed".

What does that mean?

Imagine your password is:

Password!!

Pressing Shift(and hold it) for both !, this password becomes:

Password!1

So to make it work, I needed to hold & release the Shift key for each symbol/letter again.

Hope this helps :)

[mjschlot]

This solved it for me. If I lifted the shift between each character requiring shift, then I could login.

[AV3RG]

The caps lock or shift key is not the issue, my purely alphanumeric passwords are also failing

[michal1024]

Hi all, I just had the same problem. Omarchy 3.1.7 on a desktop. I locked the screen, came back after few hours and could not log in. I switched to terminal and could not log in either. I was able to log in as root though. I changed user's password with "passwd username" and tried to login again - still no luck, neither in tty nor gui. I assume that excludes keyboard layout, capslock or password mistakes.

After reboot I was able to log in normally. I can't find anything in the logs, journal just says:
Nov 17 22:07:02 hal hyprlock[128381]: pam_unix(hyprlock:auth): authentication failure;

omarchy-debug log: https://0x0.st/Kf14.log

[AshishKapoor]

Happened with me just now. Only restarting the machine helped.

[baptleduc]

I faced the same problem today as well and had to reboot

[clement-bramy]

I can confirm this is still (?) happening, I've had omarchy 3.1.7 for 3 days, and I has happened quite a few times. It also seem to happen when password is requested during package install (so might not be related to lock screen only?).

[Riddlerrr]

This sounds like a wring keyboard layout issue. Check to see if it is correct or try switching

[clement-bramy]

If that was a keyboard wiring issue wouldn't I notice it while typing? I write a lot of code, I would probably have noticed that?

Unless I'm missing your point.

[Riddlerrr]

Did you add a second language keyboard layout to wayland config? Like EN and FR, for example
If yes this can be your issue else the issue with something else. It was just my guess based on limited data

[clement-bramy]

I only have one keyboard layout (US), and yes I understand it was just a guess :) I'm just trying to give as much information as I have.

As I have installed omarchy recently, I install a lot of stuff to setup my laptop, so I'm guess that is why I am probably more exposed to the "auth" issue.

[DFanso]

Have the same issue on the lockscreen

[FilipUllsten]

Same issue here

[dhh]

I've adjusted the pam.d such that it'll reset the faillock counter on reboot. You can run the changes on your own account if you want to test if this helps your setup:

sudo sed -i '/pam_faillock\.so preauth/d' /etc/pam.d/sddm-autologin
sudo sed -i '/auth.*pam_permit\.so/a auth        required    pam_faillock.so authsucc' /etc/pam.d/sddm-autologin

Now on every reboot, the counter should be reset, so hyprlock should not be failing to unlock.

[ColtonIdle]

this happens to me because i mash on my keyboard to wake up my screen. would be nice for a plain ol' enter key to not actually try to hit the password checker. instead it should no-op so you can wake up the screen

[avelkov]

There is an option in hyprlock to ignore enter unless there is a password. general { ignore_empty_input = true } I’m pretty sure I’ve not had the issue since setting that.

On November 25, 2025, Muhammad Haroon Arshad ***@***.***> wrote: this happens to me because i mash on my keyboard to wake up my screen. would be nice for a plain ol' enter key to not actually try to hit the password checker. instead it should no-op so you can wake up the screen

— Reply to this email directly, view it on GitHub <#1469 (comment)- 15077731>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AHF3V3IPCXSJU3R7GUSXDX336SCPNAVCNFSM6AAAAACFX6T7KWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMBXG43TGMI>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[moesy]

I have the same issue and similar to @AshishKapoor only rebooting helps.

[moesy]

Thanks @rsd. After stepping away for about an hour, it unexpectedly started working. These were the (accidental) steps that made it work:

- Entered a blank password
- Let it fail
- Entered the actual password
- Success

It is not obvious to me why stepping away for an hour would suddenly make it work or why entering the blank password by accident first would unblock it. However my machine is now about to log in.

I've experienced this issue a few times now and will update here if this workaround works again or if it was a fluke.

[rsd]

that's the point most people are failing to understand in this thread.
pam's faillock is active by default in arch.
It is suppose to lock a user out after a few wrong passwords.
This is to avoid someone with physical access to your machine to try to guess your password or remote services (e.g. sshd).
It can be configured in the /etc/pam.d/* files and the command:
faillock --user <your user's name> --reset reset it if you lock yourself out.

[sepulworld]

What is the timeout on this mechanism? Instead of rebooting how long do you have to wait until you can attempt a retry? Would be nice to bubble up this timer to the prompt somehow.

[rsd]

take a look at:

cat /etc/security/faillock.conf

and

grep faillock /etc/pam.d/*

as always, the docs:

man pam_faillock

[moesy]

@sepulworld in my case the default is 3 password fails in 15 minutes and a 10 minute lockout.

I've had scenarios where I went 8+ hours and still could not login without rebooting but in my most recent experience on 3.2.2 password worked as expected when I came back after an hour. I think there might be multiple things happening and it also looks like various fixes were added to 3.2.2.

I'm not convinced that I put in the wrong password initially however that may have been a separate issue that was since fixed.

[mcdent]

This is surely fixed now in the latest version??Sent from my mobile device. On 3 Dec 2025, at 19:41, Moe Sy ***@***.***> wrote: I have the same issue and similar to @AshishKapoor only rebooting helps. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[moesy]

My issue was as of 3.2.2

[AshishKapoor]

This is surely fixed now in the latest version??Sent from my mobile device. On 3 Dec 2025, at 19:41, Moe Sy @.> wrote: I have the same issue and similar to @AshishKapoor only rebooting helps. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.>

I am not noticing this on v3.2.2

[karatekaneen]

I thought that I also encountered this error but it was actually this where the password had been set with another language than the one I was using.

Might be the case for some of you here as well

[kgn]

Update: running faillock --user $USER --reset fixed this me. The other issue I ran into is that I must have messed up my sudo password when I first setup Omarchy, I reset it and now my login and sudo passwords are different. My login password works on the login screen (after reset), but my sudo password works on the lock screen. So if anyone else has accidentally set their sudo password to something different than their login password they will not be able to "login" on the lock screen because it expects the sudo password.

---

I am running into this too. If I leave my computer and it gets to the password screen there is nothing I can do except restart, and then the same password works on that login screen.

For me, it is 100% failure, I cannot log back in with out rebooting.

[czlowiek488]

Omarchy 3.2.2 issue still exists.
Pressing Ctrl+alt+F2 and then Ctrl+alt+F1 works for temporary workaround.

[karatekaneen]

Are you using some other than the default keyboard layout? If so, take a look at my other reply in the main thread

[tighthead3]

I ran into this issue today (happened in past as well) - correct password rejected on hyprlock, had to reboot to fix it. I had CC review and fix it

Root cause: PAM faillock. I saw 8-9 failed attempts before my correct password stopped working. My habit is to hit spacebar to wake the screen, then backspace to clear any input before typing my password. Without ignore_empty_input = true, those spacebar presses were being submitted as empty password attempts. Once I hit 10 failures, faillock kicked in and locked me out.

Fix (by Claude AI):
Added ignore_empty_input = true to the input-field section in ~/.config/hypr/hyprlock.conf:

input-field {
...
ignore_empty_input = true
}

This prevents empty/accidental key presses from counting as failed password attempts.

Also added a recovery alias in case it happens again:
alias unlock-reset='faillock --user $(whoami) --reset'
If locked out, switch to TTY (Ctrl+Alt+F2), log in, run unlock-reset, then return to the graphical session without rebooting.

[AV3RG]

This AI slop is not the reason why the bug is happening, please stop posting anything that an LLM provided you!

[avelkov]

The ignore empty field solution is valid, whether provided by ai or the manual reading of hyprland docs. Since implementing this a few weeks back I have not had the issue repeat itself.

On December 8, 2025, Muhammad Haroon Arshad ***@***.***> wrote: This AI slop is not the reason why the bug is happening, please stop posting anything that an LLM provided you!

— Reply to this email directly, view it on GitHub <#1469 (comment)- 15199822>, or unsubscribe <https://github.com/notifications/unsubscribe- auth/AHF3V3KOOFREHZUUKGCKNSD4AWSTTAVCNFSM6AAAAACFX6T7KWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJZHE4DEMQ>. You are receiving this because you were mentioned.Message ID: ***@***.***>