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

Verwaltungseinstellungen, Protokollierung, und dann diese Seite: vierhundert rote Zeilen, alle vom selben Fehler, alle aus einer Woche, in der eine App nicht mitgespielt hat. Der Fehler ist längst behoben, die Zeilen bleiben. Man sucht einen Knopf zum Leeren und findet keinen. Es gibt ihn nicht, und in der Diskussion zu Nextcloud All-in-One antwortet der Maintainer szaimen auf genau diese Frage: die Datei auf der Platte kürzen.

Das ist die harmlose Version. Die andere steht im Nextcloud-Forum: ein Protokoll mit 116 Gigabyte, ein anderes mit 42. In beiden Fällen war die Platte voll, bevor jemand nachgesehen hat. Ein Textfile, das die Cloud lahmlegt, ist absurd genug, dass es sich lohnt zu verstehen, wie es dazu kommt. Danach ist das Leeren ein Befehl, und das Kleinhalten sind drei Einstellungen.

Wo nextcloud.log liegt und warum es wächst

Nextcloud schreibt sein Protokoll in eine Textdatei namens nextcloud.log, die im Datenordner liegt, also neben den Dateien der Benutzer. Die Seite „Protokollierung“ in den Verwaltungseinstellungen zeigt nichts anderes als diese Datei, hübsch aufbereitet. Wer die Datei leert, hat auch die Seite leer.

Was hineinkommt, bestimmt die Protokollstufe. Fünf Stufen gibt es, von 0 (Fehlersuche, alles) bis 4 (nur Abstürze), Standard ist 2, also Warnungen und Fehler. Auf Stufe 0 oder 1 landet jede Anmeldung und jeder Dateizugriff in der Datei. Im Forum-Fall mit den 42 Gigabyte tippte ernolf genau darauf: eine Stufe, die viel zu niedrig steht. Der Fall mit 116 Gigabyte hatte eine andere Ursache, eine kaputte OnlyOffice-Anbindung, die denselben Fehler im Sekundentakt schrieb.

Gegen das Wachsen hat Nextcloud eine eingebaute Rotation. Ein Hintergrundjob sieht einmal pro Stunde nach, ob die Datei größer als 100 MB ist. Wenn ja, benennt er sie in nextcloud.log.1 um und überschreibt dabei die vorherige Kopie. Das steht so im Quelltext des Jobs, und daraus folgen zwei Dinge: Schlimmstenfalls liegen 200 MB herum, das ist der Normalfall. Und die Rotation greift nur, wenn der Hintergrundjob läuft. Im Forum fand wwe in seiner Datenbank, dass der Rotationsjob seit Tagen nicht mehr gelaufen war. So kommen die Gigabyte zustande.

Was du brauchst

Eine laufende Nextcloud aus dem offiziellen Docker-Image, per Docker Compose gestartet, und einen Shell-Zugang auf den Rechner, auf dem sie läuft. Meist ist das SSH; wie du den absicherst, steht in SSH absichern auf Debian und Ubuntu. Läuft deine Nextcloud ohne Docker direkt auf dem Server, ersetzt du in jedem Befehl unten den Anfang docker compose exec -u www-data app php occ durch sudo -u www-data php /var/www/nextcloud/occ, und die Datei findest du in deinem Datenordner statt im Container.

Wechsle in den Compose-Ordner und prüf, ob der Container läuft und wie dein Dienst heißt:

cd /opt/nextcloud
docker compose ps

In der Spalte „SERVICE“ steht der Name, den du in allen weiteren Befehlen statt app einsetzt, falls er bei dir anders lautet. In der Spalte „STATUS“ muss „running“ oder „Up“ stehen. Dann prüf, ob occ antwortet, das Kommandozeilen-Werkzeug von Nextcloud, mit dem du gleich die Einstellungen setzt:

docker compose exec -u www-data app php occ status

Die Ausgabe enthält installed: true und deine Versionsnummer. Kommt stattdessen „Console has to be executed with the user that owns the file config/config.php“, fehlt das -u www-data. Bei Alpine-Varianten des Images heißt der Benutzer -u 82, sagt die Doku des Images.

