Platte voll bei Owncloud

Einige unserer Nutzerinnen und Nutzer meldeten, dass sie plötzlich keine Dateien mehr hochladen konnten. Der Fehler trat auf, obwohl ihr persönliches Speicher-Kontingent (Quota) laut Anzeige noch lange nicht ausgeschöpft war. Was zunächst wie ein kleiner Bug in der Speicheranzeige wirkte, entpuppte sich als Symptom eines viel größeren Problems.

Denn in Wirklichkeit war nicht der Speicher der Nutzerinnen und Nutzer voll – sondern die Datenplatte des Servers selbst.

Ein Logfile, das zum Speicherfresser wurde

Innerhalb weniger Stunden war die Datenpartition des Servers restlos gefüllt. Der Grund: Das ownCloud-Logfile wurde in atemberaubendem Tempo mit Fehlermeldungen geflutet. Jede einzelne Verbindung von einem bestimmten Gerät führte zu einem neuen Eintrag im Log.

Der Fehler lautete:

hash_hmac(): Unknown hashing algorithm: sha1

Und dieser wurde nicht einmal, nicht hundertmal, sondern tausendfach pro Stunde ausgelöst.

Die eigentliche Ursache

Die Analyse führte uns zu einer überraschenden Quelle: Einer Android-App, die zur ownCloud-Synchronisierung eingesetzt wurde (z. B. die offizielle ownCloud-App oder ein WebDAV-Client), hatte ein Update erhalten. Die neue Version verwendete nun vermehrt eigene Authentifizierungs- und Zugriffsmethoden.

Diese Zugriffsmethoden aktivierten in ownCloud eine Funktion, die intern mit der PHP-Bibliothek phpseclib arbeitet. Dort kommt hash_hmac() zum Einsatz, um Daten sicher zu vergleichen – etwa bei Tokens oder API-Zugriffen.

Unter bestimmten Bedingungen – speziell in Kombination mit mod_php (PHP direkt in Apache eingebunden) – kann es passieren, dass hash_hmac() nicht korrekt initialisiert wird. Das Ergebnis: PHP erkennt den gängigen Algorithmus sha1 nicht, wirft eine Warnung – und ownCloud schreibt diese ins Log.

Da die App viele kleine Zugriffe in kurzer Zeit durchführt, eskalierte das Problem schnell.

Warum trat das Problem plötzlich auf?

Der Server lief seit Jahren nahezu unverändert. ownCloud-Version, PHP-Version, Systemkonfiguration – alles stabil. Und doch trat das Problem jetzt, fast ohne Vorwarnung, auf.

Der Grund: Nicht der Server, sondern ein Client hatte sich verändert.

Durch ein App-Update wurde eine Funktion aktiviert, die ownCloud zwar bereitstellte, bisher aber kaum genutzt wurde. Das ist in der IT nicht ungewöhnlich: Systeme verhalten sich manchmal über Jahre unauffällig – bis jemand plötzlich eine kaum getestete Ecke des Codes berührt.

Die Lösung: Umstieg auf PHP-FPM

Die betroffene ownCloud-Instanz lief bis dahin unter mod_php, einer klassischen Variante, PHP direkt in Apache einzubetten.

Die einfache und effektive Lösung war der Wechsel auf PHP-FPM (FastCGI Process Manager).

Nach der Umstellung:

• Tritt der Fehler nicht mehr auf

• Das Logfile bleibt ruhig

• Der Server reagiert merklich schneller

PHP-FPM ist die moderne und empfohlene Methode, PHP auf dem Server zu betreiben. Sie bietet bessere Performance, saubere Prozessverwaltung und deutlich weniger Nebeneffekte bei parallelen Zugriffen.

Was steckt technisch dahinter? (Kurz erklärt)

Die klassische Variante, PHP über mod_php zu betreiben, bindet PHP direkt in den Webserver (Apache) ein. Das hat früher gut funktioniert, bringt aber auch Risiken mit sich: Wenn der Webserver länger läuft oder viele parallele Anfragen verarbeitet, kann es passieren, dass bestimmte PHP-Module (z. B. für Verschlüsselung) nicht korrekt geladen oder initialisiert werden. Dadurch kann PHP nicht mehr richtig arbeiten – wie im Fall von hash_hmac().

PHP-FPM trennt diese Prozesse voneinander: Jeder Zugriff bekommt eine sauber initialisierte Umgebung. Deshalb treten solche Fehler unter PHP-FPM in der Regel nicht auf.

Kurz gesagt: mod_php kann in bestimmten Fällen „durcheinanderkommen“, PHP-FPM arbeitet sauberer.

Fazit

Manchmal reicht ein kleines App-Update, um ein lang stabil laufendes System aus dem Gleichgewicht zu bringen.

In unserem Fall war es eine Kombination aus einer harmlosen App, einer versteckten Funktion in ownCloud und einem technischen Sonderfall in PHP, der dazu führte, dass die Datenplatte innerhalb weniger Stunden vollgeschrieben wurde.

Mit der Umstellung auf PHP-FPM war das Problem behoben – und der Server ist nun nicht nur stabiler, sondern auch flotter als zuvor.