Die stille Wache: Checksummen in Nextcloud

Es ist ein Dienstagmorgen, kurz nach acht. Im Monitoring eines mittelständischen Maschinenbauers leuchtet eine Zeile gelb auf, die dort seit Monaten nicht mehr zu sehen war: Integrity check failed. Der zuständige Administrator klickt sich durch die Logs, findet den Hinweis auf eine Datei im Verzeichnis lib/private, die dort eigentlich nicht stehen dürfte. Vierzehn Minuten später ist klar: Bei einem nächtlichen Deploy ist ein Skript aus dem falschen Branch über die Installation gelaufen. Kein Einbruch, keine Malware – aber eine Abweichung. Möglich wurde die schnelle Einordnung nur, weil Nextcloud seit jeher Buch führt über den Zustand seiner eigenen Dateien. Checksummen sind das unspektakulärste Sicherheitsmerkmal einer Cloud-Installation und gleichzeitig eines der wirksamsten. Über sie wird selten gesprochen, was schade ist, denn wer ihre Grenzen kennt, spart sich an anderer Stelle viel Ärger.

Was eine Prüfsumme leistet – und was nicht

Eine Checksumme ist zunächst nichts weiter als eine Rechenvorschrift, die aus beliebig langen Eingaben eine kurze Ausgabe fester Länge erzeugt. Ändert sich auch nur ein Bit der Eingabe, soll sich die Ausgabe mit überwältigender Wahrscheinlichkeit ändern. Das Prinzip kennt man aus dem Alltag: Wer eine Quittung mit einem fünfstelligen Kontrollcode vergleicht, macht im Grunde dasselbe – nur sehr viel grober.

Entscheidend ist der Unterschied zwischen zwei Zielsetzungen, die im Sprachgebrauch gern vermischt werden. Eine Prüfsumme dient der Erkennung unbeabsichtigter Veränderung: ein abgebrochener Upload, ein defektes RAID-Volume, ein fehlerhaft kopierter Ordner. Eine kryptografische Hashfunktion soll zusätzlich gegen gezielte Manipulation schützen. Wer eine Prüfsumme fälschen will, muss die Gelegenheit haben, auch die Referenz zu fälschen. Genau hier liegt die Schwachstelle vieler Setups: Die Referenz liegt häufig auf demselben System, das geprüft werden soll.

Nextcloud begegnet dem auf zwei Wegen. Bei der Code-Integrität wird die Referenz mit einer Signatur versehen, die ein Angreifer nicht ohne den privaten Schlüssel des Herstellers nachbauen kann. Bei Nutzerdaten verlässt sich das System dagegen auf Plausibilität und Versionierung, nicht auf absolute Beweiskraft. Ein interessanter Aspekt, der in Admin-Foren regelmäßig für Verwirrung sorgt.

Der Werkzeugkasten: MD5, SHA-1, SHA-256 und die Frage nach dem Tempo

Historisch gewachsen ist die Landschaft der Hashverfahren in Nextcloud, wie in fast jeder Software, die auf eine längere Geschichte zurückblickt. MD5 taucht noch an einzelnen Stellen auf, vor allem in Altbeständen von Datenbanken und in Kompatibilitätspfaden. MD5 gilt seit Jahren als kryptografisch gebrochen: Kollisionen lassen sich mit überschaubarem Aufwand konstruieren. Als reine Transportkontrolle gegen Bitfehler ist es weiterhin brauchbar, als Sicherheitsmerkmal nicht.

SHA-1 hat ein ähnliches Schicksal erlitten, wenn auch später. Für neue Implementierungen ist es keine gute Wahl mehr. Der heute übliche Standard in der Nextcloud-Welt ist SHA-256, daneben begegnet einem in neueren Versionen vermehrt BLAKE2 in verschiedenen Ausprägungen – schnell, modern und für Integritätszwecke gut geeignet. In der Praxis der Dateiprüfung spielt BLAKE2 bislang eine Nebenrolle, weil die Interoperabilität mit Clients, Speichermedien und Fremdsystemen über SHA-256 am einfachsten zu gewährleisten ist.

