pcscd.service fails after resume from suspend/hibernate

Curly060 · 2026-01-19 11:16:16

Hi all,

I have a Nitrokey 3 which I use in conjunction with KeePassXC. This combination has been working totally fine until some weeks ago (can't say for sure, maybe Oct/Nov 2025).

I found the following error in the pcscd.service:

../ccid-1.7.0/src/ccid_usb.c:638:OpenUSBByName() Can't libusb_open(1/13): LIBUSB_ERROR_ACCESS

Further research showed that there was indeed a change in PCSC, see https://github.com/LudovicRousseau/PCSC/issues/239

However, this got fixed by using the latest ccid package which comes with new udev rules, so this is not the issue I am dealing with here.

In fact, I could narrow the whole thing down to different ACLs on the USB device before and after a suspend. Here are the steps to reproduce the issue:

unplug and replug the Nitrokey (or any smartcard reader)

check ACL of the Nitrokey's USB device:

getfacl /dev/bus/usb/001/007
# file: dev/bus/usb/001/007
# owner: root
# group: pcscd
user::rw-
user:curly060:rw-
group::rw-
mask::rw-
other::---

suspend and wake the system

check ACL of the Nitrokey's USB device (note that the device was re-enumerated after the resume):

getfacl /dev/bus/usb/001/008
# file: dev/bus/usb/001/008
# owner: root
# group: pcscd
user::rw-
user:curly060:rw-
group::---
mask::rw-
other::---

=> Now the group permissions are gone! However, replugging the nitrokey (or manually fixing the permissions) fixes the issue

I did some further investigation and disabled all rules that add the "uaccess" tag to my device. This needs to actually happen in two files:

/usr/lib/udev/rules.d/41-nitrokey.rules # part of nitrokey-udev-rules package
/usr/lib/udev/rules.d/70-uaccess.rules # part of systemd package

Once the uaccess tag is gone from my device, the permissions are no longer wrong after a resume.

My guess is that this ACL/permission thing has always been like that but after the pcscd service was switched to running as pcscd user and thus required the device to be of group "pcscd" with correct permissions this stopped to work.

So even though the change was in pcscd, to me this seems like a bug in Systemd. What do you think? Can anyone confirm this behaviour?

For the record: I do not have any custom udev rules that may interfere.

Cheers, Curly060 =;->

seth · 2026-01-19 15:39:27

What happens if you make 41-nitro… 71-nitro… ?

Arch Linux

#1 2026-01-19 11:16:16

pcscd.service fails after resume from suspend/hibernate

#2 2026-01-19 15:39:27

Re: pcscd.service fails after resume from suspend/hibernate

Board footer