This is the most common first-hour problem, and it is not a driver fault. A USB reader can be claimed by exactly one process. On most systems a PC/SC daemon starts automatically and claims any reader it recognizes, so by the time you run a libnfc tool the device is already taken. The error talks about USB because that is where the refusal surfaces, which sends people to reinstall drivers that were never broken.
So the question to answer first is not "is my reader working" but "who is holding it". Decide which stack you want for the task in front of you, and make sure only that one is running. PC/SC is the right choice when you want to send APDUs through a standard interface, which is most EMV work. libnfc is the right choice when you want the radio layer underneath.
The ladder, in the order that pays#
Work down these five rungs in order and stop at the first one that answers. The order is not arbitrary. It runs from the causes that are most common and cheapest to test toward the one everybody suspects first, which is almost never it. Reaching for a firmware flash on a device you have not yet proved appears on the bus is how an evening disappears.
1. Does the machine see a USB device at all?#
Unplug the reader, list the bus, plug it back in and list again. If nothing changes between the two lists, no amount of software will help you and no driver is at fault. On Linux that is lsusb; on macOS, either the command below or system_profiler with the SPUSBDataType argument, which prints the same tree in more words.
Two causes dominate here and neither is interesting. The first is a charge-only USB cable, which carries power and no data, so the reader lights up and never appears. That is the most maddening failure in this guide, because every visible sign says the device is alive. The second is power: a contactless reader draws hard when its field is up, and an unpowered hub shared with three other things will not deliver it.
2. Who is already holding it?#
If the device enumerates and your tool still cannot open it, something else opened it first. On macOS this is not something you started: the smart-card reader daemon is declared in a launch daemon whose LaunchEvents block matches on IOUSBHostDevice, which means plugging the reader in is what starts it. Looking at a process list before you plug the device in and concluding that nothing is running is therefore a mistake the design invites.
It also arrives already knowing your reader. The CCID driver macOS ships, under /usr/libexec/SmartCardServices/drivers, carries a list of several hundred device names, and the ACR122U's contactless interface is on it by vendor and product id. Nothing needs installing for the daemon to take the device. That is the good news for PC/SC work and the entire problem for libnfc work.
- What you want to know
- Did anything appear on the bus?
- Command
- lsusb
- A useful answer looks like
- One more line after plugging in than before. If the two lists match, stop here.
- What you want to know
- The same, on macOS
- Command
- ioreg -p IOUSB
- A useful answer looks like
- The reader by name in the USB tree. Nothing here means a cable or a port, not a driver.
- What you want to know
- Does PC/SC have it?
- Command
- pcsctest
- A useful answer looks like
- A reader listed means PC/SC claimed it, and that libnfc will not get it while that stands.
- What you want to know
- The same, with a card on it
- Command
- pcsc_scan
- A useful answer looks like
- An ATR when you present a card. This is also the fastest proof that the antenna works.
- What you want to know
- Is the daemon running on Linux?
- Command
- systemctl status pcscd
- A useful answer looks like
- Active. Socket activation means it may start the instant a tool asks for it.
- What you want to know
- Which driver is bound?
- Command
- lsusb -t
- A useful answer looks like
- A Driver= entry per interface. That name is who you are competing with.
- What you want to know
- Are the kernel NFC modules loaded?
- Command
- lsmod | grep pn533
- A useful answer looks like
- Nothing printed is good news. Output means the kernel's own NFC driver may be holding the device.
- What you want to know
- What did the kernel say on plug-in?
- Command
- dmesg | tail -20
- A useful answer looks like
- The last twenty lines, read straight after plugging in, name the driver that took it.
Run those in that order and by the fourth one you usually know. The pattern to recognize is a reader that PC/SC lists happily while libnfc refuses to open it. That is two stacks doing exactly what each was written to do, and the fix is a decision rather than a repair.
3. Which driver is bound to the interface?#
A userspace library reaching a USB device through libusb needs the interface free, and an interface is bound to at most one driver at a time. So the question underneath rung two has a more precise form on Linux: not which process, but which driver. lsusb -t prints the tree with a Driver= entry against each interface, and dmesg read immediately after plugging in names whatever grabbed it.
Linux carries its own NFC subsystem with drivers for the PN53x family, and their module names begin with pn533. If those are loaded on your machine they are a candidate for the interface libnfc wants, so check with lsmod before assuming anything. Check rather than believe, because whether they are present at all depends on your distribution and your kernel configuration, not on any rule this guide can state for you.
4. Permissions#
There is one symptom that identifies this rung on its own: the tool works under sudo and fails as you. Nothing about a claim conflict behaves that way, so if you see it you can skip straight here. On Linux the answer is a udev rule granting your group access to that vendor and product id, which you can read out of the bus listing you already ran.
5. And only now, the device#
If the device enumerates, no daemon holds it, the interface has no driver bound and permissions are right, then suspect the hardware. Even here, look at the symptom before the board. A reader that works and then drops mid-transaction is a power story, not a firmware story. A reader that finds some cards and not others is usually an antenna and a distance story.
| Symptom | What it usually means |
|---|---|
| PC/SC lists the reader, libnfc cannot open it | Working as designed. Stop the PC/SC daemon, or use PC/SC instead. |
| Neither sees it, and no new device appears on plug-in | Cable or power. Try another cable before another driver. Charge-only USB cables are a real and maddening cause. |
| It works as root and not as your user | Device permissions. On Linux this is a udev rule, not something to solve by running everything as root. |
| It enumerates, then drops mid-transaction | Power, or a USB hub. Contactless readers draw hard when the field is up. |
| It finds a transport card and never a bank card | Not a fault. Different card, different activation. Check that you are polling for the right technology. |
| It worked yesterday and not today | Something updated. A kernel, a driver package or a daemon that now starts when it did not. Read the logs from the plug-in. |