Schritt 1: Ansehen, wie groß es ist und was drinsteht

Bevor du etwas leerst, sieh dir an, was du leerst. Die Datei ist der einzige Zeuge für das, was in den letzten Wochen schiefging, und die ersten Zeilen sagen dir oft, welche App das Protokoll vollschreibt.

docker compose exec -u www-data app ls -lh data/nextcloud.log data/nextcloud.log.1
docker compose exec -u www-data app php occ log:file

Die erste Zeile zeigt die Größe beider Dateien; fehlt nextcloud.log.1, hat die Rotation noch nie gegriffen, das ist bei kleinen Instanzen normal. Die zweite zeigt, wohin Nextcloud schreibt und ab wann rotiert wird:

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

Steht bei „Rotate at“ ein „disabled“, hat jemand die Rotation abgeschaltet, und die Datei wächst ohne Grenze. Das ist dann Schritt 3.

Jetzt eine Kopie auf den Host. Ich würde sie nicht überspringen, auch wenn du sicher bist, dass nur Müll drinsteht: Der Fehler, den du in drei Wochen suchst, ist heute noch in dieser Datei. Beide Wege legen dieselbe Datei an, einmal per Browser, einmal per Befehl.

docker compose cp app:/var/www/html/data/nextcloud.log ./nextcloud-log-vor-leerung.log
ls -lh nextcloud-log-vor-leerung.log

Die Kopie hat dieselbe Größe wie die Datei im Container, dann ist sie vollständig. Bei einem Protokoll im Gigabyte-Bereich dauert das Kopieren entsprechend, und der Download über den Browser bricht bei solchen Größen gern ab; dann nimm den Befehl.

Schritt 2: Das Protokoll leeren

Es gibt zwei Handgriffe dafür, und ich würde den ersten nehmen. truncate -s 0 setzt die Datei auf null Byte, ohne sie zu löschen. Besitzer und Rechte bleiben, wie sie sind, und Nextcloud schreibt die nächste Zeile hinein, als wäre nichts gewesen. rm löscht die Datei ganz; das geht auch, im Forum berichtet Holch, dass Nextcloud sie danach mit null Byte neu anlegt. Aber wer sie als root vom Host aus löscht und Nextcloud sie in dem Moment nicht neu anlegen kann, hat ein Rechteproblem, das er sich mit dem Kürzen gar nicht erst einhandelt.

docker compose exec -u www-data app truncate -s 0 data/nextcloud.log
docker compose exec -u www-data app rm -f data/nextcloud.log.1
docker compose exec -u www-data app ls -lh data/nextcloud.log

Die dritte Zeile zeigt jetzt eine Größe von 0 für nextcloud.log, und die Rotationskopie ist weg. Der Befehl läuft im Container als www-data, dem Benutzer, dem die Datei gehört; deshalb braucht er kein sudo. Wer den Datenordner als Host-Verzeichnis eingebunden hat, kann stattdessen sudo truncate -s 0 /opt/nextcloud/data/nextcloud.log direkt auf dem Host tippen. Für Nextcloud All-in-One nennt szaimen den Pfad /var/lib/docker/volumes/nextcloud_aio_nextcloud/_data/data/nextcloud.log.

Lad danach die Seite „Protokollierung“ im Browser neu. Sie ist leer oder zeigt nur die ein, zwei Zeilen, die seit dem Kürzen dazugekommen sind. Wenn sie nach einer Minute schon wieder voll ist, hast du gerade den Grund gefunden, warum die Datei so groß war, und Schritt 3 ist der Teil, den du brauchst.

Schritt 3: Drei Einstellungen, damit es klein bleibt

Leeren behebt den Zustand, nicht die Ursache. Die Ursache steckt fast immer in einer dieser drei Stellen, und alle drei setzt du in fünf Minuten.

Die Protokollstufe auf Warnung

