UGREEN NAS: Protokolle finden und richtig lesen

Warum ist die NAS heute Nacht neu gestartet? Wer hat sich angemeldet? Seit wann ist ein Container weg? Antworten darauf stehen in Protokollen, und davon gibt es auf einer UGREEN NAS mehrere: die Benachrichtigungen von UGOS Pro, die Protokolle einzelner Apps und die Protokolldateien des Linux-Systems darunter. Diese Anleitung zeigt, wo Sie was finden, und führt an einem echten Beispiel vor, wie Sie einen unerwarteten Neustart aufklären.

Die Screenshots und Ausgaben stammen von einer UGREEN DXP4800 Pro mit UGOS Pro 1.21.0.0190. Adressen und Kontonamen in den Ausgaben sind ersetzt.

Voraussetzungen

• Eine UGREEN NAS mit UGOS Pro
• Ein Konto mit Administratorrechten
• Für die Systemprotokolle SSH, siehe Teil 52
• Etwa 20 Minuten

Schritt 1: Die Benachrichtigungen

Klicken Sie oben rechts auf das Sprechblasen-Symbol. Es öffnet sich eine Liste der letzten Meldungen, gruppiert nach App.

Die Zahl am Symbol einer App nennt, wie viele Meldungen von ihr vorliegen. Über das Zahnrad legen Sie fest, welche Apps Benachrichtigungen senden dürfen. Wie Sie die Liste filtern und Alarme aufs Handy bekommen, zeigt Teil 94. Klicken Sie auf Alle anzeigen.

Die Liste nennt Kategorie, Quelle, Zeit und Inhalt jeder Meldung. Über die Spaltenköpfe sortieren Sie, über das Filtersymbol oben rechts grenzen Sie ein. Über Exportieren in den App-Protokollen sichern Sie Einträge etwa für den Support. Mit Alle entfernen leeren Sie die Liste, das löscht aber auch Ihre Spuren für spätere Fragen. Lassen Sie die Einträge deshalb stehen.

Verifizieren: Die Liste zeigt Meldungen der letzten Tage mit Zeit und Quelle.

Schritt 2: Ein Beispiel, der Neustart am Morgen

Bei uns fuhr die NAS am 03.11. um 6:57 Uhr herunter und startete um 6:58 Uhr neu, ohne dass jemand davor saß. Die Liste der Benachrichtigungen erklärt das:

• 02.11., 20:48 Uhr: Es ist ein System-Update auf 1.21.0.0190 verfügbar.
• 02.11., 20:49 Uhr: Die Systemversion wurde heruntergeladen und ist bereit.
• 03.11., 06:59 bis 07:01 Uhr: TextEdit, Docker und Virtuelle Maschine erfolgreich aktualisiert.
• 03.11., 07:00 Uhr: Erfolgreich aktualisiert auf Version 1.21.0.0190.

UGOS hat das Update also über Nacht vorbereitet und am Morgen eingespielt, mit Neustart und anschließender Aktualisierung der Apps. Das passt zu dem, was andere Protokolle zeigen: Die Docker-App meldete um 7:00 Uhr kurz offline und wieder online, und libvirt zeigt den Start der VM nach dem Hochfahren. Wann UGOS Updates einspielt, stellen Sie unter Systemsteuerung, Aktualisieren und Wiederherstellen ein, siehe Teil 7.

Per SSH bestätigt last die Startzeit:

last -x reboot | head -2

reboot   system boot  6.18.15          Tue Nov  3 06:58   still running
reboot   system boot  6.18.15          Wed Oct 21 17:02 - 06:57 (12+14:55)

still running bedeutet, dass das System seit diesem Start läuft. Die zweite Zeile zeigt den vorherigen Start und wann er endete.

Verifizieren: Zu jedem Neustart finden Sie in den Benachrichtigungen oder in last eine passende Erklärung.

Schritt 3: Protokolle der Apps

Docker und die App Virtuelle Maschine führen eigene Protokolle mit mehr Einzelheiten.

Die Docker-App protokolliert Start und Stopp der Engine, Updates und das Bereitstellen von Projekten. Die Meldungen zu den Containern selbst stehen dagegen im Reiter Protokoll jedes Containers, siehe Teil 63. Die Grundlagen zu Docker und Compose erklärt Docker Compose als Grundlage.

Die App Virtuelle Maschine nennt, wer eine VM gestartet, heruntergefahren, geändert oder gelöscht hat. Automatische Starts nach einem Neustart stehen dort bei uns nicht, die finden Sie im Protokoll von libvirt, siehe Teil 90.

Verifizieren: Sie finden in der App, die eine Störung betrifft, den passenden Eintrag mit Zeit.

Schritt 4: Systemprotokolle per SSH

Unter der Oberfläche schreibt das Linux-System Protokolldateien nach /var/log. Die wichtigsten:

