Rysz

Der UPS Driver ist falsch eingestellt, nicht usbhid-ups sondern nutdrv_qx einstellen und versuchen bitte.

Ja und im BIOS muss zusätzlich eingestellt sein, dass nach einem Stromverlust immer gestartet werden soll. Wird die USV jetzt von NUT erkannt?

Nein, bleibt 127.0.0.1 wenn die USV direkt per USB am UNRAID angeschlossen ist.

Klicke bitte einmal auf "Reset Config" und dann... Stelle bitte mal so ein und schaue, ob es dann bei dir funktioniert:

Danke, die sollte grundsätzlich mit NUT funktionieren, poste bitte mal einen Screenshot deiner NUT Einstellungen.

Was hast du denn für eine USV - welchen Hersteller und welches Modell? Poste doch mal einen Screenshot von deinen aktuellen NUT Einstellungen.

Thanks for the information, it's very likely the same problem as the user above experienced with that APC series and the two week self test (the time frame fits) - so using the legacy or stable backend should solve the problem for you too. I have reported this issue to the NUT (backend) developers in the meantime so hopefully we will see a fix before too long.

Thanks a lot for your testing and patience with this, I'm very glad that this is working for you at last. Unfortunately some UPS don't really play well with the newer backends, but I'll raise an issue with the NUT developers so this can be fixed in newer versions (hopefully). In the meantime you can revert all your settings to your preferred values now, just make sure to keep the backend on one that is working for you and also keep the usernames different for monitor and slave.

So I've been able to reproduce the problem on my test server at last, thanks for your patience and testing. The culript is that the UPS seems to send an "OFF" event during the self-testing, which basically says "Hey, I'm offline and no longer providing power to your server" and NUT acts on that and starts a shutdown sequence because it requires at least one functional, online UPS. This is the line where this happens: Oct 8 17:30:11 UNRAID upsmon[26302]: UPS [email protected]: administratively OFF or asleep What's even stranger is the UPS seems to be "OL" (Online) and "OFF" (Offline) at the same time, these two events shouldn't be able to exist at the same time. I'm guessing this is an APC driver issue with NUT and your specific UPS model or series, so I'll have to run this up to the NUT backend developers, the UNRAID plugin is basically just a frontend for the NUT backend (which is developed for more systems than UNRAID). What is curious is that I've found no report from other APC users where this happens, which makes me wonder if this is something that is just happening on your UPS or UPS series. What you can try in the meantime: Change the NUT backend to "legacy (2.7.4)" in NUT Settings -> Reboot -> Test Change the NUT backend to "stable (2.8.0)" in NUT Settings -> Reboot -> Test And please report back if the problem also happens on the different backends. If it doesn't work with the other backends, I might have one more idea you could try. It's not an ideal one, so I'll keep this as a last "solution" in case all else fails for now. Please also let me know the exact UPS vendor and model that you have!

OK this is super useful information so thanks for that so far. UPS inverter clicking during self-tests is normal, so that in combination with the other information provided about the UPS hardware's state also makes me think more in direction of a configuration or software issue now. One major problem I've identified with the configuration is that you're using the same usernames for "NUT Monitor Username" and "NUT Slave Username", but those can never be the same because they come with a different set of permissions each. "NUT Monitor Username" is the one the NUT master will use, "NUT Slave Username" is the one your NUT clients will use. Please change your "NUT Monitor Username" to a different username, you won't need to change any settings with the clients. This will make sure the NUT services can distinguish between who is NUT master and who is NUT slave (client), that's really important for functionality. I've read about some UPS only reporting a limited set of variables to NUT during self-tests, so it's possible that during these self-tests the "Runtime Left" variable becomes either unavailable or zero for a few (milli-)seconds while the inverter switches between line power and battery power for testing (that's the clicking you hear). This could (in theory) lead to NUT seeing the UPS on battery power during the testing and at the same time the "Runtime Left" variable unavailable and/or below your configured 15 minutes - resulting in the false shutdown sequence with NUT thinking that it's a power loss scenario. So I'd suggest doing this: Change "NUT Monitor Username" to something else. Change "Shutdown Mode" to "Time On Battery" (for test purposes) Set "Time on Battery before Shutdown (minutes):" to 5-6 minutes (for test purposes) Set "Kill UPS Power" to "No" If you can, trigger a manual self-test of the UPS and see if the problem still occurs. You can also choose "Battery Charge" as "Shutdown Mode", it's still better than "Runtime Left", but "Time On Battery" is mostly independent from UPS-reported variables so it's best for testing now. In general I'd always advise to using either "Battery Charge" or "Time on Battery", rather than "Runtime Left", because "Runtime Left" is the least predictable and trustworthy of the different "Shutdown Mode"s. The reason is reported UPS runtime can fluctuate a lot depending on UPS and UPS battery and many UPS vendors do not have clean implementations of this variable.