Standard ist Stufe 2, Warnung. Wer beim Fehlersuchen mal auf 0 oder 1 gestellt hat und es vergessen hat, bekommt jede Anmeldung und jeden Dateizugriff ins Protokoll; das ist der Klassiker aus dem Forum. Prüf zuerst, wo du stehst:

docker compose exec -u www-data app php occ log:manage

Enabled logging backend: file
Log level: Warning (2)
Log timezone: UTC

Steht dort Debug (0) oder Info (1), setz die Stufe zurück. Beide Wege ändern denselben Wert in der Konfiguration.

docker compose exec -u www-data app php occ log:manage --level=warning
docker compose exec -u www-data app php occ log:manage

Die zweite Zeile zeigt jetzt „Log level: Warning (2)“. Zum Fehlersuchen darfst du jederzeit wieder runter auf Debug, nur eben mit dem Vorsatz, es am selben Abend zurückzustellen.

Die Rotation auf 50 MB

Die 100 MB Standard sind kein Problem, solange die Rotation läuft. Ich würde trotzdem auf 50 MB gehen, aus einem einfachen Grund: Der Job prüft nur einmal pro Stunde, und eine Nextcloud, die gerade Amok läuft, schreibt in einer Stunde deutlich mehr als 50 MB. Die Grenze ist also ein Richtwert, ab dem die nächste Stunde aufräumt, keine harte Kante. Im Forum beschreibt bb77 das als Rotation, die „eher zufällig“ und nicht bei der eingestellten Größe passiert; der stündliche Takt erklärt genau das. Die Angabe erfolgt in Byte.

docker compose exec -u www-data app php occ log:file --rotate-size=52428800
docker compose exec -u www-data app php occ log:file

„Rotate at“ zeigt jetzt 50 MB. Wer auf 0 setzt, schaltet die Rotation ab; das ist nur sinnvoll, wenn das Betriebssystem mit logrotate übernimmt, wie ernolf im Forum vorschlägt. Das ist ein eigenes Thema und für eine Nextcloud im Container nicht der erste Griff.

Der Cron-Container, der die Rotation ausführt

Der Punkt, an dem die Gigabyte-Fälle im Forum hängen. Die Rotation ist ein Hintergrundjob, und Hintergrundjobs laufen bei Nextcloud auf drei Arten: AJAX, also nur wenn gerade jemand die Seite offen hat; Webcron über einen Dienst von außen; oder Cron, ein echter Zeitplan auf dem Server. Die Doku nennt Cron die bevorzugte Art. Ist noch AJAX eingestellt und öffnet zwei Wochen lang niemand die Seite, rotiert auch niemand. Prüf, ob deine Jobs laufen:

Für das Docker-Image liefert das offizielle Compose-Beispiel einen zweiten Container aus demselben Image, der nichts anderes tut, als alle fünf Minuten cron.php aufzurufen. Öffne die Compose-Datei mit nano compose.yaml (oder docker-compose.yml, je nachdem, wie deine heißt) und ergänze unter services: diesen Block. Die volumes-Zeilen müssen exakt denen deines app-Dienstes entsprechen, sonst sieht der Cron-Container eine andere Nextcloud. Speichern mit Strg+O, Enter, schließen mit Strg+X.

  cron:
    image: nextcloud:apache
    restart: always
    volumes:
      - nextcloud:/var/www/html:z
    entrypoint: /cron.sh

docker compose up -d
docker compose ps

In der Liste taucht jetzt ein zweiter Container namens cron mit Status „running“ auf. Nach spätestens fünf Minuten zeigt die Seite „Grundeinstellungen“ eine frische Ausführung, und Nextcloud stellt den Modus dabei von selbst auf Cron um; die Doku sagt, das manuelle Auswählen sei dann nur noch optional. Das ist der Moment, in dem die 200 MB Obergrenze wieder gilt.

Wo es erfahrungsgemäß klemmt

Es füllt sich sofort wieder. Der häufigste Nachsatz in den Forum-Threads. Im 42-Gigabyte-Fall kürzte der Fragende die Datei und schrieb, sie fange einfach wieder an, sich zu füllen. Dann steht die Ursache noch: eine App, die im Sekundentakt denselben Fehler wirft. Sieh dir die ersten Einträge nach dem Leeren an, sie zeigen dir die App. Im 116-Gigabyte-Fall war es OnlyOffice; nach dem Abschalten der Anbindung war Ruhe.