Die Wahl des Verfahrens ist dabei nur die halbe Frage. Genauso wichtig ist, wann gerechnet wird. Eine Prüfsumme über jedes Byte jeder Datei bei jedem Zugriff zu bilden, würde jede Instanz in die Knie zwingen. Nextcloud arbeitet deshalb ereignisorientiert: gerechnet wird beim Hochladen, beim Scannen, beim Reparieren, beim Verifizieren – nicht beim Lesen.

Wo Nextcloud überall rechnet

Code-Integrität: das Gedächtnis der Installation

Im Kern jeder Nextcloud-Installation liegen Dateien namens signature.json. Sie enthalten eine Liste aller zum Release gehörenden Dateien samt ihrer Hashes. Beim Aufruf von occ integrity:check-core vergleicht der Server diese Liste mit dem tatsächlichen Zustand des Dateisystems. Abweichungen werden in drei Kategorien gemeldet, die man auseinanderhalten sollte:

INVALID_HASH – die Datei existiert, ihr Inhalt weicht aber vom Sollwert ab. Das ist der ernste Fall.
FILE_MISSING – eine erwartete Datei fehlt. Häufig nach unsauberen Updates oder wenn ein Aufräumskript zu gründlich war.
EXTRA_FILE – eine Datei liegt im überwachten Bereich, gehört aber nicht dorthin. Meist harmlos, gelegentlich ein Warnsignal.

Dasselbe Verfahren greift für Apps, sofern diese signiert ausgeliefert werden. occ integrity:check-app files_pdfviewer prüft eine einzelne App, occ integrity:check-apps alle auf einmal. Wer den Mechanismus abschaltet – etwa über integrity.check.disabled in der Konfiguration – sollte das bewusst und dokumentiert tun. Es ist bequem, bis man es braucht, und dann ist es zu spät.

Erwähnenswert ist an dieser Stelle auch der Updater: Bevor updater.phar ein neues Release entpackt, prüft er die heruntergeladene Datei gegen den veröffentlichten Hash und gegen die Signatur. Ein manipulierter Download fällt damit auf, bevor er Schaden anrichten kann.

Der Dateicache: Hashes als Teil des Inventars

Nextcloud verwaltet seine Dateien nicht ausschließlich auf dem Dateisystem. Eine zentrale Rolle spielt die Tabelle oc_filecache, in der zu jeder Datei Metadaten liegen: Größe, Änderungszeitpunkt, ETag, Pfad und eben – sofern bekannt – eine Checksumme. Der Aufbau ist einigermaßen unscheinbar, die Auswirkungen sind es nicht.

SELECT fileid, path, size, checksum
FROM oc_filecache
WHERE checksum IS NOT NULL
LIMIT 10;

Gespeichert wird das Format Algorithmus, Doppelpunkt, Hexadezimalwert – also beispielsweise SHA256:9f2c…. Mehrere Einträge lassen sich durch Leerzeichen trennen, was in der Praxis selten vorkommt, aber möglich ist. Wichtig zu verstehen: Eine leere Checksumme bedeutet nicht, dass die Datei beschädigt ist. Sie bedeutet nur, dass für sie nie eine berechnet wurde. Das ist bei per occ files:scan eingelesenen Fremddaten der Normalfall.

Uploads: der Weg über den Header

Beim klassischen WebDAV-Upload kann ein Client im HTTP-Header mitteilen, welchen Hash er für die hochgeladene Datei berechnet hat. Der Server vergleicht nach Abschluss des Schreibvorgangs und lehnt die Datei bei Abweichung ab. Der Header heißt je nach Version und Client OC-Checksum oder OC-Checksum mit SHA-256-Präfix, hier hat sich über die Jahre manches verschoben und alte Clients senden mitunter MD5.

Das ist mehr als eine Formalie. Ohne diesen Abgleich würde ein abgebrochener Transfer unter Umständen eine halbe Datei als vollständig markieren – die Größe stimmt vielleicht, der Inhalt nicht. Mit Header bekommt der Client eine belastbare Rückmeldung und kann den Transfer wiederholen, statt später eine beschädigte Datei in der Sync-Historie zu entdecken.