OK this is quite an advanced setup you've got there, so let's see. Definitely before this happens, some kind of power problem occurs (due to mains power loss or mains power condition like voltage/frequency spike as seen in brownouts) OR your UPS is reporting such a state to NUT falsely (due to defective UPS, driver problem ...). So NUT is receiving information from your UPS that makes it consider your UPS to be in a critical state, triggering an immediate shutdown despite any of your configured NUT settings (e.g. "Runtime Left" as "Shutdown Mode"). Interesting is, your UPS is only reporting a UPS "OFF" event to NUT here: Oct 8 02:35:51 UNRAID upsmon[27897]: UPS [email protected]: administratively OFF or asleep But are there any more log lines before this one indicating that your UPS is going on battery power at some point? Please post any NUT log lines before this one, if there are any. Because this line on its own makes no sense to trigger such a critical situation - your UPS would need to be on battery for a shutdown sequence as below to occur. Before proceeding to initiate a shutdown sequence (FSD) thinking your UPS is critical: Oct 8 02:35:51 UNRAID upsd[27893]: Client [email protected] set FSD on UPS [qnapups] We need to find out why NUT thinks your UPS is critical, this usually only happens when your UPS is both on battery and the UPS battery is almost depleted at the same time. But there's no indication from your logs (just from the inverter clicking sounds) that your UPS is in fact on battery, that's what I don't understand. Plus, for your UPS to reach such a low battery (critical) state faster than your UPS master & clients can shutdown would mean either the UPS battery is severely overloaded (too much power draw) or on the verge of dying (due to old age or defects). Both should be reported by your UPS somehow, so this wouldn't happen out of the blue (unless something was defective). In such a shutdown sequence NUT (by default) waits max. 15 seconds for your clients to shutdown. If your clients don't shutdown within those 15 seconds, it proceeds to continue to shutdown the UNRAID server. Normally this wouldn't have negative effects on your clients shutdown sequences, but you had "Kill UPS Power" set to "Yes". So after UNRAID shutdown is completed, it kills the power to all your clients even if they're not done with their own shutdown sequences yet - this is what caused your unclean shutdowns there. With "Kill UPS Power" set to "Yes" one needs to make sure that the clients start their shutdown sequences earlier than the master and also have sufficient time to shutdown before the master starts shutting down and cuts the power. This is, of course, not possible when your UPS suddenly goes critical for reasons unknown - so we'll need to set this to "No" for now. So where to go from all this information? It's not from updating the plugin, definitely, but rather something happening with your UPS. You hear the inverter clicking, so the UPS hardware is doing something at that stage (which is not NUT-caused). First of all, keep "Kill UPS Power" set to "No" until we figure out what is going on with your UPS. This should at least solve the unclean shutdowns for now, but you'll still see your devices shutting down (though gracefully) when your UPS is going into such a sudden critical state. We need to figure out what's happening with your UPS hardware. So if there's no power outage this could either be your UPS testing its battery, conditioning power (because of voltage/frequency spikes) or your UPS/UPS battery being defective. A battery test or power conditioning should not cause a NUT critical state, unless the battery is almost dead in the first place and does not even survive that short time on battery power in combination with the load connected. Did you see any lights flickering in your house when this was happening? First I would make sure your UPS is not somehow overloaded (too many watts for too little battery). If that's not the case, I'd attempt to switch out the UPS batteries, that being the cheapest solution. Especially if your UPS batteries are already older, changing them can be magic to solving very weird problems. If the problem persists even then I'd consider the UPS defective and have it checked by the vendor. If you're still in warranty for your UPS I'd definitely contact the vendor and get the UPS and UPS battery checked. All of this is, of course, under the assumption that your UPS is generally compatible with NUT. Please do also cross-check with the hardware list on the NUT website for reference. Sometimes searching for your UPS model together with NUT on Google can also reveal some issues other people with the same model were previously having. But overall I do still think something hardware-related is happening (regardless of NUT) because your UPS is also making the clicking (inverter) noises whenever the problem occurs. P.S. Also, I'd generally advise against using "Runtime Left" as "Shutdown Mode" as it's highly dependent on the state of both your UPS battery and UPS reported variables. It's the least reliable out of the three "Shutdown Mode"s, so it might be worth trying with another "Shutdown Mode", especially when you're already having some problems and if your UPS battery is already older.

