Arch Linux

Curly060

Member

Registered: 2015-03-05

Posts: 15

pcscd.service fails after resume from suspend/hibernate

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

Member

From: Don't DM me only for attention

Registered: 2012-09-03

Posts: 73,892

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

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

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

greenfoo

Member

Registered: 2019-12-05

Posts: 14

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

I just experienced the same issue and, as Curly060 suggested, I also think this might be a systemd bug, thus I created this ticket explaining what is going on.

Last edited by greenfoo (2026-03-01 22:44:49)

greenfoo

Member

Registered: 2019-12-05

Posts: 14

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

UPDATE: As explained in the previously linked ticket, the issue turned out to be a problem on the extra/ccid package.

A PR that fixes the problem has already been merged upstream. We just need to wait for a new release (the latest one, which still does not include the fix, is 1.7.1, which is also the same version Arch currently packages)

If you don't want to wait for the new release, you can fix it manually by changing one line on /usr/lib/udev/rules.d/92_pcscd_ccid.rules, from this:

ACTION!="add", GOTO="pcscd_ccid_rules_end"

...to this:

ACTION=="remove", GOTO="pcscd_ccid_rules_end"