WebDAV-Auskunft und Client-Abgleich

Prüfsummen lassen sich über WebDAV auch auslesen. Ein PROPFIND mit der entsprechenden Property liefert einen Block, der etwa so aussieht:

<oc:checksums>
  <oc:checksum>SHA256:9f2c4a…</oc:checksum>
</oc:checksums>

Die Desktop-Clients nutzen das, um nach einem Upload zu prüfen, ob die Datei unversehrt angekommen ist. Zugleich dient es als zusätzliche Absicherung gegen das klassische Problem „gleiche Größe, andere Änderungszeit“ – ein Szenario, in dem ein reiner Größen- und Zeitstempelvergleich keine verlässliche Aussage mehr trifft. Der Abgleich über Hash ist langsamer, aber eindeutiger. Die Sync-Engine moderner Clients setzt ihn deshalb selektiv ein und nicht auf jeder Datei.

Der Upload im Detail: warum Chunks die Sache komplizierter machen

Größere Dateien lädt der Nextcloud-Client in Stücken hoch. Das Verfahren ist unter dem Namen Chunked Upload bekannt, intern gibt es mehrere Generationen davon. Für die Prüfsummenlogik ist vor allem eines relevant: Einzelne Chunks lassen sich nicht sinnvoll gegen den Hash der Gesamtdatei verifizieren. Der Hash ergibt sich erst aus der Konkatenation.

Die Lösung liegt darin, den finalen Hash im letzten Schritt mitzuschicken – bei der MOVE-Anfrage, die das temporäre Upload-Verzeichnis in die Zielstruktur überführt. Trifft dort ein SHA-256-Wert ein, vergleicht der Server gegen das zusammengesetzte Ergebnis. Stimmt es nicht überein, wird der Upload verworfen, und die Ziel-Datei bleibt unangetastet. Das ist einer der Gründe, warum Nextcloud große Dateien lieber einmal komplett scheitern lässt, als eine still beschädigte Datei zu akzeptieren.

In der Praxis führt das gelegentlich zu Frust: Wer hinter einem Proxy mit aggressivem Timeout arbeitet, sieht Uploads abbrechen, die nach 95 Prozent fertig aussahen. Die Fehlermeldung ist dann oft wenig aufschlussreich, im Log findet sich aber meist ein Hinweis auf die abweichende Prüfsumme. Nicht zuletzt deshalb lohnt es sich, die Chunk-Größe an die Netzbedingungen anzupassen.

Der Datenbank-Cache und seine Tücken

Weil die Checksumme Teil des Dateicaches ist, kann sie in einen inkonsistenten Zustand geraten. Typische Ursache: Jemand verschiebt Dateien direkt im Storage-Verzeichnis, ohne den Cache zu aktualisieren. Der Server glaubt dann, unter einem Pfad liege eine Datei mit einem bestimmten Hash, während dort tatsächlich eine andere liegt. Von außen sieht die Instanz gesund aus, bis ein Client eine Prüfung anfordert und einen Mismatch meldet.

Der korrekte Weg aus dieser Lage führt über occ files:scan, das den Cache neu aufbaut. Wichtig ist der Parameter --path, wenn nur ein Teilbereich betroffen ist; ein vollständiger Scan über mehrere Terabyte kann Stunden dauern und die Datenbank erheblich belasten.

occ files:scan --path="/alice/files/Projekte"
occ files:scan --all
occ files:scan-app-data

Ein Missverständnis begegnet einem dabei immer wieder: files:scan berechnet nicht grundsätzlich neue Prüfsummen. Der Befehl liest in erster Linie Größe und Änderungszeitpunkt. Wo bereits ein Hash vorlag und die Datei unverändert scheint, wird er nicht angetastet. Wer nach einer Migration vollständige Hashes über alle Daten benötigt, kommt um einen expliziten Verifikationslauf nicht herum – je nach Version über occ files:checksums:verify oder über Werkzeuge, die die Dateien selbst durchrechnen und die Ergebnisse in den Cache zurückschreiben.

Ein Wort zu Reparatur und Aufräumen

occ maintenance:repair ist nicht das Werkzeug der Wahl, wenn es um Checksummen geht. Der Befehl kümmert sich um Mimetypes, fehlende Indizes, verwaiste Einträge und ähnliche Hausmeisterarbeiten. Er kann indirekt helfen, weil eine inkonsistente Datenbank auch inkonsistente Hashzuordnungen produziert, aber er rechnet keine Dateien durch. Wer das verwechselt, sucht mitunter lange nach dem Grund, warum eine Meldung hartnäckig bleibt.

Ähnliches gilt für occ files:cleanup: Der Befehl entfernt verwaiste Cacheeinträge, also Zeilen ohne zugehörige Datei. Auch hier wird nichts verifiziert, nur aufgeräumt. Die Reihenfolge in der Praxis lautet deshalb: erst scannen, dann reparieren, dann verifizieren. Nicht umgekehrt.

Externe Speicher und Object Storage: wo die Rechnung nicht aufgeht

Nextcloud kann Daten auf externen Speichern ablegen: SMB-Freigaben, SFTP, NFS, S3-kompatible Objektspeicher. Spätestens hier wird die Sache uneinheitlich. Ein SFTP-Server liefert keine Prüfsummen über den Standardweg. NFS schon gar nicht. Bei S3 gibt es das ETag, das bei einfachen Uploads dem MD5 der Datei entspricht – bei mehrteiligen Uploads aber aus den ETags der Teile zusammengesetzt wird und mit dem Hash der Gesamtdatei nichts mehr zu tun hat.

Daraus folgen zwei praktische Konsequenzen. Erstens: Prüfsummen, die aus dem Cache stammen, sind bei externen Speichern mit Vorsicht zu genießen. Zweitens: Wer eine belastbare Integritätsprüfung braucht, muss die Datei tatsächlich lesen und selbst rechnen. Bei mehreren hundert Terabyte ist das ein Kostenfaktor, den man einplanen sollte.

Immerhin: Bei reinem Object Storage als primärem Storage entfällt der klassische lokale Dateicache-Pfad teilweise, weil der Server die Objekte direkt verwaltet. Die Hashlogik bleibt dieselbe, die Fehlerbilder sehen nur anders aus. Statt einer fehlenden Datei auf einem lokalen Volume gibt es dann einen 404 vom S3-Endpunkt – eine Fehlermeldung, die einen anfangs in die falsche Richtung schicken kann.

Ende-zu-Ende-Verschlüsselung: die Grenze der Prüfbarkeit

Bei aktivierter Ende-zu-Ende-Verschlüsselung verlassen Dateien das Client-Gerät bereits verschlüsselt. Der Server sieht nur Chiffretext. Er kann technisch einen Hash über den vorliegenden Blob berechnen und speichern, aber dieser Hash sagt nichts über die Korrektheit des Klartexts aus. Für den Anwender ist das kein Nachteil, für den Administrator eine Einschränkung, die in Supportfällen regelmäßig für Überraschung sorgt.

Interessant ist, dass die klassische Server-side-Encryption, also die Verschlüsselung durch Nextcloud selbst, dieses Problem nicht hat. Hier kennt der Server den Schlüssel, kann entschlüsseln und kann prüfen. Zwischen beiden Verfahren liegen Welten – nicht nur in der Schutzwirkung, sondern auch in der Betriebslogik.

Diagnose in der Praxis: ein Werkzeugkasten

Wenn eine Prüfsummenmeldung im Raum steht, hilft eine geordnete Vorgehensweise mehr als hektisches Suchen in Logdateien. Bewährt hat sich folgende Reihenfolge:

# 1. Code-Integrität prüfen
occ integrity:check-core
occ integrity:check-apps

# 2. betroffene App einzeln prüfen
occ integrity:check-app better_search

# 3. Cache neu einlesen
occ files:scan --path="/nutzer/files/ordner"

