Ich hatte die Lösung schon vor langer Zeit im alten Forum dokumentiert, aber das gibt es inzwischen nicht mehr.
Ich habe gerade meinen UPS auf ein Unifi UPS 2U umgestellt und dieses unterstützt einen NUT-Server, mit konfigurierbarem UPSName, Benutzernamen und Passwort.
Ich habe Claude Desktop benutzt, um das Ganze wieder zum Laufen zu bringen. Hoffe, das hilft dir.
QNAP als NUT (Network UPS Tools) Client fixen — Die GUI-Option „Network UPS Slave" funktioniert nicht richtig
Das Setup
- Ein NUT-Server läuft auf einem separaten Gerät (in meinem Fall ein UniFi UPS, das als NUT-Server agiert), erreichbar unter
<NUT_SERVER_IP>:3493.
- Ein QNAP NAS (QTS 5.2.9), das diesen UPS als Client/Slave überwachen soll, damit es auf Stromereignisse reagieren kann.
Das Problem
Die eigene GUI-Option von QNAP hierfür — Systemsteuerung → System → Energie → UPS → „Network UPS Slave" — fragt nur nach der IP-Adresse des Servers. Es gibt kein Benutzername-/Passwort-Feld.
Echte NUT-MONITOR-Verbindungen (die das Gerät als authentifizierten Client registrieren und ein korrektes Herunterfahren ermöglichen) brauchen Zugangsdaten, die zu einem Eintrag auf dem Server in upsd.users passen. Ohne diese kann der QNAP-prozess („upsutil“), der über die GUI gestartet wird, nicht richtig authentifizieren, deshalb:
- Das NAS tauchte nie in der Liste der verbundenen Clients des NUT-Servers auf.
- Die eigenen UPS-Informationsfelder der GUI blieben leer (Netzstatus, Batteriestand, Modell — alles zeigte
--), obwohl der UPS klar online war.
Manuell eine schreibgeschützte Abfrage ausführen funktionierte einwandfrei:
upsc <ups_name>@<NUT_SERVER_IP>
Das ergab sämtliche Live-Daten (Batteriestand, Last, Status usw.) — der Server ist also erreichbar und der UPS-Name stimmt. Allerdings ist dies nur ein nicht-authentifizierter read, keine Monitor-Verbindung. Man sieht nicht, ob der tatsächliche Monitoring-Daemon läuft.
Die entscheidende Entdeckung: Ein ps | grep -i ups zeigte nur upsutil — upsmon (der eigentliche NUT-Monitor-Daemon) lief auf dem NAS gar nicht. Die GUI-Option „Network UPS Slave" startet ihn nicht.
Die Lösung
1. Die echte upsmon-Konfiguration direkt bearbeiten
QNAP bringt eine Standard-NUT-upsmon.conf mit, aber die GUI füllt dort die MONITOR Zeile nie mit Zugangsdaten, da sie sie nicht abfragt. Bearbeite die Datei direkt (per SSH oder SFTP):
/etc/config/ups/upsmon.conf
Füge die richtige MONITOR Zeile mit den passenden NUT-Zugangsdaten vom Server hinzu (oder korrigiere sie):
MONITOR <ups_name>@<NUT_SERVER_IP>:3493 1 <monitor_username> <monitor_password> slave
Tipp: Den korrekten <ups_name> (das ist der interne Gerätename, der auf dem NUT-Server registriert ist und muss nicht „ups" heißen) findet man mit:
upsc -l <NUT_SERVER_IP>
2. Den echten Monitoring-Daemon starten
Das QNAP-upsmon-Binary akzeptiert nicht das übliche -c <Pfad> wie normale NUT-Builds (dieses Flag ist für Kommandos wie fsd/reload/stop reserviert). Es liest seine Konfiguration direkt aus dem oben bearbeiteten Pfad /etc/config/ups/upsmon.conf — sobald diese Datei korrekt ist, genügt:
/usr/sbin/upsmon
Schau nach, ob er wirklich läuft (es sollten zwei Prozesse erscheinen — ein privilegierter Parent und ein unprivilegierter Worker):
ps | grep -i upsmon
Sobald er läuft, erscheint das NAS korrekt in der Client-Liste des NUT-Servers und die Verbindung ist authentifiziert.
3. Auf Dauer sicherstellen (Crontab-Watchdog)
Die QNAP-GUI weiß nicht, dass dieser Prozess von Hand gestartet wurde, deshalb überlebt er keinen Neustart und jede Änderung in den GUI-Energieeinstellungen oder ups.sh restart tötet ihn. Statt mit QNAPs fragiler autorun.sh zu kämpfen (die in Systemsteuerung → Hardware → Allgemein aktiviert werden muss und von Malware Remover auch wieder lautlos deaktiviert werden kann), ist ein einfacher Crontab-Watchdog zuverlässiger:
*/5 * * * * pgrep -x upsmon >/dev/null || /usr/sbin/upsmon
Das prüft alle 5 Minuten, ob upsmon läuft und startet ihn falls nötig neu — also auch nach Neustarts, Abstürzen und Eingriffen durch die GUI.
Wichtig bei QNAP: Die Datei /etc/config/crontab direkt zu bearbeiten (z.B. mit Notepad++ über SFTP) reicht nicht — crond.sh restart reicht nicht, sie muss explizit ins aktive crontab geladen werden:
crontab /etc/config/crontab && /etc/init.d/crond.sh restart
Danach prüfen, ob sie geladen wurde:
crontab -l
(Auch prüfen, ob die Zeilenenden im Unix/LF-Format sind, wenn man sie von Windows bearbeitet — CRLF kann bewirken, dass cron die Zeile stumm ignoriert.)
Ergebnis
upsmon läuft durchgehend und authentifiziert und erscheint korrekt in der Client-Liste des NUT-Servers.upsc <ups_name>@<NUT_SERVER_IP> liefert weiterhin Live-UPS-Daten.- Ein Cron-Watchdog hält ihn am Laufen, auch bei Neustarts und GUI-Eingriffen, ohne dass das fragile QNAP-autorun.sh gebraucht wird.
Zusammenfassung der Ursache
Die eingebaute GUI-Option von QNAP „Network UPS Slave" ist ein vereinfachter, nicht-authentifizierter Wrapper (upsutil) — das ist nicht das gleiche wie der Standard-NUT-Daemon upsmon und kann kein echtes, authentifiziertes Client-Monitoring. Wenn die UPS-Statusseite auf deinem QNAP leere Felder zeigt und das NAS nicht in der Clientliste des NUT-Servers erscheint, prüfe ob wirklich upsmon läuft (ps | grep upsmon) — vermutlich tut er das nicht, egal was die GUI anzeigt.
Hinweis: Das umgeht QNAPs eigene integrierte USV-Verwaltung (