"Insufficient permissions" when starting USB drivers

When an USB-capable driver program walks the list of devices, many of those would not be accessible to the unprivileged nut or ups or nobody user account that the driver runs as -- and quite validly, being mice, keyboards or cameras that should be of no interest to NUT:

Considering device #1 (0403:6001)
libusb_open for device #1 failed: Access denied (insufficient permissions)

In some cases, this can be reported for UPS devices as well, and ultimately if no devices were matched as supported by the driver (and none were even accessible to check in detail):

libusb1: Could not open any HID devices: insufficient permissions on everything
No matching HID UPS found
Driver failed to start (exit status=1)

This error message usually deals with a couple of situations:

• Actual lack of permissions (POSIX bits in devfs) -- usually solved by udev, devd, upower, hotplugd or similar subsystem that handles hot-plug hardware for the OS, and assigns ownership and permission to the device nodes.

  • This is more likely to happen with custom NUT builds that did not generate/install/activate the rule set files for the relevant hotplug subsystem.
  • This can also happen when a VID:PID pair not hard-coded in NUT sources as supported by at least one driver is tried as an UPS (e.g. with vendorid and productid options along with explicit subdriver option for usbhid-ups or nutdrv_qx) -- then a local file should be added and activated similar to the package-installed rules (e.g. follow the example of /usr/lib/udev/rules.d/62-nut-usbups.rules for Debian-derived Linux packaging), and a PR submitted to extend the grasp of existing drivers successfully tested with new device IDs.
  • This can also be alleviated by starting the driver as root and configuring it to not drop the privileges (user=root in ups.conf section for the device) as a temporary fix and to check that this is the case at all (ideally, the fewer programs run with high privileges -- the better).

• Someone else has hold of the device and libusb can't take it as exclusively as NUT needs (use lsof/fuser/... to check if any other programs hold it; maybe another copy of your driver program running as a service vs. manually, in debugger etc.)

  • See also: Troubleshooting upsdrvctl drivers not starting ("insufficient permissions on everything" or "Can't claim USB device [VVVV:PPPP]@0/0: Entity not found") possibly due to nut-driver-enumerator (NDE) services having been there before you with NUT 2.8.x.