# 4. Status der Instanz einschätzen
occ status
occ maintenance:repair --dry-run

Wer die Meldungen der Code-Integrität im Browser vorfindet – als Administrator sieht man sie im Überblick der Instanz –, kann sie dort auch als „akzeptiert“ markieren. Das ist sinnvoll, wenn man Änderungen selbst vorgenommen hat, etwa durch Patches oder Anpassungen an der Oberfläche. Es ist ein schlechter Reflex, wenn man die Ursache nicht kennt. Ein abgenickter Hash ist ein dauerhaftes Schweigen, und Schweigen ist bei Integritätsfragen selten gut.

Fehlerbilder, die einem häufiger begegnen

„Checksum mismatch“ direkt nach einem Upload. Meist ein Client- oder Proxyproblem. Zuerst prüfen, ob ein Reverse Proxy die Anfrage puffert oder verändert. Dann den Client aktualisieren. In seltenen Fällen ist der Client schlicht zu alt für das gesendete Hashverfahren, was dann zu einem stummen Vergleich gegen MD5 führt.

Datei erscheint doppelt. Hier haben sich Cache und Dateisystem auseinandergelebt. Der Pfad zeigt auf einen Ort, die Datei liegt an einem anderen. Ein Scan mit --path und anschließendes Aufräumen bringt das wieder zusammen, sofern die Daten tatsächlich nur einmal existieren.

Nach einer Migration meldet jeder Client Änderungen. Klassiker nach einem Umzug mit rsync oder einem Wechsel des Storage-Backends. Änderungszeitpunkte haben sich verschoben, Hashes sind leer. Hier hilft nur ein vollständiger Scan und – wenn man es genau wissen will – eine Verifikation. Achtung: Ein solcher Lauf ist I/O-lastig und sollte außerhalb der Kernzeiten stattfinden, idealerweise im Wartungsmodus.

Warnung bleibt nach dem Entfernen der Datei bestehen. Meist liegt der Eintrag noch in der Datenbank. occ files:cleanup hilft, oder ein gezielter Scan des betroffenen Ordners.

Backup, Restore und die Versuchung der Abkürzung

Ein weitverbreiteter Irrglaube lautet, Prüfsummen seien eine Form von Backup. Sie sind das Gegenteil. Sie stellen fest, dass etwas kaputt ist, und sie können, wenn redundante Kopien existieren, beim Reparieren helfen. Ersetzen können sie keine Sicherung, weil sie selbst mit der defekten Datei untergehen können.

In einer sauberen Sicherungsstrategie spielen sie trotzdem eine wichtige Rolle, und zwar auf der Backup-Seite. Wird ein Backup über Jahre weitergereicht – Band, Object Storage, Offsite-Kopie –, lässt sich mit einem manifestierten Hash nachweisen, dass die wiederhergestellte Datei mit der gesicherten identisch ist. Ohne diesen Nachweis bleibt nur die Annahme, dass es schon passen wird.

Beim Restore ist die Reihenfolge entscheidend. Erst Instanz in den Wartungsmodus, dann Dateisystem zurückspielen, dann Datenbank, dann Cache neu aufbauen. Wer die Datenbank vor den Dateien zurückspielt oder umgekehrt, bekommt genau jene Inkonsistenz, die man eigentlich vermeiden wollte. Nach dem Restore ist ein vollständiger Scan Pflicht, nicht Kür.

Performance: warum nicht alles immer geprüft wird

Es gibt Administratoren, die den Wunsch äußern, jede Datei bei jedem Zugriff zu verifizieren. Technisch machbar, betriebswirtschaftlich selten sinnvoll. SHA-256 läuft auf moderner Hardware mit mehreren hundert Megabyte pro Sekunde, bei einer NVMe mit mehreren Gigabyte pro Sekunde ist die CPU dann der Flaschenhals. Über zehn Terabyte gerechnet, reden wir von Stunden reiner Rechenzeit – ohne den I/O, der parallel anfällt.

Der pragmatische Mittelweg: Hashes einmal beim Schreiben erzeugen, sie beim Lesen nutzen, und in größeren Abständen stichprobenartig verifizieren. Manche Häuser fahren einmal im Quartal einen vollständigen Verifikationslauf über einen Teilbestand, meist über die besonders kritischen Ordner. Das ist kein vollständiger Schutz, aber es ist einer, der im Betrieb überlebt.

Wichtig ist auch die Frage, welche Last man erzeugt. Ein Verifikationslauf über die gesamte Instanz zur Hauptgeschäftszeit ist ein Eigentor. Wer ihn plant, sollte Wartungsfenster nutzen, die Datenbank im Blick behalten und die Zeitfenster für Hintergrundjobs entsprechend anpassen.

Altlasten und die Frage der Verfahrenswahl

In gewachsenen Installationen finden sich MD5-Werte aus frühen Versionen, teils jahrelang unangetastet. Das ist nicht dramatisch, solange sie nicht als Sicherheitsmerkmal missverstanden werden. Wer Migrationsprojekte betreut, sollte sich überlegen, bei welcher Gelegenheit man diese Altbestände ersetzt. Ein vollständiger Rehash über alle Daten ist schmerzhaft, aber einmalig. Der Aufwand lohnt sich vor allem dort, wo Prüfsummen tatsächlich zur Integritätsaussage herangezogen werden.

Auch die Frage, ob ein Hash überhaupt vertrauenswürdig ist, hängt vom Kontext ab. Ein Hash, den ein Client beim Upload mitschickt, beweist nur, dass der Client ihn berechnet hat. Er beweist nicht, dass der Client ehrlich war. Als Schutz gegen Netzwerkfehler ist das ausreichend, als Schutz gegen einen kompromittierten Client nicht. Wer in einer Hochsicherheitsumgebung arbeitet, braucht beides: Transportintegrität und Vertrauen in die Endpunkte.

Was in Zukunft zu erwarten ist

Einige Entwicklungen zeichnen sich ab. Schnellere Hashverfahren wie BLAKE3 werden dort interessant, wo große Datenmengen effizient geprüft werden müssen – etwa in Dateisystemen mit Content-defined Chunking, wo Änderungen an einer Datei nicht den gesamten Hash invalidieren. Der Grundgedanke ist nicht neu: Schon heute zerlegen Backup-Werkzeuge Dateien in Blöcke und speichern Hashes pro Block, was inkrementelle Sicherungen erst praktikabel macht.

Parallel dazu wächst der Druck, Integrität nicht nur pro Datei, sondern pro Speicherebene zu denken. Objektspeicher mit eingebauten Prüfmechanismen, Dateisysteme mit eigener Datenintegrität, Ende-zu-Ende-Verschlüsselung mit authentifizierten Verfahren – all das verschiebt die Zuständigkeit. Nextcloud wird auch in Zukunft nicht alles selbst prüfen, sondern sich auf das verlassen, was die darunterliegende Schicht liefert. Wer das weiß, kann seine Prüfstrategie gezielt auf die Lücken ausrichten, die übrig bleiben.

Fazit

Checksummen sind das Bindeglied zwischen der Annahme, dass Daten übertragen wurden, und der Gewissheit. In Nextcloud begegnen sie einem an mehr Stellen, als man zunächst vermutet: bei der Code-Integrität, beim Upload, im Dateicache, in der WebDAV-Auskunft, im Backup. Ihre Stärke ist die Eindeutigkeit, ihre Schwäche ist der blinde Fleck – dort, wo keine Prüfung stattfindet, wird auch kein Fehler gemeldet, und das kann beruhigend wirken, bis es das nicht mehr tut.

Wer die Mechanismen kennt, kann sie gezielt einsetzen und im Störfall schneller handeln. Wer sie ignoriert, merkt es erst, wenn eine Sync-Kette unerklärlich hakt oder ein Restore nicht das zurückbringt, was erwartet wurde. Die stille Wache arbeitet zuverlässig – aber sie arbeitet nur dort, wo man sie aufgestellt hat.

Die stille Wache Wie Checksummen in Nextcloud Integrität sichern