• syslog: Sammelprotokoll fast aller Dienste, ältere Teile als syslog.1 und syslog.2.gz
• auth.log: Anmeldungen per SSH und Befehle mit sudo
• kern.log: Meldungen des Kernels, etwa Fehler von Festplatten oder USB-Geräten
• samba/: der SMB-Dienst für Netzlaufwerke
• libvirt/qemu/: eine Datei je VM, benannt nach ihrer Kennung, nur für root lesbar
• ugreen-upgrade.txt: Ablauf der System-Updates, nur für root lesbar
• dpkg.log: installierte und aktualisierte Debian-Pakete
• ups/: die Anbindung einer USV

Manche Dateien darf nur root lesen, etwa die Protokolle der VMs. Andere wie kern.log darf die Gruppe admin lesen, zu der Ihr Administratorkonto gehört. Mit sudo vorangestellt klappt das Lesen in jedem Fall, sudo fragt dabei nach Ihrem Passwort. Die letzten Zeilen einer Datei zeigt tail, laufend mitlesen geht mit tail -f:

sudo tail -n 20 /var/log/kern.log
sudo tail -f /var/log/auth.log

Mit Strg+C beenden Sie das Mitlesen. Zum Blättern und Suchen eignet sich sudo less /var/log/syslog, mit / suchen Sie, mit q beenden Sie. Ältere Teile mancher Dateien packt das System, etwa syslog.2.gz. Diese durchsuchen Sie mit zgrep, zum Beispiel sudo zgrep -i error /var/log/syslog.2.gz.

Verifizieren: sudo tail zeigt aktuelle Zeilen aus kern.log und auth.log.

Schritt 5: Gezielt suchen

Statt ganze Dateien zu lesen, suchen Sie mit grep nach typischen Wörtern. Fehlgeschlagene Anmeldungen per SSH:

sudo grep -E "Failed password|Invalid user" /var/log/auth.log

Gibt grep nichts aus, gab es keinen Treffer, das ist kein Fehler. Bei uns gab es zwei Treffer vom 31.10., beide gehören zu einem einzigen Versuch mit unbekanntem Kontonamen und falschem Passwort:

2026-10-31T07:55:23 nas sshd[3276288]: Invalid user NAME from ADRESSE port 50…
2026-10-31T07:55:39 nas sshd[3276288]: Failed password for invalid user NAME from ADRESSE…

Einzelne Treffer sind oft ein Tippfehler. Viele Treffer von Adressen außerhalb Ihres Heimnetzes deuten darauf hin, dass SSH aus dem Internet erreichbar ist. Prüfen Sie dann die Portfreigaben im Router, siehe Teil 52.

Hinweise auf Festplattenprobleme sucht dieser Befehl:

sudo grep -iE "I/O error|medium error" /var/log/kern.log

Bei uns gab es keinen Treffer. Tauchen hier Zeilen auf, prüfen Sie die S.M.A.R.T.-Werte, siehe Teil 18.

Verifizieren: Sie wissen, wie viele fehlgeschlagene Anmeldungen es gab und ob kern.log Laufwerksfehler meldet.

Schritt 6: Das Journal reicht nur kurz zurück

Auf vielen Linux-Systemen ist journalctl der erste Weg. Auf der UGREEN lohnt ein Blick, wie weit das Journal zurückreicht:

sudo journalctl --list-boots

Bei uns begann das Journal am Nachmittag erst um 16:23 Uhr, also nur eine Viertelstunde vorher, obwohl die NAS seit dem Morgen lief. Ältere Starts kannte es nicht. Der Grund steht in /etc/systemd/journald.conf: UGOS speichert das Journal zwar dauerhaft, begrenzt es aber mit SystemMaxUse=50M auf 50 MB. Ist das voll, löscht systemd die ältesten Einträge. Wie viel belegt ist, zeigt sudo journalctl --disk-usage, bei uns 47,7 MB, das reichte nur für wenige Stunden. Fehler der letzten Stunden findet journalctl trotzdem:

sudo journalctl -b -p err --no-pager

Bei uns stand dort zum Zeitpunkt der Aufnahme nur eine Meldung des USV-Treibers. Für alles, was länger zurückliegt, nehmen Sie die Dateien unter /var/log. Sie reichen deutlich weiter zurück, auth.log bei uns bis in den Mai.

Verifizieren: Sie wissen, ab wann Ihr Journal Einträge hat, und greifen für ältere Ereignisse auf /var/log zurück.

Schritt 7: Ein Ereignis über mehrere Protokolle verfolgen

Die Stärke liegt im Vergleich. Nehmen Sie den Zeitpunkt eines Ereignisses aus einer Quelle und suchen Sie in den anderen nach derselben Minute. Für unser Beispiel mit dem Update am Morgen:

sudo grep "^2026-11-03T06:5[0-7]" /var/log/kern.log | tail -3
sudo tail -n 3 /var/log/ugreen-upgrade.txt
grep "^2026-11-03" /var/log/dpkg.log | grep "upgrade docker-ce:"

