Bug #13432
open
ups driver will not start
0%
Description
I cannot get a USB-connected UPS to be recognized unless the nut usb driver is started with the "-u root" option.
Without the option:
$ /usr/local/sbin/upsdrvctl start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
No matching HID UPS found
Driver failed to start (exit status=1)
With the option:
$ /usr/local/sbin/upsdrvctl -u root start
Network UPS Tools - UPS driver controller 2.7.4
Network UPS Tools - Generic HID driver 0.41 (2.7.4)
USB communication driver 0.33
Using subdriver: CyberPower HID 0.4
The service script for nut at /usr/local/etc/rc.d/nut.sh does not include the "-u root" option and so it fails to detect any usb connected ups and simple outputs:
Broadcast Message from root@pfsense
(no tty) at 15:12 EDT...
UPS UPS_NAME_HERE is unavailable
over and over.
Files
Updated by Kris Phillips over 1 year ago
Hello,
I tested and was unable to reproduce this, but I don't have a Cyberpower UPS. It seems this shouldn't be limited to Cyberpower, though, since the driver is the generic usbhid driver. Can you please confirm whether you're running pfSense CE or Plus and what version?
Updated by Kris Phillips over 1 year ago
Actually, I tested this with an APC unit just now and the nut package and was able to connect with the generic usbhid driver with an APC UPS I had laying around. It reported normally and required nothing to be manually run as root. See attached screenshot. Tested on pfSense Plus 22.05.
Updated by Scott Lampert over 1 year ago
It seems to be the same as this issue: https://redmine.pfsense.org/issues/9849
This was on a completely new install of pfsense. It seems once the ups is detected correctly it no longer needs the “-u root” flag for the driver on further invocations. I would assume this is because the permissions on the /dev/ugenX.X are restricted to root only. When I get an opportunity I will try removing the nut package and reinstalling to see if I can reproduce this again.
Updated by Kris Phillips over 1 year ago
Scott Lampert wrote in #note-3:
It seems to be the same as this issue: https://redmine.pfsense.org/issues/9849
This was on a completely new install of pfsense. It seems once the ups is detected correctly it no longer needs the “-u root” flag for the driver on further invocations. I would assume this is because the permissions on the /dev/ugenX.X are restricted to root only. When I get an opportunity I will try removing the nut package and reinstalling to see if I can reproduce this again.
Hello Scott,
Sounds good. Please let us know the results.
Updated by Scott Lampert over 1 year ago
I cannot reproduce this after it started working. Even uninstalling and reinstalling the nut package does not seem to set up the conditions to make the error happen. I'm not sure if uninstalling the package also removes the old configuration. If it doesn't, then that would explain why it continues to work. The only other thing I could think to try would be to do a complete fresh install of pfsense, install the nut package, and see if it reproduces this condition. Unfortunately, I'm not in a position to do this currently.
Updated by Travis Erdmann over 1 year ago
I also had the same issue after doing a fresh install (and restored config)
Updated by Kris Phillips over 1 year ago
- Status changed from New to Incomplete
I'm still unable to reproduce this problem with a fresh install of 23.01 and the latest NUT package. At this point I'm marking this bug report as Incomplete until reproduction steps can be provided to make this situation occur.
Updated by Doug Miles 10 months ago
The root cause appears to be the kernel not recognizing some UPS models as a UPS. See discussion here:
https://forum.netgate.com/topic/102959/nut-package/1071
The user=root workaround works, but there is another workaround in that thread to get the kernel to properly identify your UPS, so root isn't required. It requires a little more command-line effort, though.
Updated by Tom Bauer 8 months ago
I started having similar issue after upgrade to 2.7.0 (was working before)
got notices and saw "upsmon" giving "failed - Driver not connected" errors in /var/log/system.log
I resolved the issue by changing owner to nut on the USB devices associated with my UPS used 'ls -lah /dev/usb/' before and after plugging in UPS.
In my case /dev/usb/0.2.0 and /dev/usb/0.2.1 appeared as new, so changed owner on them with:
chown nut /dev/usb/0.2*
it was owned by root:wheel; now owned by nut:wheel