Nextcloud-Protokoll löschen: Log leeren und klein halten

Oben in der Nextcloud-Übersicht steht seit Tagen derselbe Satz: Fehler im Protokoll. Du klickst auf Protokollierung, scrollst durch ein paar tausend rote Zeilen von einer App, die du längst wieder deinstalliert hast, und suchst den Knopf zum Aufräumen. Den gibt es nicht. Nextcloud kann sein Log anzeigen, filtern und herunterladen, aber nicht leeren.

Warum der Knopf fehlt, weiß ich nicht. Vielleicht, weil jemand ihn zu schnell drücken würde. Ich zum Beispiel. Also machen wir es von Hand: drei Befehle im Container, und danach weißt du auch, warum die Meldung in einer Woche wiederkommen kann und was sie dir dann sagen will.

Was du brauchst

• Eine laufende Nextcloud in Docker: das offizielle Image, das Image von LinuxServer oder ein Unraid-Container aus den Community Apps, das ist meist eines der beiden
• Zugriff auf die Shell des Hosts, also des Rechners, auf dem Docker läuft. Per SSH, oder bei Unraid über das Terminal-Symbol oben rechts in der Weboberfläche
• Ein Admin-Konto in Nextcloud für den Blick in die Weboberfläche

Ob du loslegen kannst, klärt ein Befehl auf dem Host:

docker ps --format '{{.Names}}\t{{.Image}}' | grep -i nextcloud

Zurück kommt eine Zeile mit dem Namen deines Containers und seinem Image. Merk dir beides. Der Name kommt in jeden weiteren Befehl, und am Image erkennst du, welche der zwei Befehlsvarianten unten für dich gilt: nextcloud: ist das offizielle Image, linuxserver/nextcloud das von LinuxServer. Kommt gar nichts zurück, läuft der Container nicht, und dann ist das dein eigentliches Problem.

Alle Befehle rechnen mit denselben Beispielwerten. Du musst sie nirgendwo eintragen; wo sie unten auftauchen, ersetzt du sie durch das, was bei dir steht.

Schritt 1: Das Log lesen, bevor du es löschst

Ich weiß, du willst es einfach weghaben. Trotzdem erst ein Blick hinein, denn die Warnung in der Übersicht ist keine Dekoration: Nextcloud zählt dort die Warnungen und Fehler der letzten sieben Tage. Steht da tausendmal dieselbe Zeile, macht gerade jetzt eine App oder eine Einstellung Ärger. Löschst du nur das Log, ist die Meldung eine Woche weg und dann wieder da.

Geklappt hat es, wenn du eine Liste siehst und der neueste Eintrag oben einen Zeitstempel trägt. Der Zeitstempel entscheidet: Liegt er Wochen zurück, ist das Problem längst erledigt und du darfst mit gutem Gewissen aufräumen. Ist er von heute, lies die Zeile zu Ende. Da steht der Name der App, die schreibt. Die zu beheben ist der eigentliche Fix, das Leeren nur die Politur.

Schritt 2: Herausfinden, wo die Logdatei liegt

Die Weboberfläche zeigt dir das Log, sagt aber nicht, wo es liegt. Das verrät occ. Der Befehl läuft im Container, nicht auf dem Host, und je nach Image sieht er etwas anders aus.

docker exec -u www-data nextcloud php occ log:file

docker exec -it nextcloud occ log:file

Die Antwort hat drei Zeilen. Das ist Ausgabe, nichts zum Eintippen:

Log backend file: enabled
Log file: /var/www/html/data/nextcloud.log
Rotate at: 100 MB

Die mittlere Zeile ist dein Pfad. Er gilt im Inneren des Containers, und da bleiben wir auch: Alle weiteren Befehle laufen ebenfalls per docker exec, du musst also nie wissen, in welchem Ordner deines Servers der Datenordner eigentlich liegt. Die dritte Zeile merkst du dir für Schritt 4: 100 MB, bevor Nextcloud die Datei von selbst zur Seite räumt. Deshalb konnte sie so groß werden.

Kommt stattdessen Console has to be executed with the user that owns the file config/config.php, hast du das -u www-data vergessen. Nextcloud nennt dir in der Meldung sogar die passende Benutzer-ID und den Vorschlag, sie an docker exec zu hängen. Eine Fehlermeldung, die ihren eigenen Fix mitbringt. Davon hätte ich gern mehr.

Schritt 3: Das Log leeren

Wenn du die alten Einträge noch brauchen könntest, lade die Datei in Schritt 1 herunter. Das ist dein Backup. Ja, auch für ein Logfile. Ich hör nicht auf damit.

Geleert wird mit truncate, nicht mit rm. Das ist keine Geschmacksfrage: Nextcloud hält die Datei zum Schreiben offen. Löschst du sie, schreibt der Prozess munter in die gelöschte Datei weiter, du siehst sie nur nicht mehr, und der Platz auf der Platte wird erst frei, wenn der Container neu startet. truncate kürzt die Datei dagegen auf null Byte und lässt sie liegen, wo sie ist, mit denselben Rechten.

docker exec -u www-data nextcloud truncate -s 0 /var/www/html/data/nextcloud.log

docker exec -it nextcloud truncate -s 0 /data/nextcloud.log

Ob es geklappt hat, zeigt ein Blick auf die Dateigröße:

docker exec nextcloud ls -lh /var/www/html/data/nextcloud.log

In der Ausgabe steht an fünfter Stelle die Größe, und da sollte jetzt eine 0 stehen. Lade danach die Seite Protokollierung neu: leer. Und die Übersicht prüft beim nächsten Aufruf frisch, findet keine Fehler der letzten sieben Tage mehr und meldet genau das.

Schritt 4: Das Log klein halten