Das ^ verankert die Suche am Zeilenanfang, sonst trifft grep auch Zeilen, in denen die Zeit nur im Text vorkommt. kern.log zeigt die letzten Zeilen des alten Systems kurz vor 6:57 Uhr. ugreen-upgrade.txt endet bei uns um 6:56:52 Uhr mit Successful: Das Systemabbild spielt UGOS als fertiges Image ein, nicht über die Paketverwaltung. Die Pakete für Docker und Virtuelle Maschine aktualisiert UGOS dagegen nach dem Neustart über die Paketverwaltung, das steht in dpkg.log, bei uns 40 Pakete von 7:00 bis 7:01 Uhr. Die Zeile upgrade docker-ce um 7:00:17 Uhr passt genau zur Meldung der Docker-App, die Engine sei um 7:00 Uhr offline und um 7:00:33 Uhr wieder online gegangen. Achten Sie dabei auf das Zeitformat jeder Datei: Manche schreiben ISO-Zeiten mit Zeitzone, andere nur Datum und Uhrzeit. Notieren Sie für ein Ereignis jeweils Quelle, Zeit und Inhalt in einer kleinen Tabelle, bis die Reihenfolge klar ist.

Verifizieren: Für ein Ereignis finden Sie passende Einträge in mindestens zwei Quellen innerhalb derselben Minuten.

Welche Quelle für welche Frage?

• Warum ist die NAS neu gestartet? Benachrichtigungen, dazu last -x reboot.
• Wer hat sich angemeldet? auth.log mit grep nach Failed, für SSH-Sitzungen auch last | head.
• Wann ist ein Container ausgefallen? Reiter Protokoll des Containers und Protokolle der Docker-App.
• Wer hat eine VM ausgeschaltet? Protokolle der App Virtuelle Maschine, für automatische Vorgänge das libvirt-Protokoll.
• Hat eine Festplatte Probleme? kern.log mit grep nach I/O error, dazu die S.M.A.R.T.-Werte.
• Warum kommt niemand an das Netzlaufwerk? Die Dateien unter /var/log/samba/.

Mit dieser Übersicht finden Sie für die häufigsten Fragen sofort die richtige Stelle, statt alle Protokolle der Reihe nach zu durchsuchen.

Typische Fehler

• Permission denied beim Lesen: Die Datei darf nur root lesen. Mit sudo lesen.
• Journal kurz: Das Journal ist auf 50 MB begrenzt, ältere Einträge löscht systemd. Dateien unter /var/log nutzen.
• Zeiten passen nicht zusammen: kern.log, auth.log und syslog schreiben Ortszeit mit Zone, libvirt UTC, im Winter eine Stunde hinter der Ortszeit. Die ältesten Zeilen tragen bei uns +08:00, die Werkszeitzone vor der Einrichtung.
• Benachrichtigungen fehlen: Jemand hat Alle entfernen geklickt. Die Dateien unter /var/log, etwa syslog und dpkg.log, enthalten die Vorgänge trotzdem.
• Riesige Ausgabe: Mit grep filtern und mit tail oder head begrenzen.

Häufige Fragen

Wie lange bewahrt UGOS die Protokolle auf?

Das ist je Datei verschieden. syslog und dpkg.log werden regelmäßig gekürzt und gepackt, ältere Teile tragen Endungen wie .1 oder .2.gz. syslog reichte bei uns etwa fünf Wochen zurück. auth.log und kern.log wurden bei uns nicht gekürzt und reichten bis in den Mai zurück.

Was bedeutet die Meldung des USV-Treibers?

Bei uns meldete der Treiber usbhid-ups einen Fehler zu einem Bericht, den er ignoriert. Die USV blieb in UGOS verbunden und zeigte den Akkustand, die Meldung hatte bei uns keine Folgen. Mehr zum Treiber steht in /var/log/ups/ups_tool.log. Wie Sie eine USV einrichten, zeigt ein eigener Teil der Serie.

Soll ich Protokolle regelmäßig lesen?

Nicht jeden Tag. Lesen Sie sie, wenn etwas auffällt, und lassen Sie sich wichtige Ereignisse per Benachrichtigung schicken.

Fazit

Die Benachrichtigungen von UGOS beantworten die meisten Fragen schnell, wie unser Beispiel mit dem Update am Morgen zeigt. Für Docker und VMs haben die Apps eigene Protokolle, für Anmeldungen und Hardware die Dateien unter /var/log. Das Journal reicht auf der UGREEN nur kurz zurück, deshalb lohnt der Blick in die Dateien. Wer die Quellen kennt und Zeiten über mehrere Protokolle vergleicht, klärt die meisten Störungen in wenigen Minuten.

Weiterführende Anleitungen und Quellen

• Teil 52: SSH einrichten
• Teil 63: Docker-App im Überblick
• Teil 90: VM-Autostart
• Teil 95: Task Manager
• Linux: journalctl