fprintAuth in greetd suddenly enabled even after disabling it in my config

Help
1

Hello! In my configuration.nix, I have this line:

security.pam.services.greetd.fprintAuth = false;

It is intended to make greetd ask for a password instead of asking for fingerprint authentication. It has always worked up until I did a rebuild-switch one day, and now it asks for my fingerprint when logging in. Another important detail is that I have this exact setting for swaylock, but it correctly ignores the fingerprint authentication. Below is the list of relevant generations– 195 has the old, intended behavior and 196 ignores setting greetd.fprintAuth to false.

~ ❯ sudo nix-env --list-generations --profile /nix/var/nix/profiles/system
 195   2026-07-25 18:51:28
 196   2026-07-27 09:13:33   (current)

I used the nvd tool (temporarily installed with nix-shell -p) to see the differences between the versions:

[nix-shell:~]$ nvd diff /nix/var/nix/profiles/system-{195,196}-link
<<< /nix/var/nix/profiles/system-195-link
>>> /nix/var/nix/profiles/system-196-link
Version changes:
[U.]  #01  btrfs-progs           7.0 -> 7.1
[U.]  #02  cubeb                 0-unstable-2026-07-16-lib -> 0-unstable-2026-07-25-lib
[U.]  #03  deno                  2.9.3 -> 2.9.4
[U*]  #04  freetube              0.25.0 -> 0.25.1
[U.]  #05  initrd-linux          7.1.4 -> 7.1.5
[U*]  #06  level-zero            1.31.0 -> 1.32.0
[U.]  #07  libdisplay-info       0.3.0 x2 -> 0.4.0 x2
[U.]  #08  linux                 7.1.4, 7.1.4-modules x2 -> 7.1.5, 7.1.5-modules x2
[U.]  #09  nixos-system-tpt14g5  26.11.20260723.e2587ca -> 26.11.20260726.624af66
[U.]  #10  ostree                2026.1 -> 2026.2
[U*]  #11  tailscale             1.98.8 -> 1.98.9
[U.]  #12  vpl-gpu-rt            26.1.6 -> 26.3.0
[U.]  #13  xfsprogs              7.0.1, 7.0.1-bin -> 7.1.1, 7.1.1-bin
Closure size: 2252 -> 2252 (105 paths added, 105 paths removed, delta +0, disk usage -148.7KiB).

If it also helps, I am on the unstable branch. As of writing, I haven’t tested switching my flake inputs to the stable one and I will make an update when I do. I am curious, what exactly changed that cause the functionality of that line in my config to cease to work? Was it the kernel change? Any pointers would be super helpful!

2

Update, I switched my flake inputs from the unstable branch to NixOS 26.05 and created a new generation. As expected, greetd correctly prompts me for my password instead of my fingerprint.

Where do you yall think I should go from here? Should I just deal with having to sign in with my fingerprint instead of my password, or is there a solution that will allow the line in my configuration.nix to work while letting me stay on the unstable branch?

3

One solution to try is using lib.mkForce to override it to false. Of course, there’s probably a reason that something is enabling that, so no promises this won’t break something. (Alternatively, maybe something has changed so that this option isn’t being used anymore, in which case that wouldn’t matter.) I’ll dig into the code a bit and see if I can easily find what changed.

Update: My guess is that this PR was the one that broke you, which would mean the above wouldn’t be effective. I’m not sure what a fix would for your config would look like.

4

I suspect what’s happening here is that the login service, that the greetd service now substacks, is the PAM stack invoking the finger print auth. To change that you’ll want security.pam.services.login.fprintAuth = false; instead.

Alternatively you can disable the rules that substack login though I’d recommend against that for the same reasons that PR changed the previous behaviour. Most PAM modules that need to run during system login are in that service stack and substacking it is the way the linux ecosystem as a whole generally expects this to be handled.

If you just dont want to use the fingerprint reader ever you can instead disable the whole thing with services.fprintd.enable = false;. That will take fingerprint during login away as well as any other “use fingerprint by default when available” type things.

2 Likes
5

Hey, I replaced my old line with security.pam.services.login.fprintAuth = false; and the behavior is restored to normal, thank you so much for your time!

And @GraysonTinker thx for linking the pull request so I could read what happened. Going forward, I will also be sure to read them if any other breaking changes occur.

1 Like