Damit du das nicht jeden Monat wiederholst, setzt du die Grenze aus Schritt 2 herunter. Nextcloud hat dafür eine eingebaute Rotation: Ein Hintergrund-Job prüft die Größe, und ist die Datei über der Grenze, schiebt er sie als nextcloud.log.1 zur Seite und fängt mit einer leeren an. Es bleibt also immer eine Generation als Reserve, mehr nicht.

docker exec -u www-data nextcloud php occ log:file --rotate-size 10485760

docker exec -it nextcloud occ log:file --rotate-size 10485760

Ich würde 10 MB nehmen, nicht die 100 MB aus der Voreinstellung. In 10 MB passen zehntausende Zeilen, das reicht für jede Fehlersuche der letzten Tage, und die Seite Protokollierung bleibt flott. Wer den Wert auf 0 setzt, schaltet die Rotation ab. Das ist die eine Zahl, die du hier nicht eintippen willst.

Zur Kontrolle denselben Befehl wie in Schritt 2 ohne Zusatz, also occ log:file. In der dritten Zeile steht jetzt Rotate at: 10 MB.

Die ersten Einstellungen

Das Log ist leer und hat eine Grenze. Ob es dir künftig hilft oder nur wieder vollläuft, hängt an drei Einstellungen drumherum.

Die Protokollstufe bleibt auf Warnung. Nextcloud schreibt ab Stufe 2 mit, also Warnungen, Fehler und Fatales. Die Versuchung ist groß, auf Fehler hochzudrehen, damit die Übersicht Ruhe gibt. Damit verschwinden aber auch die Warnungen, die dir vor dem Fehler hätten helfen können. Andersherum ist Debug, Stufe 0, nur etwas für eine konkrete Fehlersuche, weil es auf einer Instanz mit ein paar Nutzern die 10 MB in Stunden füllt. Umstellen und zurückstellen geht mit einem Befehl:

docker exec -u www-data nextcloud php occ log:manage --level warning

Die Zeitzone des Logs auf deine setzen. Nextcloud stempelt die Zeilen sonst in UTC ab, und du suchst einen Fehler von 14 Uhr im Log vergeblich, weil er dort unter 12 Uhr steht. Ein Befehl, und die Uhrzeiten passen zu deiner Küchenuhr:

docker exec -u www-data nextcloud php occ log:manage --timezone Europe/Berlin

Die Hintergrund-Aufgaben auf Cron prüfen. Die Rotation aus Schritt 4 ist ein Hintergrund-Job. Steht Nextcloud auf AJAX, läuft der nur, wenn gerade jemand die Weboberfläche benutzt; nachts rotiert dann nichts, und das Log wächst trotzdem. Nachsehen kannst du das per Klick, und die Übersicht warnt dich ohnehin, wenn der Cron länger nicht gelaufen ist.

Häufige Stolpersteine

occ als root gestartet: Die Meldung aus Schritt 2 mit der Benutzer-ID. Nextcloud weigert sich zu Recht, sonst gehören dir hinterher Dateien, die dem Webserver gehören sollten. Einfach -u www-data ergänzen, beim LinuxServer-Image den mitgelieferten occ-Aufruf nehmen.

Log mit rm gelöscht, Platte bleibt voll: Der offene Schreibzugriff aus Schritt 3. Einmal docker restart nextcloud, dann gibt der Prozess die alte Datei frei und legt eine neue an. Beim nächsten Mal truncate.

Die Seite Protokollierung bleibt leer: Sie liest ausschließlich die Datei nextcloud.log. Wer das Log per Konfiguration an syslog oder das Fehlerlog des Webservers umgebogen hat, sieht dort nichts, die Einträge liegen dann im Journal des Hosts. Ob das bei dir so ist, sagt occ log:manage ohne Optionen: Dort muss Enabled logging backend: file stehen.

Die Warnung kommt nach ein paar Tagen zurück: Die Anleitung hat funktioniert, genau davor stand die Ansage in Schritt 1. Irgendwas schreibt gerade jetzt Fehler, und Nextcloud zählt die letzten sieben Tage. Also die neueste Zeile lesen. Sie nennt die App.

Fazit

Das Leeren dauert zehn Sekunden, der eigentliche Wert steckt in Schritt 1 und 4. Wer einmal liest, was da steht, und die Rotation auf 10 MB setzt, öffnet die Seite Protokollierung danach nur noch, wenn die Übersicht wirklich etwas zu melden hat. Und dann steht dort auch nur das Aktuelle, nicht die Vorgeschichte von drei Jahren.

Ich würde die Datei deshalb genau einmal von Hand leeren und es dann Nextcloud überlassen. Ein Log, das man jeden Monat manuell putzen muss, ist ein Log mit einer falschen Einstellung.

Welche App hat bei dir das Log vollgeschrieben, und hast du sie behalten oder rausgeworfen? Und liest du das Protokoll regelmäßig oder erst, wenn die Übersicht rot wird? Schreib es in die Kommentare.

Und wenn Nextcloud gerade nicht nur schreibfreudig, sondern gar nicht erreichbar ist: Uptime Kuma meldet dir das aufs Handy, bevor es die Familie merkt.

Quellen

• Nextcloud-Dokumentation: Logging configuration (logfile, loglevel, log_rotate_size)
• Nextcloud-Dokumentation: Using the occ command
• Nextcloud-Quellcode: occ log:file (Optionen --file, --rotate-size)
• Nextcloud Log Reader: die Prüfung „Errors in the log“ (sieben Tage)
• Nextcloud-Docker-Image: Using the occ command (docker exec -u www-data)
• LinuxServer.io: docker-nextcloud (occ-Aufruf, Pfade /config und /data)