[Nut-upsdev] Nut (git) upsdrvctl fails without "-u root start <upsname>", upsd fails on state file GID

David C. Rankin drankinatty at suddenlinkmail.com
Sat Dec 14 21:23:59 UTC 2013

On 12/14/2013 02:06 PM, David C. Rankin wrote:
> Charles,
>   Setting uid:gid to root:nut on /dev/bus/usb/004/002 seemed to be the issue.
> The question now become how to automate this process so that the user isn't
> required to manually hunt down the usb dev and change gid to the nut gid? So
> far, either manually setting the gid or hand-rolling the udev files to do the
> same thing seems like things that used to work automatically, but now require
> user intervention. I don't know the answer, but I'll post this to the Arch list
> and see if the devs there have any idea. Thanks again for your help.

Charles, All,

  Do you know if the problem with upsdrvctl being able to probe/connect to the
usb devices is the result of some default permission change in Linux in general.
It seems to me that since nut used to work right out-of-the-box, then all/most
distros must have had the default permissions on usb nodes set to 0666, where
currently they are 0664. (this is just brainstorming)

  Is there someway nut can be modified to probe the 0664 permission usb devices
and then connect as root before dropping permissions back to the "nut" gid? I've
also posed this question and the problems encountered attempting to run nut out
of the box to the Arch list as well. A summary of that post and the problem here is:


  After working through errors starting the latest nut from git with systemd,
the problem was that /dev/bus/usb/004/002 is owned by root:root forcing
nut-driver.server to fail to start. Essentially upsdrvctl could not find/connect
with /dev/bus/usb/004/002 and could not find the ups usb connection. Modifying
the Execstart=/usr/bin/upsdrvctl start to:

/usr/bin/upsdrvctl -u root start <upsname>

  allowed upsdrvctl to connect, but then created the state files in
/var/state/ups with root:root permission which in turn caused nut-server.service
(upsd) to fail on startup. upsd could not read the device files created in the
state directory and could not create the upsd.pid as it was running gid "nut".

  Changing gid ownership of /dev/bus/usb/004/002 to root:nut solves all problem
and allows upsdrvctl, upsd and upsmon to all start and connect fine. However,
there is no way for the packager to know what bus a device with install or or
whether it will be plugged back into the same port each time. I would like to
investigate how Arch could be changed/configured so that nut simply runs out of
the box as it used to before what ever changed changed. Is there a way the
packager can do this?


  I think this is one of those issues that will take coordination between the
distros and nut to solve unless there is some magic nut can do to work with the
root:root 0664 device permissions by default. What do you think?

David C. Rankin, J.D.,P.E.

More information about the Nut-upsdev mailing list