permissions issue with nut init script

[Al Grimstad]

Binary package hint: nut

I choose to run the nut daemons as the user "nut". For reasons I don't understand, the ubuntu 8.04 version of nut (2.2.1-2.1ubuntu7) isn't happy with the ownership-permissions of /var/run/nut (770 root.nut) and fails, i.e., upsdrvctl fails because it can't change to this directory.

I've found two work-arounds. One is to run the nut daemons as root. I don't want to do this.

The second work-around is to change the ownership of /var/run/nut to nut.nut. Again for reasons I don't fully understand, but suppose to be related to the dynamic creation of /var/run at boot, this change doesn't survive a re-boot.

The way I fixed this problem is to hack /etc/init.d/nut changing this line:

                && chown root:nut ${pid_dir} \
to
                && chown nut:nut ${pid_dir} \

A better hack would keep this consistent with values in /etc/default/nut.

Fundamentally, though, I suspect this is some kind of build error. I run nut on debian etch systems and haven't seen this problem.

[Dustin Kirkland  (kirkland)]

Hi-

Is this perhaps a duplicate of Bug #222761?

:-Dustin

[Al Grimstad (al-grimstad)]

On Tue, 2008-04-29 at 00:58 +0000, Dustin Kirkland wrote:
> *** This bug is a duplicate of bug 222761 ***
> https://bugs.launchpad.net/bugs/222761
>
> Hi-
>
> Is this perhaps a duplicate of Bug #222761?
>
> :-Dustin

Yes, indeed! The bug report you cite has a better work around too.

I wonder. Was the code configured with the option "with-group=nut"?
-- al

[Dustin Kirkland  (kirkland)]

On Mon, Apr 28, 2008 at 9:28 PM, Al Grimstad <email address hidden> wrote:
> Yes, indeed! The bug report you cite has a better work around too.

I'm pretty sure Chuck has a fix in the works. It should be rolled out
as an update to hardy at some point.

:-Dustin