This definitely shouldn't and doesn't happen with my NUT clients. Are your NUT clients somehow configured to shutdown when losing connection to the NUT master? The update routine of the plugin just stops the NUT service (on the master) before updating but definitely does not trigger a shutdown scenario. And no, "Kill UPS Power" just instructs your UPS to cut the battery power to all protected devices after running the shutdown sequence in case of a power outage.

In dem Fall würde ich eher zu einer Lösung wie z.B. Syncthing greifen, wo sich die Berechtigungen entsprechend einstellen lassen, dass es auch über SMB keine Probleme gibt.

Eaton Geräte haben üblicherweise einen Punkt bei ~20%, wo die USV ein LOWBATT (Niedrige Batterieladung) Event an den UNRAID Server sendet, welches immer (unabhängig von und zusätzlich zur Konfiguration) einen sanften Shutdown auslöst. Gerade wenn die Batterie älter ist, ist "Runtime Left" aber kein so zuverlässiges Kriterium mehr, weil es passieren kann, dass die Batterieladung schneller unter diese 20% fällt als die USV Runtime Left (welche vom "Normalzustand" der Batterie ausgeht) konfiguriert wäre. Bei älteren Batterien würde ich daher eher in Richtung des "Time on Battery before Shutdown" gehen und diesen großzügig und unter Berücksichtigung des Alters der Batterie setzen. Bei einer alten Batterie auf ca 1-2 Minuten max., wenn das Netz in unseren Breiten nicht nach 1-2 Minuten wieder da ist, ist es meist ohnehin länger im Ausfall als die USV es überbrücken könnte. Alternativ könnte man auch "Battery Level" als Kriterium nehmen, dann aber eben mit einem Wert über den 20%, damit es eine Wirkung hat. Wenn die Batterie neuwertig ist, würde ich auch eher ein Kommunikationsproblem mit dem APC Daemon vermuten. Ich würde dir daher auch generell das NUT Plugin empfehlen, welches mehr Einstellungen und Diagnosemöglichkeiten bietet sowie mit Eaton sehr gut funktioniert (NUT wurde einige Zeit von Eaton selbst mitentwickelt).

Since it's a commercial product packaging their client software into an UNRAID plugin would very likely be violation of their EULA.

I've just compiled a new package and updated the plugin to use that, which includes the latest netatalk version (3.1.17) where this issue should be fixed regardless of the "convert appledouble" workaround (I suggest attemping to remove that workaround from the configuration now). Please update and let me know if the problem is now resolved for you either with or without the workaround.

Yes, that's indeed possible, but I don't recommend this to anyone switching the backend because if you're switching the backend you're likely already having some kind of problems and not rebooting your system then adds another unpredictable variable to these already existing problems. Rebooting the system makes sure all files of the old backend are 100% gone from the system, as opposed to just uninstalling and reinstalling where we'll have to rely on the uninstallation routine being able to remove all those files.

Please install Network UPS Tools (NUT) for UNRAID by Rysz from Community Applications. The older plugins (including the one in the first post of this topic) are deprecated/now unsupported.

Thanks for sharing this, I'm just curious what the use case for this would be, as opposed to running NUT in regular netserver setting without dummy-ups acting as a repeater and simply naming your UPS "qnapups" in the NUT settings.

Glad you got it working again! 😉

Sorry I don't really know how to help you more here, I think this is a USB connection or USB controller issue more than a NUT issue. It seems the drivers can't see the UPS as USB device. Your UPS series is reported as working with NUT both with blazer_usb and nutdrv_qx drivers, and now you're even using the exact same NUT backend and settings as with the previous plugin (where you said it was working) so it's 100% identical as before as far as NUT is concerned but still not working. That's why I'm guessing it's an issue outside of NUT.

Warning for users considering to update an existing NUT installation: Be advised that the default backend (including the UPS drivers) is developed further and subject to change. Backend development can never plan for all UPS devices and updating comes with a chance of degraded UPS compatibility. That means if NUT works well for you and you are happy with everything, updating is not going to bring you much benefit. Most of the changes are intended towards simplifying new installations and users having problems with their UPS devices. Please always read the changelog carefully and consider if you really need these changes on your (working) system. For more detailed information about this and the backends, please read this:

Did you also try the blazer_usb driver with the legacy backend? You're now using the exact same NUT backend as with the previous plugin (which worked for you) so there's no reason it shouldn't work anymore (at least not because of NUT). Can you also try another USB port? Check your cable connection to the UPS also if nothing is loose.

Thanks, in this case please try changing the backend to legacy 2.7.4 in NUT Settings (requires reboot). Then try again with first blazer_usb and if that doesn't work nutdrv_qx driver.

Choose Custom, you'll get a text field to the right where you'll put "nutdrv_qx" (without the quotes) and for the port you'll put "auto“ (without the quotes).