Nextcloud – Das Problem mit großen Uploads…

**Wenn große Uploads plötzlich nicht mehr funktionieren oder

”Oida – setzt doch endlich die upload_max_filesize hoch!”**

Neben der IMAP-Anmeldung zeigte sich nach dem Upgrade auf Nextcloud ein weiteres, unerwartetes Problem:

Der Upload großer Dateien funktionierte nicht mehr.

Viele vermuteten sofort eine falsche Einstellung in der php.ini – zu kleine Werte bei upload_max_filesize oder post_max_size.
Doch die Wahrheit lag – wie so oft – deutlich tiefer im System.

Unsere Architektur ist nicht ganz ohne

Unsere Nextcloud läuft nicht auf einem einzelnen Server, sondern auf einer verteilten Hochverfügbarkeits-Architektur mit

• Load Balancer
• zwei Application-Servern (Nginx + PHP-FPM)
• PgBouncer für Connection-Pooling
• CephFS-Storage auf einem Ceph-Cluster
• und einem PostgreSQL-Patroni-Cluster für Datenbank-Redundanz.

Wenn in so einem System ein Upload fehlschlägt, ist die Ursache selten eine vergessene Zeile in der php.ini.

[Bild nur für eingeloggte Mitglieder sichtbar]

Hinweis zur Architektur-Grafik

Die dargestellte Nextcloud-Architektur zeigt das grundsätzliche Funktionsprinzip der Umgebung – sie ist bewusst vereinfacht dargestellt, um die wichtigsten Komponenten und Abhängigkeiten nachvollziehbar zu machen.

In der Realität ist das System deutlich umfangreicher:

• Der Ceph-Cluster besteht aus sechs physischen Servern, die gemeinsam für verteilten, ausfallsicheren Speicher sorgen.
• Der PostgreSQL-Patroni-Cluster läuft auf vier Nodes und gewährleistet Datenkonsistenz und Hochverfügbarkeit. Diese vier Maschinen hängen wiederum hinter einem Load-Balancer der die Ausfallsicherheit gewährleistet
• Zusätzlich existieren separate Systeme für Monitoring, Backup, Logging, Mailrouting und DNS, die in der Grafik nicht abgebildet sind, um die Übersichtlichkeit zu wahren.

Diese Infrastruktur bildet das Rückgrat der 4future.digital-Plattform – sie stellt sicher, dass unsere Dienste auch unter hoher Last stabil, sicher und performant bleiben.

Wie Nextcloud große Uploads handhabt

Nextcloud nutzt für Datei-Uploads das WebDAV-Protokoll.
Um auch sehr große Dateien zuverlässig übertragen zu können, werden diese in viele kleine Chunks (Datenblöcke) zerlegt und einzeln hochgeladen.

Erst ganz am Ende versucht der Browser, diese Teilstücke über einen WebDAV MOVE-Befehl an ihren endgültigen Speicherort zu verschieben und so die vollständige Datei „zusammenzuleimen“.

Genau hier lag das Problem:
Der MOVE-Befehl scheiterte mit der Meldung „Method not allowed“.

Der unscheinbare Unterschied zwischen alt und neu

In älteren Nextcloud-Versionen wurde das Zusammenfügen der Chunks etwas anders umgesetzt. Mit einer Architektur-Änderung im WebDAV-Subsystem führte Nextcloud den Upload nun anders aus.

Gleichzeitig verhinderte eine Sicherheits-Direktive in Nginx, dass MOVE-Operationen auf genau diese Pfade ausgeführt werden durften.
Was früher problemlos funktionierte, wurde plötzlich blockiert – nicht wegen eines Fehlers in PHP, sondern wegen verbesserter Sicherheit im Webserver.

Das spannende dabei: Der Client funktionierte nach wie vor, weil er noch immer die alte WebDav Implementierung für die Uploads verwendete.

Die Lösung

Nach intensiver Analyse stellte sich heraus, dass lediglich eine Anpassung der Nginx-Konfiguration nötig war, um den MOVE-Befehl auf diese temporären Upload-Verzeichnisse wieder zuzulassen.

Seitdem funktioniert der Upload großer Dateien wieder zuverlässig

Was wir daraus gelernt haben

Dieses Beispiel zeigt, wie empfindlich das Zusammenspiel moderner Open-Source-Architekturen sein kann.
Ein einziges Sicherheits-Setting in einem der beteiligten Systeme kann dazu führen, dass ein scheinbar triviales Feature wie „Datei hochladen“ nicht mehr funktioniert.

Oder, wie man im Wiener Dialekt sagen würde:

Nicht der Upload war zu klein – die Architektur war zu g’scheit. 

Technischer Hintergrund (Kurzfassung)

• Nextcloud lädt große Dateien in Chunks hoch.
• Diese werden am Ende per WebDAV MOVE zu einer Datei zusammengeführt.
• Eine Nginx-Sicherheitsrichtlinie blockierte diesen MOVE.
• Durch Anpassung der Konfiguration konnte das Verhalten korrigiert werden.

Open Source kostet Zeit – auch wenn sie kostenlos ist

Der Aufwand, um den Fehler zu finden und zu beheben, betrug rund zwei volle Arbeitstage.

Ein externer Systemingenieur hätte dafür – bei einem marktüblichen Stundensatz von etwa 100 € – rund 1 500 bis 2 000 € verrechnet.

Diese Arbeit wurde ehrenamtlich im Rahmen unserer Infrastrukturpflege erbracht – nicht, weil sie einfach war, sondern weil digitale Souveränität bedeutet, Probleme selbst lösen zu können.

Wenn Du solche Projekte unterstützen möchtest, freuen wir uns über eine Spende an die 4future.foundation oder eine Fördermitgliedschaft in der 4future.community.
So helfen Sie mit, dass offene, unabhängige Lösungen auch in Zukunft weiterentwickelt werden.

Jetzt Spenden

Fördermitglied werden.