upsdrvctl start no longer works (insufficient permissions on everything)

[myyc]

i've seen this reported elsewhere (e.g. #1983). in my case it plainly stopped working, but i don't know when.

briefly:

• using debian stable (upgraded to sid's 2.8.1 to see if that'd change anything)
• the ups works
• it gets recognised by lsusb (Bus 002 Device 005: ID 0764:0501 Cyber Power System, Inc. CP1500 AVR UPS)
• nut-scanner works as root
• permissions are fine in all relevant paths (/run/nut, etc.)
• /lib/nut/usbhid-ups -a ups -DD fails with the following

   0.000028     [D1] debug level is '2'                                                                                                              
   0.000233     [D1] Succeeded to become_user(nut): now UID=123 GID=133                                                                              
   0.000252     [D1] upsdrv_initups (non-SHUT)...                                                                                                    
   0.000260     [D2] Initializing an USB-connected UPS with library libusb-1.0.26 (API: 0x100010a) (NUT subdriver name='USB communication driver (lib
usb 1.0)' ver='0.46')                                                                                                                                
   ...
   0.009685     [D2] Checking device 10 of 11 (0764/0501)
   0.009695     [D1] Failed to open device (0764/0501), skipping: Access denied (insufficient permissions)
   ...
   0.009719     [D2] libusb1: No appropriate HID device found
   0.009725     libusb1: Could not open any HID devices: insufficient permissions on everything

[jimklimov]

Just in case, did you make sure to stop any driver instances that could be running wrapped as a systemd service instance (could be created by NDE - see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) and block the defvs node by actually working)?

Also check if the /usr/lib/udev/rules.d/62-nut-usbups.rules contains the USB IDs for your device, and that the udev.service was restarted after the NUT installation?

[myyc]

yeah, i stopped everything. that log is triggered by a manual execution, but without touching anything i have the usual crash loop:

May 16 11:24:36 n1 systemd[1]: Stopped nut-driver@ups.service - Network UPS Tools - device driver for NUT device 'ups'.
May 16 11:24:36 n1 systemd[1]: Starting nut-driver@ups.service - Network UPS Tools - device driver for NUT device 'ups'...
May 16 11:24:36 n1 nut-driver@ups[277957]: Network UPS Tools - Generic HID driver 0.52 (2.8.1)
May 16 11:24:36 n1 nut-driver@ups[277957]: USB communication driver (libusb 1.0) 0.46
May 16 11:24:36 n1 nut-driver@ups[277957]: libusb1: Could not open any HID devices: insufficient permissions on everything
May 16 11:24:36 n1 nut-driver@ups[277957]: No matching HID UPS found
May 16 11:24:36 n1 nut-driver@ups[277957]: upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
May 16 11:24:36 n1 nut-driver@ups[277930]: Driver failed to start (exit status=1)

as for the last comment, maybe i wasn't clear, but by "no longer works" i meant that i had no issues for a while, didn't touch anything and at some point it just stopped working, so yes, udev has no issues and the rules are there.

[jimklimov]

Well, at face value - the error is that when your copy of the NUT driver tries talking to the device, the OS says it is busy talking to someone else (if the basic devfs ownership/permissions are not the reason). There may be a lot of reasons, including e.g.:

• the kernel holds the device (the stuff udev/upower/... aim to fix, telling the kernel which devices to release to userland processes) - should not be your case
• another process talks to the device exclusively (e.g. another copy of the NUT driver, some other program that found itself an USB HID device to play with, etc.)
• this host is a hypervisor, and the device got delegated into some container/VM
• this host is a container/VM, and the hypervisor has someone else grabbing that device (not visible from inside a virtual environment, but intercepted traffic does not get to the NUT driver here

Thinking of it, maybe fuser or lsof would reveal if some other running process is attached to that devfs node?

[myyc]

thanks for the help so far. we can remove the last two points since it's a bare metal machine. it doesn't seem to be the second either as lsof | grep ... doesn't show the device being open.

it seems that i should have been clearer from the start so let me know if you need other info :)

[jimklimov]

You can also try to go deeper into OS-level tracing (with strace, truss or similar tools), but I think it would give you a wall of text and at some point some ENOACCESS reply to a request from libusb, and that would be it. But still, worth trying in case something else actually does pop up :)

[myyc]

strace only adds this

openat(AT_FDCWD, "/dev/bus/usb/002/005", O_RDWR|O_CLOEXEC) = -1 EACCES

[jimklimov]

Succeeded to become_user(nut): now UID=123 GID=133

Is that devfs node owned by this account? Maybe you ended up with some other udev rule that changes it elsewhere?..

[myyc]

as per the rules file, which i didn't edit, it's owned by root (ownership isn't changed) but group is nut and mode is 664:

ATTR{idVendor}=="0764", ATTR{idProduct}=="0501", MODE="664", GROUP="nut"