Problembehebung beim Hochladen von Dateien mit ownCloud bei 99 %: Praktischer Leitfaden zur Fehlerbehebung

Ein ownCloud-Upload, der 99 Prozent erreicht und dann scheinbar hängen bleibt, lässt sich in der Regel nicht durch wiederholtes Neustarten des Uploads beheben. Zu diesem Zeitpunkt hat der Browser möglicherweise bereits den Großteil oder die gesamte Datei übertragen, während der Server noch Aufgaben wie das Empfangen des letzten Datenblocks, das Zusammensetzen der Datenblöcke, das Verschieben der fertigen Datei an ihren Zielort, das Aktualisieren der Metadaten oder das Aufheben von Sperren erledigt. Der Prozentsatz allein gibt die Ursache nicht an. Daher ist es am schnellsten, die serverseitigen Informationen in einer festgelegten Reihenfolge zu überprüfen.

Diese Anleitung basiert auf der aktuellen ownCloud Server 11.0-Administrationsdokumentation (Stand: Oktober 2026). Die beschriebenen Vorgehensweisen gelten auch für viele ownCloud Classic-Bereitstellungen, jedoch können Konfigurationspfade und das Verhalten von Docker in älteren Versionen abweichen. Prüfen Sie vor dem Ändern von Limits Ihre installierte Version und Bereitstellungsmethode.

Checkliste für die Schnelldiagnose

1. Reproduzieren Sie den Fehler einmal und überprüfen Sie anschließend sofort die Protokolle.

Führen Sie einen kontrollierten Upload mit einer Datei durch, die das Problem zuverlässig reproduziert, und notieren Sie den genauen Zeitpunkt. Untersuchen Sie anschließend das ownCloud-Protokoll, das PHP-Protokoll und das Fehlerprotokoll des Webservers um diesen Zeitpunkt herum. Nehmen Sie nicht vorher mehrere Konfigurationsänderungen vor; dadurch wird es schwieriger festzustellen, welche Ebene tatsächlich den Fehler verursacht hat.

Die offizielle Fehlerbehebungsdokumentation von ownCloud empfiehlt ausdrücklich, zuerst die PHP-, Apache- und ownCloud-Logs zu überprüfen. Bei der Standard-Docker-Bereitstellung dokumentiert ownCloud, dass die Ausgabe von Apache und PHP über die Container-Standardausgabe (stdout) und Standardfehlerausgabe (stderr) geleitet wird, und schlägt vor, die Container-Logs anschließend zu überprüfen docker compose logs owncloud -f.

Das ownCloud-Protokoll ist auch über die Admin-Oberfläche abrufbar. Die ownCloud-Protokoll- und Konfigurationsanleitung beschreibt den Pfad über Einstellungen > Admin > Allgemein und bietet eine occ configreport:generateOption, falls ein ausführlicherer Konfigurationsbericht benötigt wird.

Auf welche Protokollmeldungen sollten Sie achten?

Konzentrieren Sie sich auf den ersten Fehler im Zusammenhang mit der fehlgeschlagenen Anfrage, nicht auf jede nachfolgende Warnung. Hilfreiche Kategorien sind beispielsweise Anfrage-Timeouts, unzureichender Speicherplatz, Probleme beim Erstellen oder Umbenennen einer temporären Datei, Berechtigungsfehler, WebDAV-Ausnahmen, HTTP-Fehler 413/502/504 und Dateisperrungsfehler. Wenn Sie die ownCloud-Protokollierung vorübergehend auf DEBUG erhöhen, stellen Sie sie anschließend wieder auf das normale Niveau zurück. ownCloud weist darauf hin, dass eine ausführliche Protokollierung die Serverleistung beeinträchtigen kann. Weitere Informationen finden Sie in der offiziellen Dokumentation zur Protokollierungskonfiguration .

2. Prüfen Sie den freien Platz sowohl an den temporären Standorten als auch im endgültigen Lagerraum.

Dies ist eine der wichtigsten Prüfungen, um einen 99-prozentigen Stillstand zu verhindern. ownCloud Server 11.0 erklärt, dass Uploads mehrere temporäre Bereiche nutzen können. Das temporäre PHP-Upload-Verzeichnis muss Speicherplatz für aktive Chunks bieten, während das Benutzer-Upload-Verzeichnis die Chunks für eine Datei sammelt, bis der Upload abgeschlossen ist.

Laut der ownCloud-Dokumentation zum Hochladen großer Dateien sollte der temporäre PHP-Speicherplatz grob anhand der Anzahl gleichzeitiger Uploads multipliziert mit der Chunk-Größe eingeplant werden. Wichtiger noch: Bei einer großen Einzeldatei benötigt das Upload-Verzeichnis des Benutzers temporär Speicherplatz in der Größenordnung der endgültigen Dateigröße, da es die Chunks bis zum Abschluss der Zusammenführung speichert. Sobald der Upload abgeschlossen ist, schreibt ownCloud die Chunks an den endgültigen Zielort und löscht sie.

