nut
nut copied to clipboard
networkupstools
upsdrvctl start no longer works (insufficient permissions on everything)
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-scannerworks as root- permissions are fine in all relevant paths (/run/nut, etc.)
/lib/nut/usbhid-ups -a ups -DDfails 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
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?
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 [email protected] - Network UPS Tools - device driver for NUT device 'ups'.
May 16 11:24:36 n1 systemd[1]: Starting [email protected] - 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.
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?
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 :)
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 :)
strace only adds this
openat(AT_FDCWD, "/dev/bus/usb/002/005", O_RDWR|O_CLOEXEC) = -1 EACCES
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?..
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"
I have a similar issue running on proxmox.
It was working fine on proxmox V7 for 2+ years, I then upgraded to V8 2 days ago and are getting the incorrect permission on everything.
Already spent 2 days trying everything I know, including removing and doing a build from source but the error is exactly the same with old version and new version.
I also posted the issue and what I tried on the forum: https://forum.proxmox.com/threads/ups-nut-hid-broken-after-upgrading-to-v8-2.149132/
What I find strange is that it finds the device, and queries it successfully and is able to claim it, yet the driver still continues on querying other USB devices. Why does it not stop when it finds a matching device ?
[eatonElipse]
# user = nut
driver = usbhid-ups
port = auto
# desc = "EATON Elipse ECO 650 UPS"
vendorid = 0463
bus = 003
busport = 001
device = 002
productid = ffff
serial = 000000000
#offdelay=60
#ondelay=70
# Power down the server at a higher battery charge level (40%) than default 20%
# This should help with older, weaker batteries
ignorelb = yes
override.battery.charge.low = 20
# /usr/local/ups/sbin/upsdrvctl -DD -d start eatonElipse
Network UPS Tools - UPS driver controller 2.8.2-338-gdc099e8e5
0.000000 [D1] upsdrvctl commanding one driver (eatonElipse): start
0.000007 [D1] Starting UPS: eatonElipse
0.000014 [D1] WARNING: Requested a debugging level but not explicitly a backgrounding mode - driver may never try to fork away; however the upsdrvctl tool will fork it and not wait.
0.000016 [D2] 1 remaining attempts
0.000022 [D2] exec: /usr/local/ups/bin/usbhid-ups -DD -a eatonElipse
0.000069 [D2] Starting driver with debug but without explicit backgrounding: will not wait for it to fork and detach, continuing...
0.000083 [D1] upsdrvctl: successfully finished
0.000087 [D1] Completed the job of upsdrvctl tool, cleaning up and exiting now
0.000090 [D1] Completed the job of upsdrvctl tool, clean-up finished, exiting now
root@ellis-vm:/usr/share/pac/nut# Network UPS Tools - Generic HID driver 0.54 (2.8.2-338-gdc099e8e5)
USB communication driver (libusb 1.0) 0.48
0.000000 [D1] upsdrv_makevartable...
0.000025 [D1] Using USB implementation: libusb-1.0.26 (API: 0x1000109)
0.000084 [D1] Network UPS Tools version 2.8.2-338-gdc099e8e5 (release/snapshot of 2.8.2.1) built with gcc (Debian 12.2.0-14) 12.2.0 and configured with flags: --with-user=nut --with-group=nut --with-usb
0.000089 [D1] debug level is '2'
0.000468 [D1] Succeeded to become_user(nut): now UID=112 GID=118
0.000476 [D1] Signalling UPS [eatonElipse]: driver.exit (quietly, no fuss if no driver is running or responding)
0.000482 Can't open /var/state/ups/usbhid-ups-eatonElipse: No such file or directory
0.000485 [D1] Request for other driver to exit returned code -1
0.000488 [D1] Socket dialog with the other driver instance (may be absent) failed: No such file or directory
0.000492 [D1] upsdrv_initups (non-SHUT)...
0.000495 [D2] Initializing an USB-connected UPS with library libusb-1.0.26 (API: 0x1000109) (NUT subdriver name='USB communication driver (libusb 1.0)' ver='0.48')
0.002248 [D2] Checking device 1 of 8 (1D6B/0003)
0.002260 [D1] Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions)
0.002262 [D2] Checking device 2 of 8 (10C4/EA60)
0.002265 [D1] Failed to open device (10C4/EA60), skipping: Access denied (insufficient permissions)
0.002270 [D2] Checking device 3 of 8 (8087/0026)
0.002275 [D1] Failed to open device (8087/0026), skipping: Access denied (insufficient permissions)
## FINDS THE DEVICE
0.002279 [D2] Checking device 4 of 8 (0463/FFFF)
0.817905 [D2] - VendorID: 0463
0.817918 [D2] - ProductID: ffff
0.817919 [D2] - Manufacturer: EATON
0.817921 [D2] - Product: Ellipse ECO
0.817922 [D2] - Serial Number: 000000000
0.817923 [D2] - Bus: 003
0.817924 [D2] - Bus Port: 001
0.817925 [D2] - Device: 002
0.817927 [D2] - Device release number: 0100
0.817928 [D2] Trying to match device
0.817930 [D2] match_function_subdriver (non-SHUT mode): matching a device...
0.817964 [D2] Device matches
0.817965 [D2] Reading configuration descriptor 1 of 6
0.817986 [D2] Claimed interface 0 successfully
## Claimed It
0.945975 [D2] Retrieved HID descriptor (expected 9, got 9)
0.945990 [D2] HID descriptor length 909
5.946126 [D2] Unable to get Report descriptor: Resource temporarily unavailable
5.946163 [D2] Checking device 5 of 8 (1D6B/0002)
5.946178 [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions)
5.946181 [D2] Checking device 6 of 8 (0781/55AE)
5.946186 [D1] Failed to open device (0781/55AE), skipping: Access denied (insufficient permissions)
5.946189 [D2] Checking device 7 of 8 (1D6B/0003)
5.946193 [D1] Failed to open device (1D6B/0003), skipping: Access denied (insufficient permissions)
5.946195 [D2] Checking device 8 of 8 (1D6B/0002)
5.946198 [D1] Failed to open device (1D6B/0002), skipping: Access denied (insufficient permissions)
5.946202 [D2] libusb1: No appropriate HID device found
5.946205 libusb1: Could not open any HID devices: insufficient permissions on everything
5.946208 No matching HID UPS found
5.946215 upsnotify: failed to notify about state 4: no notification tech defined, will not spam more about it
Added a udev rule:
# cat /etc/udev/rules.d/50-usb_ups.rules
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="nut"
And reloaded udev:
udevadm control --reload-rules && udevadm trigger
Any suggestions as everything I have tried so far has not made any difference.
and this is the usb info:
# lsusb -vd 0463:ffff
Bus 003 Device 002: ID 0463:ffff MGE UPS Systems UPS
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x0463 MGE UPS Systems
idProduct 0xffff UPS
bcdDevice 1.00
iManufacturer 1 EATON
iProduct 2 Ellipse ECO
iSerial 4 000000000
bNumConfigurations 6
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 0x0022
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 20mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 10.10
bCountryCode 33 US
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 909
Report Descriptor: (length is -7)
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 20
Device Status: 0x0001
Self Powered
0.945990 [D2] HID descriptor length 909 5.946126 [D2] Unable to get Report descriptor: Resource temporarily unavailable
Just in case: did you stop any competing NUT drivers - may be running/trying as a service instance like nut-driver@eatonElipse thanks to NDE (see wiki)?
Is the USB device not passed through to some VM/container?
@jimklimov - Thanks no already checked if it was being used by something else when I saw one of the comments above.
lsof /dev/bus/usb/003/002 produces no output so nothing else is using it.
The UPS is visible in the hardware selection for USB, but none of the VMs or Containers are using it. and just to be sure I shut down all instances and I still get the same error.
Also, this has been working for 2+ years on Proxmox V7 without any problem, it stopped working as soon as I upgraded to version 8.2 3 days ago.
well I don't know why as I have rebooted several times, but I just rebooted and its all back to normal now.
Obviously something I did resolved it, but sadly I can not be sure what it was.
But thanks for helping.
Ubuntu 24.04.2 LTS, NUT 2.8.1-3.1ubuntu2.
Was seeing this as well, problem was configuration generated by nut-scanner was too specific, so when an old CyberPower PR3000ELCDRT2U was replaced by a new instance of the exact same model, despite being the same model, the vendor string reported via USB had changed from CyberPower Systems to CYBER POWER, hence usbhid-ups fails to match it, and falls over with an unhelpfully misleading error message.
Existing config in /etc/nut/ups.conf was generated by running nut-scanner and removing some obviously bad suggestions (serial, bus and device ids, etc):
[ups]
driver = "usbhid-ups"
port = "auto"
vendorid = "0764"
productid = "0601"
product = "PR3000ELCDRT2U"
vendor = "CyberPower Systems"
After the old PR3000ELCDRT2U was replaced with a new one, we started seeing the "insufficient permissions on everything" error.
Running nut-scanner again reported the following:
[nutdev1]
driver = "usbhid-ups"
port = "auto"
vendorid = "0764"
productid = "0601"
product = "PR3000ELCDRT2U"
serial = "PT1PZ2000008"
vendor = "CYBER POWER"
bus = "001"
device = "008"
busport = "013"
###NOTMATCHED-YET###bcdDevice = "0200"
Note the ids and product are the same, but the vendor is different. Removing the vendor = "CyberPower Systems" line in ups.conf resolved the issue.
I think there's probably a few things to be done here:
- nut-scanner should be generating config fragments robust to common changes (such as vendor's bad USB device programming practices, users plugging the equipment into a different USB port, etc).
E.g. the above output really should be the following, since most people will have a single USB UPS attached:
[nutdev1]
driver = "usbhid-ups"
port = "auto"
# vendorid = "0764"
# productid = "0601"
# product = "PR3000ELCDRT2U"
# serial = "PT1PZ2000008"
# vendor = "CYBER POWER"
# bus = "001"
# device = "008"
# busport = "013"
# ###NOTMATCHED-YET###bcdDevice = "0200"
-
Fix usbhid-ups to report a more useful error when the problem is not USB file permission related, but actually "can't find the configured device"
-
Stop matching based on human-readable attributes such as "vendor" and "product", since they clearly change at the whim of a UPS vendor's poor practices.
Thanks @mjog for the report, although here I'd be inclined to hand-wave this away as user/operator error and NUT actually doing the right thing. If you ask it to monitor any device supported by a driver, just say so by providing only driver=usbhid-ups \\ port = auto. If you want specifics, you add them. If you have three CyberPowers plugged into the system, you want whatever way available to identify which one is which (sometimes even the link-dependent hints like bus/device/busport - indeed they are not offered by default in v2.8.2 and later, since they are too likely to change on a whim).
This is YOUR config file, you type it, you're responsible for what you care it to contain. Here nut-scanner just helps you populate it, then you take a chisel to the stone and cut away the cruft :)
Vendor strings changing is not that frequent of an occurrence, though it apparently happens. APC firmware updates were seen to change the productid number. Too many low-key vendors combine IDs like 0000, 0001 and ffff and strings are the only way to make sense of what the device is about, and so what protocol it might talk. Even big-name vendors happen to have useless "serial" number strings like all-zeroes or all-spaces. No one size fits all...
As for the message, I think it was changed at some point to reflect that we did see some devices but refused to match them. I can only advise to re-check with current NUT (as in, build from git master) to make sure that particular issue is no more. Packages are old and "obsolete" a few days after a release is cut in stone, as development marches on.
Note you can just build NUT, not necessarily install it into your system, to check the updated driver: https://github.com/networkupstools/nut/wiki/Building-NUT-for-in%E2%80%90place-upgrades-or-non%E2%80%90disruptive-tests
Also thanks - I've updated https://github.com/networkupstools/nut/wiki/CyberPower-Systems-(CPS)-know-how with your findings.
I also just got this today, i upgraded ubuntu and NUT started working, and got this problem, somehow the information changed and my UPS stopped working. nut-scanner really should just provide the port=auto and driver with the rest of the information commented out, in case you need to disambiguate
@mgrandi : which NUT version do you have now? Note the currently most-recent release is 2.8.3.
Which configuration fields blocked you (e.g. nut-scanner no longer offers bus/busport/device by default - they are indeed commented away since v2.8.2).
somehow the information changed
That's the interesting part... Did you change the config files, or or some other program rewrote them, or they remained as they were in your previous version and something stopped working after the update?
... and my UPS stopped working
I hope not the UPS as a device, but NUT's monitoring of one.
nut-scanner really should just provide
Note that nut-scanner only suggests a configuration, you write the one you need (and are supposed to know what you want and how to achieve that). Like with contracts, some lawyer might draft something, but it is you actively signing your life away :)
You are very much free to never use the tool and iterate some educated guesses for the configuration on your own, it's just a few lines of text. Especially if all you want is driver=usbhid-ups and port=auto - certainly don't need a complex tool to discover and tell you what you already know, disregarding all other nuances (including which vendor/model that config section is supposed to name and handle; presuming that forever you would only have one USB UPS attached).
I can see how even generating a couple of lines can be helpful in some automated-setup scenarios, but that is really a task for whoever uses NUT or integrates with their distro/plugin/...
For automation's sake, probably an option and/or toggle envvar toggle can be added to allow generating a dumber config if only one supported device of the USB bus type was found. I am unlikely to work on that but PRs would be welcome. This should be a "low-hanging fruit".
And also, if you ARE using an older NUT than the current version (which likely has THAT issue long fixed)... your loss, you chose the distro that values stability over rolling daily releases and bleeding-edge features (and bugs).
And also, if you ARE using an older NUT than the current version (which likely has THAT issue long fixed)... your loss, you chose the distro that values stability over rolling daily releases and bleeding-edge features (and bugs).
I am using Ubuntu 25.04, a distribution that came out about a month ago. The 6 month development cycle of Ubuntu has been pretty well documented for about a decade now, not everyone has the time and energy to run arch linux or some other rolling release distribution.
which NUT version do you have now?
ubuntu 25.04 comes with version nut-2.8.1-ubuntu1, so it sounds like it just missed the fix you mentioned
That's the interesting part... Did you change the config files, or or some other program rewrote them, or they remained as they were in your previous version and something stopped working after the update?
My configuration didn't change, but sometimes the port mappings change, presumably when the linux kernel version changes through updates, and in the past i would just run nut-scanner to get the updated values. I use ansible to wrangle the multiple config files, so after i discovered i can just leave out all of the port and bus information, i changed that and re-ran my ansible playbook
I hope not the UPS as a device, but NUT's monitoring of one.
and yes, it was a typo, nut-driver wouldn't start because it couldn't find the UPS on the port/bus that was provided in the configuration file
You are very much free to never use the tool and iterate some educated guesses for the configuration on your own, it's just a few lines of text. Especially if all you want is driver=usbhid-ups and port=auto - certainly don't need a complex tool to discover and tell you what you already know, disregarding all other nuances (including which vendor/model that config section is supposed to name and handle; presuming that forever you would only have one USB UPS attached).
it is more that people don't know all of those fields were optional, or are only really required if you have multiple UPS devices attached to my computer. I followed some website guide and the NUT documentation and just ended up seeing "use nut-scanner to generate the config and paste that in".
but since it seems that the fix i suggested is actually part of nut 2.8.3 then all is good
I don't disagree with what you said, I too have tens of tasks to tend to during the day and fall victim to "if nothing else helps, try RTFM!" as the last step rather than first. But... this is all documented, and we can only impact the tip of the code/docs source tree, not some old releases copied years ago and adapted into distros, so I must respectfully wash my hands here - on our side, the issue was addressed for some time, and we can't even better inform people who do not read the docs via those docs, right? ;)
- https://networkupstools.org/docs/man/upsdrvctl.html refers to https://networkupstools.org/docs/man/upsdrvsvcctl.html and https://networkupstools.org/docs/man/nut-driver-enumerator.html early on;
- https://networkupstools.org/docs/man/usbhid-ups.html mentions issues about busport and device, not so much about "bus"; ummm, might do a better job about these though. UPDATE: Revised in commit 2afe03c