[Help] Tos 6 424 pro keeps forgetting my UPS

[SWADED]

Tos 6 keeps forgetting my UPS. Latest update did not fix this issue. Please fix this issue, I want to protect my expensive hardware.

[Gremlin]

What ups are you using? What version of TOS? (Not everyone's idea of "latest" is really the latest ) What model of nas?

[Herewerare2024]

Same problem, I havent tried looking into it again since the past 2 TOS 6 updates though. I believe the NUT config and associated "drivers" may be flaky with some "approved or otherwise" UPS.

No matter how I attempted config log error related to USB communication would populate. The UPS would show in the system menu then almost time out and would disappear. If it possible the config expected responses too often from the UPS. Either way, customization is limited in the TOS 6 OS... so it's wait for a possible usb/NUTT update or refresh.

[TMzethar]

Regarding issues with UPS connection instability, disconnections, or being 'forgotten'. This might help you improve it:
viewtopic.php?t=7417

[Herewerare2024]

I worked extensively on this issue last night. What I found is that there are legacy files in /etc/ being the same name as the files in /etc/nut/ . Delete the files with the same name in /etc/ . Next, there are a LOT of permissions to set for the nut. Also the system default for the *.pid in /run/nut defaults to the system user for permission when created. It need to be created for nut which is a nut-monitor modification -> add [Service] User=nut Group=nut (each on own line). Once that is all set and the ups.conf [ups] default designation needs to left as is and not changed to [bob ups] or whatever else as it for some reason changes back to [ups] which causes a permission issue within NUT when there is a mismatch with the line in users nut file, or the monitor config line. This is a pretty vague response I get it. Just understand that between permission rests on usbmon pid files, NUT configuration issues with the name designation change in ups.conf and the system problem with using the wrong user to own the *pid files... it creates a very unstable connection via USB to the UPS. Additionally, some errors will still show up in the messages being error 71. Not a big deal but I believe it has something to do with polling of the ups and either it polls too fast or too slow. I have to look into that more.

[Herewerare2024]

To expand, I verified that there were no .swp file for ups.conf. I found that the ups.conf would not retain changes after a reboot. hence leaving [ups] as is in the file... and also why adding pollinterval = 15 in this file is futile. While im not sure how or why the ups.conf is reset during reboots... the pollinterval setting is not likely to fix the problem IMO. The UPS will show and work for up to a few hours then magically disconnect over time. a reboot will show it again for a few hours before it then disappears... I recommend using the file deaults where required in files that do not retain changes and account for proper file generation from the nut services for pid. Made the thing work. Verified over 18 hours no comms issue with my cyberpower brand ups. Cheers.

[Herewerare2024]

Finally, in /etc/nut/ the ups.conf, upsmon.conf, and upsd.users all need to be configured correctly for any hope of this to work. upsmon.conf should have a: RUN_AS_USER nut entry as well as a: MONITOR ups@localhost 1 XXXXX YYYYY master ,line where XXXXX is the username WITHIN NUT (defined in upsd.users) and not a system account, and YYYYY is the password you defined in the upsd.users file. Remember that "ups" is linked to the [ups] naming in ups.conf.

[TMzethar]

Thank you for reporting your findings. This should provide a valuable reference for the project team.

[SWADED]

Is there any update when this will be fixed?

[Gremlin]

Is there any update when this will be fixed?

When what will be fixed? It doesn't look like you have provided any further details or requested information.