12

Running an Ubuntu Server on a Eaton 3S 700VA UPS. The Eaton's USB connection goes into my Ubuntu Server. I'm trying to use NUT to manage the UPS.

After sudo su'ing

cat /etc/nut/ups.conf:

[eaton]
    driver = usbhid-ups
    port = auto
    desc = "Eaton 3S"

upsdrvctl -t start

Network UPS Tools - UPS driver controller 2.6.1
*** Testing mode: not calling exec/kill
   0.000000 
   0.000805 Starting UPS: eaton
   0.000955 exec:  /lib/nut/usbhid-ups -a eaton

upsdrvctl start

Network UPS Tools - UPS driver controller 2.6.1
Network UPS Tools - Generic HID driver 0.35 (2.6.1)
USB communication driver 0.31
Can't claim USB device [0463:ffff]: could not detach kernel driver from interface 0: Operation not permitted
Driver failed to start (exit status=1)

5 Answers 5

12

While I do not claim to be an expert here, I am concerned that this answer will not result in a persistent permission change over a reboot, and/or the usb cable from the UPS gets moved to a different port.

Following the information from here: Musings of the Nannerpuss: NUT - Network UPS Tools - on Ubuntu .

"... The problem involves the fact that Ubuntu mounts the device as owned by root, but the nut daemon drops to an unprivileged account that doesn't have the necessary access. The simple fix is to use udev to adjust the device permissions.

Connect the device and (as root) run lsusb and locate it. Note the Bus and Device IDs as well as the Vendor:Product ID pair...."

using output as in above answer:

$ lsusb
Bus 002 Device 004: ID 051d:0002 American Power Conversion Uninterruptible Power Supply   

again from the link "... You can create a udev rule that controls the mount behavior at boot: ..." (edited to match this scenario better)"

  • use your favourite text editor to make (most likely) a new udev rules.d file. The number must be higher than any other udev.d rules file for the same action:

for example

sudo nano /etc/udev/rules.d/90-nut-ups.rules

# /etc/udev/rules.d/90-nut-ups.rules
ACTION=="add", \
SUBSYSTEM=="usb", \
ATTR{idVendor}=="051d", ATTR{idProduct}=="0002", \
MODE="0660", GROUP="nut"

The rule watches for USB device additions with a vendor and product that match the UPS. It then sets the mode to 0660 and the group to nut instead of the default root.

Note that this answer uses 660 permission rather than 666 since that should be sufficient and more secure.

Reload udev (reboot, or perhaps unplugging then re plugging the usb cable from the UPS at the pc port), then disconnect and reconnect the device and test that the new permissions are correct. I an unclear on this part. In any case, once the nut user group has read and write on the device, it should be able to start successfully.

The udev rules.d edit did work on my 12.04.2 system even when I moved the USB cable to a different port, resulting in different Bus Device numbers on the lsusb output. Udev handled all without intervention. In fact, I may not have had to reboot when I moved it but can't remember for sure and will leave that testing to someone else.

3
  • I found this worked well for me with an APC Back-UPS CS 650 on Ubuntu 12.04.
    – Paul Gear
    Jan 22, 2014 at 2:43
  • Should this not be reported as a bug in ubuntu? and fixed in the official nut package?
    – Jarl
    Jul 29, 2014 at 12:41
  • This works, but scrolling down a bit and reading the newer "this bug has been fixed already" message (specifically: /lib/udev/rules.d/62-nut-usbups.rules is installed now) means this solution is technically obsolete.
    – dannysauer
    Apr 4, 2019 at 21:09
9
  • You can use lsusb to find out the bus and device number

  • Then change permission to the device

    chmod 0666 /dev/bus/usb/[bus number]/[device number]
    

For example

$ lsusb
Bus 002 Device 004: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
$ chmod 0666 /dev/bus/usb/002/004
4

regarding this error:

 failed to claim USB device: could not claim interface 0: Operation not permitted

The NUT FAQ at http://www.networkupstools.org/docs/FAQ.html has this (emphasis mine):

if NUT has been freshly installed, and if the device USB cord was already plugged when installing nut [then] just unplug and plug back the USB cord, then restart nut.

That trick worked for me.

2
  • 2
    I had to restart udev (sudo systemctl restart udev) and then unplug/replug the UPS, FWIW.
    – dannysauer
    Apr 4, 2019 at 21:39
  • Yup, restart udev and unplug/replug UPS did it for me. Jul 23, 2022 at 21:57
1

As ndemou said, the NUT FAQ is aware of the problem, and a patch as been released, correcting the bug. But old stable distros could be affected. Hopefully, the solution is very simple...

From the NUT FAQ : "My USB UPS is supported but doesn’t work!" :

On Linux, udev rules are provided to set the correct permissions on device file. This allows the NUT driver to communicate with the UPS, through this device file.

However, the driver may still fail to start and support the device, with a message like:

failed to claim USB device: could not claim interface 0: Operation not permitted

Operation not permitted is a message pointing to a privilege issue. The most frequent issue is that udev has not actually applied the rule:

if NUT has been freshly installed,
and if the device USB cord was already plugged when installing NUT. 

In this case, just unplug and plug back the USB cord, then restart NUT.

There was a mistake in the naming of the NUT udev rules file which resulted in the rules being overridden by another udev configuration file. While this has been fixed in the Git master branch, your distribution may still be affected. Details are available in the following Github issue: https://github.com/networkupstools/nut/issues/140

Looking further to the Github issue give me the solution :

udev rules are applied too late (priority 52), resulting in nut privileges being overwritten. The final result is that the driver doesn't start, and connection failure to the driver / UPS are reported by upsd and upsmon.

The fix is simply to set priority to 62 by renaming the rules file:

$ mv /lib/udev/rules.d/{5,6}2-nut-usbups.rules

This bug affects:

Debian: http://bugs.debian.org/721600
Fedora / Redhat: https://bugzilla.redhat.com/show_bug.cgi?id=488368
Ubuntu: https://bugs.launchpad.net/debian/+source/nut/+bug/1099947 and probably all Linux distribution
1

If you are away from the USB cord of your UPS (plugging the fresh new UPS and doing the config months later because you lack time), and restarting your machine is not an option, you can retrigger the udev rules:

udevadm control --reload
udevadm trigger
systemctl restart nut-server

Does the job.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .