[Nut-upsuser] Synology NAS is shutting down Ubuntu servers after very brief power outage (fwd)

[Todd Benivegna]

> If you have problems with having the NAS as master, make it a slave, and run the
> NUT configuration of your choice in your PC/workstation.
I have done just this.  I changed the Synology to a slave and made my Raspberry Pi master and the rest of my servers are slaves as well.  Manuel recommnded and he is definitely right, I think that is the best way forward, especially with your discovery as to what they’re doing to NUT on Synology.  I am having one issue getting the nut-server to start up automatically without failing.  You have any idea what’s going on there?
> Those LISTEN lines were appropriate pre-systemd when NUT's startup script was launched after networking was fully enabled. I would recommend "LISTEN 0.0.0.0 3493" instead, and use firewall rules if you are trying to exclude an interface (which is likely not the case on a Pi).
Ok, so replace both with that or just one of the lines?  I suspected one of the lines may be the problem because when I took out the second line, nut-server service wouldn’t fail, but then clients couldn’t connect.
> That is odd, indeed. And yes, it is certainly a permission issue but on
> the journal files which reside below /var/log , not on the config files
>
> Start with journactl -x as it might say more about the error. And maybe
> verify if any log file is defined by the nut-server unit.
I tried journalctl -x and got a huge list, couldn’t even find where nut-service was in there.  I tried...

sudo journalctl -x | grep "nut-server"
sudo journalctl -x | grep “error"

And got a few interesting things, but not very descriptive...
https://hastebin.com/ikupojorav.sql

Do you think it may that line upsd.conf like Charles mentioned?

Thanks everyone for all the help!!!

Regards,

Todd

--
Todd Benivegna // todd at benivegna.com
On Aug 12, 2020, 12:44 PM -0400, Tim Dawson <tadawson at tpcsvc.com>, wrote:
> 555 gives no write access to the dir, and the files are covered by their
> own perms, so I fail to see any relevance to your comment - sorry . . .
>
> 640 is decent for files, not so much for directories - as noted, the
> fields mean different things on dirs . . .
>
> From the man pages:
>
>        The  letters  rwxXst select file mode bits for the affected
> users: read
>        (r), write (w), execute (or search for directories) (x),
> execute/search
>        only  if  the file is a directory or already has execute
> permission for
>        some user (X), set user or group ID on execution (s),
> restricted  dele-
>
> So while direct access may well still work, there is *ZERO* liability in
> allowing search, and frankly, I don't know what tests NUT may be doing
> to find it's files pre-open, and some may block without that attribute .
> . .
>
> For what it's worth . . .
>
> - Tim
>
>
> On 08/12/2020 03:08 AM, Manuel Wolfshant wrote:
> > On 8/12/20 8:10 AM, Tim Dawson wrote:
> > > For directory permissions, the "x" priv determines if you can access
> > > the directory, so going from 555 (r-x,r-x,r-x) to 640 (rw-,r--,---)
> > > pretty much locks out access to the dir. Myself, I'd go back to 555.
> > > 640 essentially locks the group "nut" out . . .
> > >
> > > - Tim
> >
> > At least if on Todd's system the access rights are identical to mine,
> > no, nut is just fine with 640 because the whole directory is owned by
> > group nut. And nut ( or anyone else but root, actually ) has no
> > business in modifying the config files.  Actually I'd be quite
> > concerned if user "nut" wanted to modify its own config.
> >
> > Logs are written somewhere else.
> >
> >
> >
> > _______________________________________________
> > Nut-upsuser mailing list
> > Nut-upsuser at alioth-lists.debian.net
> > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
>
> --
> Tim Dawson
>
> 972-567-9360
>
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/nut-upsuser
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20200812/43b78ab2/attachment.html>