Home / ubuntu / Questions / 113994
In Process
Zeophlite
Asked: 2012-03-19 06:15:03 +0800 CST

Trouble starting Network UPS Tools with a Eaton 3S UPS

  • 772

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)
server usb ups

5 Answers

  1. 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.

    • 11

    • 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
    • 9

  3. 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.

    • 4

  4. 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

  5. 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.

    • 1