Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions) | Eaton 9130

[peterge-misoft]

Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions) | Eaton 9130

[jimklimov]

Hello, thanks for the report - interesting questions :)

Regarding that corrupt-looking ID, I am not sure OTOH if nut-scanner does some data conversion/normalization of invalid characters (e.g. if it "keeps" the ? as part of string, or just the terminal or the program can not display it in that locale and it is only converted visually). Probably if you redirect its output into a file and view it with e.g. HEX mode of mcview that bit can get clarified. Otherwise, for practical purposes, NUT (and you) can treat the matched values as an exact string first, and as a regex subsequently (so a . for "any character" can help here). For nutdev4 (per nut-scanner dump) this is probably the issue, since if there really is a question mark character, the regex mode looks for "zero or one G immediately followed by 336...".

While at it, can you please also post the ups.conf file contents? Specifically, I wonder if some of your other UPSes only specify a vendorid and productid or even nothing at all (not constraining to check the serial or vendor strings), and so grab this device instead of their intended one. And also if they were enumerated in same order as the printout of the tool above, so if nutdevN here and in service unit names (from ups.conf) use the same N across the board (some things seem to not match up, so...)

Also it seems that some of those serial values actually have trailing spaces in lsusb and in driver debug. This should not matter for regex match where your configured string is a sub-string of what the device reports, but still - worth exploring if nothing else helps.

For the test with the driver directly - I am not sure why nutdev3 here says it matched with the second seen device (serial GE333A0480), so assuming a mix-up of nutdevN numbering in actual ups.conf and in shown nut-scanner dump. In that case, maybe a running driver from the service unit (as prepared by NDE - see https://github.com/networkupstools/nut/wiki/nut%E2%80%90driver%E2%80%90enumerator-(NDE) article) - can be holding the device and conflicting with the command-line driver, as detailed in that article.

From the original post title, Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions) -- this is actually normal: 1D6B:0003 is not known to NUT as an UPS VID:PID combo, so it is not built into /usr/lib/udev/rules.d/62-nut-usbups.rules (assuming you have a Debian/Ubuntu derived package of NUT) and the OS does not assign permissions for nut user/group to own that devfs node.

I wonder now if udev might struggle assigning such rights to several devfs nodes for 0463:ffff so only the first device would be seen in detail by NUT?.. Given that the 3 other UPSes work, this is probably not the issue.

As one last thought so far, maybe the broken reported serial number is indicative of some memory/flash corruption on the UPS controller or noise in internal wiring/connectors so it is just defective, and the Entity not found is actually due to its unresponsiveness elsewhere in the USB HID dialogs? @arnaudquette-eaton - WDYT?

For a quick test to rule out any confusion, I'd also try stopping all NUT driver services, unplugging the 3 working UPS connections, to leave only the troublesome one in place, and running e.g. /lib/nut/usbhid-ups -s testdev -DDDDDD -x vendorid=0463 -x productid=ffff -d1 to try and poll the device exclusively (with no competitors) for one data dump. If it works in such sandbox, there may be some NUT or OS integration problem. If not even then - more likely a HW problem. You've tried cables; try also a different USB port (preferably on a different motherboard USB hub, or computer altogether) just in case it is the computer's problem.

[jimklimov]

Thanks for the screenshots. So nutdev3 and nutdev4 are indeed inverted in ups.conf compared to nut-scanner listing.

Currently nutdev3 is matched by vendorid, productid and bus which are same as for everyone else, and by vendor and product strings that are same as for nutdev2, and no unique field to differentiate them. In particular, any serial value is suitable so it tries to grab the same device as nutdev2's driver already did. Having different config names, it does not kill it off as it would if instances of the same driver config competed, e.g. older copy stalled, or the tug of rope between CLI and service unit (NDE-facilitated) runs.

In your case, setting the serial for nutdev3 with a . character in place of the "broken" one should fix the issue, allowing for regex-based match of exactly one device - and the one you want.

[peterge-misoft]

Thanks for the screenshots. So nutdev3 and nutdev4 are indeed inverted in ups.conf compared to nut-scanner listing.

Oh yes, you are correct. I miss copy/pasted sth.
This is the config now:

root@raspberrypi-nut:~# cat /etc/nut/ups.conf
pollinterval = 1
maxretry = 3
[nutdev1]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9PX3000RTN(2U) - Rack 3"
	vendorid = "0463"
	productid = "FFFF"
	product = "Eaton 9PX"
	serial = "GA14K17039"
	vendor = "EATON"
	bus = "001"
[nutdev2]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9130 - Rack 4"
	vendorid = "0463"
	productid = "FFFF"
	product = "9130"
	serial = "GE333A0480"
	vendor = "EATON Powerware"
	bus = "001"
[nutdev3]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9PX3000RTN(2U) - Rack 2"
	vendorid = "0463"
	productid = "FFFF"
	product = "Eaton 9PX"
	serial = "GA14K17060"
	vendor = "EATON"
	bus = "001"
[nutdev4]
	driver = "usbhid-ups"
	port = "auto"
	desc = "Eaton 9130 - Rack 1"
	vendorid = "0463"
	productid = "FFFF"
	product = "9130"
	serial = "G?336A0278"
	vendor = "EATON Powerware"
	bus = "001"

But it doesnt change anything, now nutdev4 is the missing one after restarting:

root@raspberrypi-nut:~# systemctl -l status nut-server 
● nut-server.service - Network UPS Tools - power devices information server
     Loaded: loaded (/lib/systemd/system/nut-server.service; enabled; preset: enabled)
     Active: active (running) since Thu 2024-05-23 09:37:05 CEST; 2min 29s ago
   Main PID: 306643 (upsd)
      Tasks: 1 (limit: 8731)
        CPU: 66ms
     CGroup: /system.slice/nut-server.service
             └─306643 /lib/nut/upsd -F

May 23 09:37:05 raspberrypi-nut.misoft.lan nut-server[306643]: Can't connect to UPS [nutdev4] (usbhid-ups-nutdev4): No such file or directory
May 23 09:37:05 raspberrypi-nut.misoft.lan nut-server[306643]: Connected to UPS [nutdev3]: usbhid-ups-nutdev3
May 23 09:37:05 raspberrypi-nut.misoft.lan nut-server[306643]: Connected to UPS [nutdev2]: usbhid-ups-nutdev2
May 23 09:37:05 raspberrypi-nut.misoft.lan nut-server[306643]: Connected to UPS [nutdev1]: usbhid-ups-nutdev1
May 23 09:37:05 raspberrypi-nut.misoft.lan upsd[306643]: Can't connect to UPS [nutdev4] (usbhid-ups-nutdev4): No such file or directory
May 23 09:37:05 raspberrypi-nut.misoft.lan upsd[306643]: Connected to UPS [nutdev3]: usbhid-ups-nutdev3
May 23 09:37:05 raspberrypi-nut.misoft.lan upsd[306643]: Connected to UPS [nutdev2]: usbhid-ups-nutdev2
May 23 09:37:05 raspberrypi-nut.misoft.lan upsd[306643]: Connected to UPS [nutdev1]: usbhid-ups-nutdev1
May 23 09:37:05 raspberrypi-nut.misoft.lan nut-server[306643]: Running as foreground process, not saving a PID file
May 23 09:37:05 raspberrypi-nut.misoft.lan upsd[306643]: Running as foreground process, not saving a PID file

In your case, setting the serial for nutdev3 with a . character in place of the "broken" one should fix the issue, allowing for regex-based match of exactly one device - and the one you want.

Changing serial to
serial = "G.336A0278"
does indeed fix this for me!
Now I am able to query all devices with upsc!

root@raspberrypi-nut:~# upsc nutdev1@localhost
Init SSL without certificate database
battery.capacity: 9.00
battery.charge: 100
battery.charge.low: 0
battery.charge.restart: 0
battery.charger.status: resting
battery.energysave.delay: 300
battery.protection: yes
battery.runtime: 2489
battery.runtime.low: 180
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 9PX 3000i RT 2U
device.serial: GA14K17039
[...]

root@raspberrypi-nut:~# upsc nutdev2@localhost
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 20
battery.runtime: 675
battery.type: PbAc
device.mfr: EATON Powerware 
device.model: 9130  3000VA-R
device.serial: GE333A0480  
device.type: ups
driver.name: usbhid-ups
driver.parameter.bus: 001
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 1
driver.parameter.port: auto
driver.parameter.product: 9130
driver.parameter.productid: FFFF
driver.parameter.serial: GE333A0480
[...]

