Fingerprint reader not detected on Linux

A fingerprint reader that is not detected on Linux needs a hardware and driver check before any PAM edits: identify the sensor, check libfprint support, then test fprintd directly. If your installed driver does not support that sensor, changing sudo’s authentication file cannot make it work.

Find out which layer is failing

“Not detected” can mean several different things: the machine cannot see a USB device, fprintd exposes no usable reader, enrollment is missing, or a particular application never asks for a fingerprint. Write down the exact command and message before trying a fix. A screenshot of an absent desktop settings option is less useful than a reproducible check.

For this diagnosis, keep the existing password authentication unchanged. There is no benefit in risking sudo access while you are still establishing whether the hardware works. Use your normal desktop account for fprintd tests so you do not accidentally inspect root’s enrollments instead of your own.

Identify the sensor with lsusb

lsusb
lsusb -t

The lsusb manual explains the device listing and tree view. Record the reader’s hexadecimal vendor ID and product ID, written as a pair separated by a colon. Those IDs are the useful comparison key; a generic vendor name or “fingerprint” label is not enough to identify driver support.

Do not filter the first listing to lines containing “fingerprint.” An unfamiliar label could be the sensor you need. Compare the full output with your machine’s hardware documentation. For an external USB reader, compare listings before and after reconnecting it; this gives you a concrete device to investigate.

If a USB reader does not appear, check its connection and the machine’s firmware settings before looking for a userspace fix. A missing entry does not prove the machine lacks a fingerprint sensor: some supported readers use SPI rather than USB. The transport matters when choosing your next check.

Match the exact device against libfprint

Open the upstream libfprint supported-device list and search for the exact USB ID, or the listed SPI identification for that transport. Do not assume that support for another sensor from the same manufacturer covers yours. The page separates transports and driver families.

Read the warning at the top: the list covers the development version. A listed sensor may need a driver newer than the release installed by your distribution. Check the installed package version and distribution release notes before concluding that a listed ID must already work on your machine.

Record the installed package versions

Use dpkg-query or pacman for your distribution. These queries inspect packages; they do not replace drivers or change authentication.

dpkg-query -W fprintd libfprint-2-2 libpam-fprintd

pacman -Q fprintd libfprint

A missing package is a different finding from an unsupported sensor. Install the appropriate distribution packages before continuing if the tools themselves are absent. Prefer the distribution’s supported update path; a random package with “fingerprint driver” in its name is not evidence of support for your device.

Ask fprintd, independently of sudo

fprintd-list "$USER"
fprintd-verify

These utilities talk to the fingerprint daemon over D-Bus. The fprintd manual documents the username behavior: list requires a username, while verify defaults to the current user. Record whether the failure concerns a device, an enrollment, a permission check or a scan.

The upstream fprintd manager interface distinguishes an empty device enumeration from an available reader. A “NoSuchDevice” error tells you that fprintd has no default reader to return; it does not, by itself, identify a missing kernel driver, a firmware fault or an unsupported chip. Combine that message with the hardware ID and package version.

If a reader exists but your account has no enrolled fingers, enroll one and verify again. Follow the prompts until enrollment completes; do not treat the start of enrollment as a successful match.

fprintd-enroll -f right-index-finger
fprintd-verify -f right-index-finger

Inspect service errors rather than guessing

On a systemd installation, inspect the service status and its logs after reproducing the failure. The commands below query the system service, not a similarly named user service.

systemctl status fprintd.service --no-pager
sudo journalctl -b -u fprintd.service --no-pager

The systemctl documentation describes status inspection; journalctl can restrict output to this boot and unit. Read the actual error before restarting anything. A stopped service observed between requests is not a complete diagnosis: the packaged service can be started through D-Bus when a client requests it.

If the message is about authorization, do not solve it by making device nodes writable to everyone. fprintd’s device interface uses PolicyKit for access control. Keep the error text and investigate the distribution’s session and policy setup. Changing permissions indiscriminately hides the distinction between access control and hardware support.

When verification works but sudo does not

A successful direct scan establishes a useful boundary: the reader, enrollment and daemon can work for that user. The next question is which PAM stack the failing application uses. Enabling fingerprint login in a desktop panel does not establish that sudo’s configuration uses the same authentication rules.

Inspect /etc/pam.d/sudo and its includes before adding anything. Test from an ordinary-user terminal with sudo’s cached authentication invalidated. If the reader prompt appears but recognition fails, record that behavior separately from an application that never invokes the module. Keep a working password path while making changes.

When the sensor is unsupported

If the exact sensor has no support in your installed libfprint and no applicable supported update, say that plainly in your troubleshooting notes. This machine’s current local fingerprint path is unavailable. Re-enrolling, adding PAM lines or repeatedly restarting the daemon does not supply an implementation for an unsupported sensor.

A useful upstream report contains the exact hardware ID, distribution, installed versions, reproduction command and relevant logs. Remove unrelated personal details before sharing logs. Keep the distinction between “not supported in my installed release” and “not listed upstream”; they give maintainers different information.

If your goal is approving sudo rather than repairing that particular reader, a supported external reader or a separate phone approval system changes the hardware dependency. The phone option uses Android’s sensor and signed approval over Tailscale; it does not add a Linux driver for the laptop’s chip. It still needs Linux PAM integration, an enrolled phone and a working password fallback.

Approve sudo without repairing this sensor

If the laptop’s chip is unsupported, Finger can use an Android phone’s fingerprint sensor for sudo approval over Tailscale. It leaves the unsupported reader unsupported, and it covers sudo rather than screen unlocking or Polkit dialogs. See Finger requirements and approval workflow, or browse the current software catalogue.