Überprüfen Sie das Dateisystem, das das Datenverzeichnis, das temporäre PHP-Verzeichnis und alle über die Konfiguration festgelegten Speicherorte enthält OWNCLOUD_DAV_CHUNK_BASE_DIR. Überprüfen Sie auch das tatsächliche Ziel, insbesondere bei externem Speicher. Ein Server kann über ausreichend freien Speicherplatz verfügen, /während ein separates Datenvolume voll ist.

Verschieben Sie keine Dateien manuell in oder aus dem ownCloud-Datenverzeichnis, um den Upload abzuschließen. ownCloud weist darauf hin, dass das Datenverzeichnis exklusiv für die Anwendung bestimmt ist; direkte Änderungen können zu Synchronisierungs- und Datenbankinkonsistenzen führen.

3. Quote vor Erhöhung der technischen Limits bestätigen.

Ein Benutzerkontingent kann das Hochladen einer großen Datei verhindern, selbst wenn im Upload-Bereich ausreichend Speicherplatz vorhanden ist. Überprüfen Sie das Kontingent des betroffenen Benutzers und gegebenenfalls die Kapazität und Berechtigungen eines externen Speichermediums. Ein hilfreicher Test ist das Hochladen derselben Datei auf ein anderes Konto oder einen anderen Speicherort mit ausreichend Speicherplatz. Tritt das Problem beim Benutzer oder Ordner und nicht bei der Datei auf, ist das Kontingent oder die Speicherrichtlinie die wahrscheinlichste Ursache.

4. PHP- und ownCloud-Upload-Einstellungen überprüfen

Wenn die Protokolle auf Limits für die Anforderungsgröße oder die Ausführung hinweisen, überprüfen Sie die effektiven PHP-Einstellungen, anstatt anzunehmen, dass die Werte in einer beliebigen php.iniDatei aktiv sind. Gängige Direktiven sind beispielsweise post_max_size` upload_max_filesize<request>`, upload_tmp_dir`<request> `, `<request>`, ` max_input_time<request> max_execution_time` und `<request> memory_limit`.

Für die unterstützte Docker-basierte ownCloud Server 11.0-Konfiguration ordnet die Dokumentation diese den folgenden Umgebungsvariablen zu: OWNCLOUD_MAX_UPLOAD, OWNCLOUD_TEMP_DIRECTORY, OWNCLOUD_MAX_INPUT_TIME, OWNCLOUD_MAX_EXECUTION_TIME, und OWNCLOUD_MEMORY_LIMIT. Dies ist wichtig, da ownCloud angibt, dass Bereitstellungen mit der Docker-Konfiguration die bereitgestellten Umgebungsvariablen verwenden sollten, anstatt auf ältere PHP- oder .htaccessAnpassungsmuster zurückzugreifen.

Setzen Sie nicht einfach alle Grenzwerte auf extrem hohe Werte. Ein besserer Zielwert ist ein Wert, der Ihre maximal beabsichtigte Dateigröße und die langsamste zulässige Verbindung berücksichtigt und gleichzeitig die betrieblichen Sicherheitsvorkehrungen wahrt.

5. Überprüfen Sie die Sitzungsdauer bei langsamen Uploads.

ownCloud weist ausdrücklich darauf hin, dass session_lifetimedie Upload-Dauer nicht kürzer als die längste erwartete Upload-Dauer sein darf. Wenn Sie eine benutzerdefinierte Einstellung vorgenommen haben, legen Sie diese mindestens auf die Anzahl der Sekunden fest, die für den langsamsten erwarteten Upload benötigt werden, oder entfernen Sie einen unnötigen benutzerdefinierten Wert und stellen Sie das unterstützte Standardverhalten wieder her.

Dies ist insbesondere dann zu überprüfen, wenn eine 500 MB große Datei fertig verarbeitet wird, eine mehrere Gigabyte große Datei jedoch nach etwa der gleichen Zeitspanne wiederholt nicht verarbeitet werden kann.

6. Testen Sie den Reverse-Proxy oder das CDN separat.

Die Dokumentation von ownCloud zu großen Dateien weist darauf hin, dass clientseitige Proxys und Dienste wie Cloudflare Uploads einschränken können. Das bedeutet, dass selbst ein optimal konfigurierter ownCloud/PHP-Stack fehlschlagen kann, weil ein anderer Zwischenschritt den Anfragetext begrenzt, eine lange Anfrage zwischenspeichert, eine inaktive Verbindung schließt oder ein Timeout auftritt, während ownCloud den Upload zusammenstellt.

Wenn Ihre Architektur einen sicheren administrativen Test zulässt, vergleichen Sie denselben Upload über den normalen öffentlichen Weg und über einen Pfad, der den Reverse-Proxy oder das CDN umgeht. Wenn der direkte Pfad erfolgreich ist, prüfen Sie die offizielle Dokumentation des jeweiligen Zwischenhändlers hinsichtlich Anfragegröße, Upload-Timeout, Pufferung und WebDAV-Verhalten. Schwächen Sie TLS nicht und legen Sie das Backend nicht öffentlich offen, nur um diesen Test durchzuführen.