Tausend Mal dieselbe Zeile. Wer die Fehler nicht wegwerfen, aber die Wiederholungen loswerden will, findet im App-Store die App LogCleaner von zomtec2311. Sie löscht Duplikate mit einem Klick, einzelne Einträge nach dem Beheben, und leert die Datei auch ohne Shell. Im Forum-Thread zu einem 151-MB-Protokoll hat sie die Sache am Ende gelöst. Ein Drittanbieter-Werkzeug, das in eine Datei schreibt, die Nextcloud gerade offen hat: Ich würde die Kopie aus Schritt 1 vorher trotzdem ziehen.

Permission denied beim Kürzen. Die Datei gehört www-data mit Rechten 0640, so steht es in der Konfigurationsreferenz. Ein normaler Benutzer auf dem Host darf sie weder lesen noch kürzen. Entweder im Container als www-data arbeiten, wie oben, oder auf dem Host sudo davorsetzen.

Die Rotation greift, und trotzdem ist die Platte voll. Dann liegt daneben eine zweite Datei: audit.log, das Protokoll der Audit-App, die Anmeldungen und Dateizugriffe mitschreibt. Es hat in der Konfigurationsreferenz einen eigenen Schalter (log_type_audit) und wächst unabhängig vom Hauptprotokoll. Wer die App nicht braucht, schaltet sie unter Apps ab; wer sie braucht, nimmt sich das als nächsten Beitrag vor.

Warum der Knopf zum Leeren fehlt

Der fehlende Knopf zum Leeren ist kein Versehen, sondern Absicht: Ein Protokoll, das man wegklicken kann, klickt man weg, bevor man es gelesen hat. Ich finde das richtig, auch wenn es mich in dem Moment nervt, in dem vierhundert alte Zeilen den einen neuen Fehler verdecken. Also: Kopie ziehen, kürzen, und danach die drei Einstellungen. Stufe Warnung, Rotation 50 MB, Cron-Container. Wer das einmal gesetzt hat, sieht das Protokoll nie mehr über 100 MB, und der Forum-Thread mit den 116 Gigabyte bleibt eine Geschichte, die anderen passiert.

Was war bei dir der Grund für das volle Protokoll: eine App, die nicht mehr mitspielte, eine vergessene Debug-Stufe, oder ein Cron, der nie lief? Und hast du vor dem Leeren nachgesehen, was drinstand? Schreib es in die Kommentare, ich sammle gern die Verursacher.

Wenn du gerade deinen Server aufräumst: Paperless-ngx per Docker ist der Dienst, der als Nächstes einen Datenordner bekommt, den man im Auge behalten sollte.

Quellen

• Nextcloud Admin-Handbuch: Logging (Stufen, Speicherort, Rotation)
• Nextcloud Admin-Handbuch: config.php-Parameter (loglevel, log_rotate_size, logfilemode, log_type_audit)
• Nextcloud Admin-Handbuch: Hintergrundjobs (AJAX, Webcron, Cron)
• Nextcloud Admin-Handbuch: occ
• Quelltext: occ log:manage
• Quelltext: occ log:file
• Quelltext: Rotationsjob (stündlich, log_rotate_size)
• Quelltext: RotationTrait (Umbenennen nach .1)
• Offizielles Docker-Image: occ im Container, Cron-Container
• Compose-Beispiel mit Cron-Dienst
• Nextcloud Release-Plan (34.0.3 vom 13-08-2026)
• AIO-Diskussion #4654: Protokoll in der Oberfläche leeren
• Forum: Huge nextcloud.log file (116 GB)
• Forum: nextcloud.log is big (42 GB)
• Forum: Problems with a big nextcloud.log (151 MB, LogCleaner)
• Forum: Rotationsjob lief tagelang nicht
• LogCleaner-App auf GitHub