root@raspberrypi-nut:~# upsc nutdev3@localhost
Init SSL without certificate database
battery.capacity: 9.00
battery.charge: 100
battery.charge.low: 0
battery.charge.restart: 0
battery.charger.status: resting
battery.energysave.delay: 300
battery.protection: yes
battery.runtime: 3273
battery.runtime.low: 180
battery.type: PbAc
device.mfr: EATON
device.model: Eaton 9PX 3000i RT 2U
device.serial: GA14K17060
device.type: ups
driver.name: usbhid-ups
driver.parameter.bus: 001
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 1
driver.parameter.port: auto
driver.parameter.product: Eaton 9PX
driver.parameter.productid: FFFF
driver.parameter.serial: GA14K17060
[...]

root@raspberrypi-nut:~# upsc nutdev4@localhost
Init SSL without certificate database
battery.charge: 100
battery.charge.low: 20
battery.runtime: 3240
battery.type: PbAc
device.mfr: EATON Powerware 
device.model: 9130  3000VA-R
device.serial: G?336A0278
[...]

Thank you very much for helping out on with this problem! <3
(I received the info from a colleague that this UPS might be 12-14 years old...)

[peterge-misoft]

Thanks for your detailed comment, I will try to answer all of you questions:

Regarding that corrupt-looking ID, I am not sure OTOH if nut-scanner does some data conversion/normalization of invalid characters (e.g. if it "keeps" the ? as part of string, or just the terminal or the program can not display it in that locale and it is only converted visually). Probably if you redirect its output into a file and view it with e.g. HEX mode of mcview that bit can get clarified. Otherwise, for practical purposes, NUT (and you) can treat the matched values as an exact string first, and as a regex subsequently (so a . for "any character" can help here). For nutdev4 (per nut-scanner dump) this is probably the issue, since if there really is a question mark character, the regex mode looks for "zero or one G immediately followed by 336...".

root@raspberrypi-nut:~# nut-scanner -U > output.txt
root@raspberrypi-nut:~# apt install mc
root@raspberrypi-nut:~# mcview output.txt

F4

While at it, can you please also post the ups.conf file contents? Specifically, I wonder if some of your other UPSes only specify a vendorid and productid or even nothing at all (not constraining to check the serial or vendor strings), and so grab this device instead of their intended one. And also if they were enumerated in same order as the printout of the tool above, so if nutdevN here and in service unit names (from ups.conf) use the same N across the board (some things seem to not match up, so...)

root@raspberrypi-nut:~# cat /etc/nut/ups.conf
pollinterval = 1
maxretry = 3
[nutdev1]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9PX3000RTN(2U) - Rack 3"
	vendorid = "0463"
	productid = "FFFF"
	product = "Eaton 9PX"
	serial = "GA14K17039"
	vendor = "EATON"
	bus = "001"
[nutdev2]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9130 - Rack 4"
	vendorid = "0463"
	productid = "FFFF"
	product = "9130"
	serial = "GE333A0480"
	vendor = "EATON Powerware"
	bus = "001"
[nutdev3]
	driver = "usbhid-ups"
#	driver = "bcmxcp_usb"
	port = "auto"
	desc = "Eaton 9130 - Rack 1"
	vendorid = "0463"
	productid = "FFFF"
	product = "9130"
#	serial = "Gï336A0278"
	vendor = "EATON Powerware"
	bus = "001"
[nutdev4]
	driver = "usbhid-ups"
	port = "auto"
        desc = "Eaton 9PX3000RTN(2U) - Rack 2"
	vendorid = "0463"
	productid = "FFFF"
	product = "Eaton 9PX"
	serial = "GA14K17060"
	vendor = "EATON"
	bus = "001"

For a quick test to rule out any confusion, I'd also try stopping all NUT driver services, unplugging the 3 working UPS connections, to leave only the troublesome one in place, and running e.g. /lib/nut/usbhid-ups -s testdev -DDDDDD -x vendorid=0463 -x productid=ffff -d1 to try and poll the device exclusively (with no competitors) for one data dump. If it works in such sandbox, there may be some NUT or OS integration problem. If not even then - more likely a HW problem. You've tried cables; try also a different USB port (preferably on a different motherboard USB hub, or computer altogether) just in case it is the computer's problem.

I could to this next tuesday, then I will have physical access to the machine again :)

---

I guess thats all you asked for, but I have not tested with the nut‐driver‐enumerator driver yet.

[jimklimov]

For clarity, there's also a setting to "allow duplicates" to skip such busy devices and try to match another. It helps when drivers race and whichever one grabs a device first, and you have no ways to identify them reliably. Crucially, it is only useful when you don't care about which exact device a particular copy of the driver tracks, but care about just the count of healthy (or not) power sources.

I don't think this is your use-case, but worth keeping it in mind :)