7. Überprüfen Sie die Dateisperrung, wenn Uploads während der Finalisierung fehlschlagen.

Die transaktionale Dateisperrung ist standardmäßig aktiviert und schützt Dateien vor gleichzeitiger Änderung. ownCloud weist darauf hin, dass dies auch beim Zusammensetzen von Teil-Uploads relevant ist. Auf stark ausgelasteten Servern kann ein Sperrproblem wie eine abgeschlossene, aber nicht korrekt bestätigte Übertragung aussehen.

Lesen Sie die Dokumentation zur Transaktionsdateisperrung, bevor Sie Änderungen an diesem Subsystem vornehmen. ownCloud empfiehlt für Sperrungen bei hoher Arbeitslast ein Speichercache-Backend anstelle von Datenbanksperren. In Clusterumgebungen ist die gemeinsame Redis-Sperrung besonders wichtig, da jeder Anwendungsknoten denselben Sperrstatus sehen muss.

Für sehr lange Uploads in öffentliche Ordner ohne Chunking ist ein Sonderfall dokumentiert. ownCloud gibt an, dass Uploads, die länger als eine Stunde dauern, möglicherweise eine ausreichend große Sperre erfordern OWNCLOUD_FILELOCKING_TTL; andernfalls kann die Redis-Speicherbereinigung die zu Beginn des Vorgangs erworbene Sperre entfernen. Ändern Sie diese Einstellung nur, wenn Ihr Upload-Pfad diesem Szenario entspricht.

8. Nach jeder Änderung methodisch erneut testen.

Nachdem Sie ein identifiziertes Problem behoben haben, versuchen Sie es erneut mit derselben Datei, demselben Konto, demselben Ziel, demselben Browser und demselben Netzwerkpfad. Überprüfen Sie anschließend drei Dinge: Der Vorgang wurde abgeschlossen, die Datei ist im Zielverzeichnis in der erwarteten Größe vorhanden und die Protokolle enthalten keinen neuen Fehler für diese Anfrage.

Eine sinnvolle Vorgehensweise ist: eine kleine Datei, eine mittelgroße Datei und schließlich die Datei, bei der der Fehler ursprünglich auftrat. Wenn kleine Dateien immer funktionieren, Fehler aber ab einer bestimmten Größe auftreten, sollten Sie die Speicherkapazität und Größenbeschränkungen überprüfen. Treten die Fehler nach einer bestimmten Zeitspanne auf, sollten Sie Sitzungen und Timeouts analysieren. Treten die Fehler nur über einen bestimmten Hostnamen oder Netzwerkpfad auf, sollten Sie Proxys und Load Balancer überprüfen.

Was man nicht tun sollte

• Versuchen Sie nicht wiederholt, mehrere Gigabyte große Datenmengen hochzuladen, ohne die Protokolle zu überprüfen. Wiederholte fehlgeschlagene Uploads kosten Zeit und können vorübergehend Speicherplatz belegen.
• Ändern Sie das ownCloud-Datenverzeichnis nicht manuell. Verwenden Sie ownCloud, WebDAV oder unterstützte Verwaltungstools.
• Deaktivieren Sie die Dateisperrung nicht als erste Maßnahme. Die Sperrung schützt die Datenintegrität; analysieren Sie stattdessen das Backend.
• Gehen Sie nicht davon aus, dass eine PHP-Einstellung wirksam ist, nur weil sie in einer Konfigurationsdatei erscheint. Container, PHP-FPM, Apache-Module und mehrere INI-Speicherorte können zu unterschiedlichen wirksamen Einstellungen führen.
• Setzen Sie nicht jedes Timeout unbegrenzt in die Höhe. Ermitteln Sie die Ebene, die die Anfrage abbricht, und legen Sie ein Limit fest, das der maximal unterstützten Upload-Größe entspricht.

Praktischer Entscheidungsweg

Falls Sie eine kurze Anleitung benötigen, gehen Sie wie folgt vor: Reproduzieren Sie den Fehler einmal; lesen Sie die ownCloud-/PHP-/Webserver-Logs; prüfen Sie Daten-, temporäre und Chunk-Speicher; verifizieren Sie das Kontingent; bestätigen Sie die effektiven Upload- und Zeiteinstellungen; prüfen Sie die Sitzungsdauer; umgehen oder untersuchen Sie den Reverse-Proxy/CDN; untersuchen Sie anschließend die Transaktionssperrung. Diese Reihenfolge priorisiert die Auswertung von Beweisen und die Prüfung der wahrscheinlichsten Infrastrukturbeschränkungen vor riskanten Konfigurationsänderungen.

Wichtig ist, dass „99 Prozent“ selbst kein Fehlercode ist. Er zeigt an, wo der Benutzer das Problem bemerkt hat, nicht welche Komponente es verursacht hat. Die zuverlässige Lösung besteht darin, den Zeitstempel des fehlgeschlagenen Uploads mit Hinweisen auf Speicherprobleme, Timeouts, Proxy-Probleme, Sitzungsprobleme oder Sperren auf dem Server abzugleichen.