Beheben Sie das Problem mit der leeren Seite/dem weißen Bildschirm in ownCloud: Wählen Sie den richtigen Wiederherstellungsweg

Entscheiden Sie zunächst, welche Art von leerer Seite Sie eigentlich haben.

Ein „weißer Bildschirm des Todes“ bei ownCloud ist ein Symptom, keine Diagnose. Die beste Lösung hängt davon ab, ob der Browser einen Serverfehler erhalten hat, gültiges HTML empfangen, aber JavaScript oder CSS nicht laden konnte, oder ob ein Reverse-Proxy verwendet wurde, der ownCloud gar nicht erreichen konnte.

Diese Unterscheidung ist wichtig, da die jeweiligen Vor- und Nachteile sehr unterschiedlich sind. Das Deaktivieren einer Drittanbieter-Anwendung birgt ein relativ geringes Risiko, wenn eine PHP-Ausnahme diese Anwendung nennt. Die Änderung der Dateibesitzrechte für die gesamte Installation ist deutlich einschneidender und sollte nicht die erste Reaktion auf einen JavaScript-Fehler sein. Ebenso kann ein Neustart aller Dienste ein Problem zwar kurzzeitig kaschieren, ohne Aufschluss darüber zu geben, ob es von PHP, einem Proxy, einem Upgrade oder einer Anwendung verursacht wurde.

Dieser Leitfaden behandelt ownCloud Classic. Laut der aktuellen ownCloud Classic 11-Dokumentation wird Version 11 als Docker-basierte Bereitstellung unterstützt, wobei Betriebssystem, PHP-Laufzeitumgebung, Datenbank und Apache in den von ownCloud bereitgestellten Containern enthalten sind. Ältere 10.x-Installationen verwenden möglicherweise noch einen herkömmlichen Webserver und PHP-FPM. Verwenden Sie den Befehlszweig, der Ihrer Bereitstellung entspricht. Die Systemvoraussetzungen für ownCloud Classic 11 finden Sie hier .

1. Wird beim Empfang einer leeren Seite der HTTP-Fehlercode 500 zurückgegeben, oder schlägt der Browser nach dem HTTP-Fehlercode 200 fehl?

Öffnen Sie die Entwicklertools Ihres Browsers und überprüfen Sie die Registerkarten „Netzwerk“ und „Konsole“ . Testen Sie den Endpunkt außerdem über ein Terminal:

curl -I https://cloud.example.com/
curl -sS -o /dev/null -w '%{http_code}\n' https://cloud.example.com/

Bildunterschrift: Eine serverseitige 500-Antwort deutet eher auf ownCloud, PHP, die Datenbank oder den Web-Stack hin als auf ein einfaches Browser-Rendering-Problem.

Wenn das Hauptdokument den Statuscode 500 oder 502/503 zurückgibt , sollten Sie Server- und Proxy-Protokolle priorisieren. Gibt das Hauptdokument den Statuscode 200 zurück , JavaScript-Bundles schlagen jedoch mit den Statuscodes 404, 403 oder Skriptausnahmen fehl, sollten Sie Asset-Pfade, Reverse-Proxy-Rewriting, Themes, Cache oder Anwendungskompatibilität priorisieren. Ist nur ein Browser betroffen, testen Sie ein privates Fenster und einen anderen unterstützten Browser, bevor Sie den Server ändern.

2. Trat das Problem nach einem ownCloud- oder PHP-Upgrade auf?

Dies ist eine der wichtigsten Fragen, da sie den Fehlerbereich sofort eingrenzen kann. Laut den aktuellen Versionshinweisen von ownCloud wurde die minimale PHP-Version für ownCloud Classic 11 auf PHP 8.3 angehoben, und ownCloud Classic 11 ist ausschließlich mit Docker kompatibel. Für ältere ownCloud-10.x-Installationen gelten andere PHP-Kompatibilitätsregeln. Daher sollten Sie keine PHP-Empfehlungen aus anderen Hauptversionen übernehmen.

Bei einer herkömmlichen ownCloud 10.x-Installation führen Sie den Befehl im ownCloud-Verzeichnis aus:

sudo -u www-data ./occ status
php -v

Für ownCloud Classic 11 führen Sie OCC über die Compose-Bereitstellung aus:

docker compose exec owncloud occ status
docker compose exec owncloud php -v

Bildunterschrift: Die Überprüfung der installierten ownCloud- und PHP-Versionen ist besonders wichtig, wenn unmittelbar nach einem Upgrade ein weißer Bildschirm erscheint.

Vergleichen Sie das Ergebnis mit den Versionshinweisen Ihrer aktuellen Version. Die offiziellen ownCloud-Versionshinweise sind die korrekte Quelle für die aktuellen Mindestversionen und Änderungen, die zu Kompatibilitätsproblemen führen können. Ein Downgrade ist keine sichere Standardlösung: Die ownCloud-Dokumentation warnt davor, dass Downgrades nicht unterstützt werden, da sie Daten beschädigen können.

3. Welches Protokoll liefert den ersten konkreten Fehler?

Protokolle sind in der Regel hilfreicher als Konfigurationsänderungen durch Ausprobieren. Das ownCloud-Administrationshandbuch empfiehlt die Verwendung des ownCloud-Protokolls zur Fehlerdiagnose; standardmäßig wird das Protokoll im konfigurierten Datenverzeichnis gespeichert, sofern kein anderes Verzeichnis logfilefestgelegt ist.

Beispiele für eine herkömmliche Installation sind:

tail -n 100 /path/to/owncloud/data/owncloud.log
journalctl -u php-fpm --since "15 minutes ago"
journalctl -u apache2 --since "15 minutes ago"
journalctl -u nginx --since "15 minutes ago"

Unter ownCloud Classic 11 sollten Sie stattdessen die Compose-Dienste überprüfen:

docker compose logs --tail=200 owncloud
docker compose ps

Bildunterschrift: Ein schwerwiegender PHP-Fehler oder ein Stacktrace, der eine Anwendung oder Klasse benennt, bietet ein wesentlich sichereres Ziel für die Fehlersuche als das Ändern von nicht damit zusammenhängenden Servereinstellungen.

Suchen Sie nach der ersten schwerwiegenden Ausnahme im Zusammenhang mit der fehlgeschlagenen Anfrage, nicht nur nach der letzten Fehlerkette. Häufige Ursachen sind eine fehlende PHP-Klasse, eine inkompatible Anwendung, ein Datenbankverbindungsfehler, eine nicht lesbare Konfiguration, fehlende Code-Dateien oder eine Ausnahme während eines unvollständigen Upgrades.

Die Protokollierungsdokumentation von ownCloud besagt, dass die DEBUG-Protokollierung zwar bei der Diagnose hilfreich sein kann, aber eine umfangreiche Ausgabe erzeugt und die Leistung beeinträchtigen kann. Wenn Sie die Protokollierungsstufe vorübergehend erhöhen, sollten Sie sie nach der Datenerfassung wieder auf einen weniger ausführlichen Wert zurücksetzen. Siehe ownCloud-Protokollierungskonfiguration .

4. Sollte man eine Drittanbieter-App deaktivieren?

Wählen Sie diesen Pfad, wenn die Fehlermeldung eine Nicht-Kern-App benennt, wenn nach der Installation oder Aktualisierung einer App eine leere Seite angezeigt wird oder wenn der Fehler während eines ownCloud-Upgrades auftritt. Die ownCloud-Anleitung zur Fehlerbehebung empfiehlt ausdrücklich, Drittanbieter-Apps zur Fehlerbehebung und vor Upgrades zu deaktivieren.

Apps zuerst auflisten. Auf ownCloud 10.x:

sudo -u www-data ./occ app:list
sudo -u www-data ./occ app:disable APP_ID

Auf ownCloud 11:

docker compose exec owncloud occ app:list
docker compose exec owncloud occ app:disable APP_ID

Bildunterschrift: Das Deaktivieren nur der in den Protokollen identifizierten Anwendung ist weniger störend als das Deaktivieren vieler Komponenten oder das Ändern des gesamten Web-Stacks.

Der Kompromiss besteht in der Funktionalität: Nutzer verlieren die betreffende App, bis sie aktualisiert oder wieder aktiviert wird. Dies ist in der Regel besser, als die ownCloud-Kerndienste zu deaktivieren. Die OCC-Dokumentation weist außerdem darauf hin, dass einige Kern-Apps nicht deaktiviert werden können, darunter DAV, FederatedFileSharing, Files und Files_External. Lesen Sie die offiziellen allgemeinen Hinweise zur Fehlerbehebung und die OCC-Befehlsreferenz .

5. Wann lohnt es sich, Berechtigungen zu korrigieren?

Berechtigungen sind ein starker Verdachtsfall, wenn das Protokoll Einträge enthält Permission denied, eine kürzlich erfolgte Bereitstellung Anwendungs-/Konfigurationsdateien mit dem falschen Benutzer kopiert hat oder ein Upgrade Dateien mit falschen Besitzrechten ersetzt hat. Sie sind ein schwacher Verdachtsfall, wenn der einzige Hinweis ein JavaScript-Fehler im Browser ist.

Versetzen Sie das System vor störenden Reparaturarbeiten in den Wartungsmodus. Für ownCloud 11:

docker compose exec owncloud occ maintenance:mode --on

Für eine herkömmliche 10.x-Bereitstellung:

sudo -u www-data ./occ maintenance:mode --on

Bildunterschrift: Der Wartungsmodus reduziert die Benutzeraktivität, während Sie Eigentums- oder Dateiberechtigungsfehler untersuchen, die bereits durch Protokolleinträge belegt sind.

Führen Sie keine pauschalen, rekursiven chmod 777oder Berechtigungskopien aus einer nicht verwandten Version aus. Das aktuelle ownCloud 11-Handbuch dokumentiert die spezifischen Besitzverhältnisse und Zugriffsrechte für manuell hinzugefügte Dateien in Docker-eingebundenen appsVerzeichnissen config: Besitzverhältnisse www-data:root, Anwendungsdateien 0644, Anwendungsverzeichnisse 0751und hinzugefügte Konfigurationsdateien 0644. Es dokumentiert auch 0640die manuell geänderten .htaccessEinstellungen .user.ini. Verwenden Sie die ownCloud 11-Dokumentation zum manuellen Upgrade als versionsspezifische Referenz.

6. Sollten Sie PHP-Module, OPcache oder Speichereinstellungen ändern?

Nur wenn Protokolle oder Kompatibilitätsprüfungen darauf hinweisen. Dieser Ansatz hat weitreichendere Folgen als die Deaktivierung einer einzelnen fehlerhaften Anwendung. Eine fehlende, erforderliche PHP-Erweiterung kann die Ausführung von Code verhindern, während eine fehlerhafte PHP-Konfiguration alle PHP-Anwendungen auf dem Host beeinträchtigen kann.

Bei einem älteren, vom Host verwalteten PHP-Stack sollte man prüfen, was die Web-Laufzeitumgebung tatsächlich lädt:

php -m
php --ini
php -r 'phpinfo();' | grep opcache.enable

Bildunterschrift: PHP-Modul- und OPcache-Prüfungen sind nützlich, wenn Serverprotokolle fehlende Erweiterungen oder Laufzeitinkompatibilitäten melden, sie sollten aber nicht ohne Beweise als erste Änderung vorgenommen werden.

Bei ownCloud 11 verwaltet das offizielle Image die PHP-Laufzeitumgebung. Daher ist das Ändern der PHP-Pakete auf dem Host in der Regel der falsche Ansatz. ownCloud dokumentiert, dass OPcache im Docker-Image standardmäßig aktiviert ist. Weitere Informationen finden Sie in der ownCloud-Dokumentation zum Speicher-Caching .

Wenn Sie nach dem manuellen Ersetzen von PHP-Dateien auf einer älteren Installation einen veralteten OPcache vermuten, kann ein Neustart von PHP-FPM oder des entsprechenden Web-/PHP-Dienstes den prozesslokalen Opcode-Cache leeren. Dies führt zu einer kurzen Unterbrechung und beeinträchtigt anschließend die Leistung des Caches. Führen Sie diesen Schritt erst nach der Korrektur der zugrundeliegenden Dateien durch, nicht anstelle der Fehlersuche.

7. Wurde ein Upgrade unterbrochen oder sind die Kerndateien inkonsistent?

Wenn während oder unmittelbar nach einem Upgrade eine weiße Seite erscheint, überprüfen Sie zunächst den Upgrade-Status. Die Upgrade-Dokumentation von ownCloud empfiehlt, für den Upgrade- und Reparaturvorgang OCC zu verwenden, anstatt die Datenbank manuell zu bearbeiten.

Für ownCloud 11:

docker compose exec owncloud occ status
docker compose exec owncloud occ upgrade
docker compose exec owncloud occ maintenance:repair
docker compose exec owncloud occ integrity:check-core

Für ownCloud 10.x verwenden Sie die entsprechenden OCC-Befehle unter dem Webserver-Benutzer:

sudo -u www-data ./occ status
sudo -u www-data ./occ maintenance:repair
sudo -u www-data ./occ integrity:check-core

Bildunterschrift: Die OCC-Reparatur eignet sich für ein unterbrochenes oder inkonsistentes Upgrade, während Integritätsprüfungen geänderte oder fehlende signierte Kerndateien identifizieren können.

Die Ergebnisse der Codeintegritätsprüfung müssen interpretiert werden. ownCloud dokumentiert INVALID_HASHdies FILE_MISSINGals EXTRA_FILEunterschiedliche Bedingungen. Bearbeiten Sie die Dokumentation nicht, signature.jsonum Warnungen zu entfernen. Die aktuelle ownCloud 11-Dokumentation schreibt außerdem die Signierung von Drittanbieter-Apps für Installation, Updates und Aktivierung vor. Weitere Informationen finden Sie in der ownCloud-Dokumentation zur Codesignierung .

8. Wie sollten Sie die Behebung des Problems überprüfen?

Eine erfolgreiche Wiederherstellung bedeutet nicht einfach nur, dass die Seite nicht mehr weiß ist. Überprüfen Sie den gesamten Anfragepfad:

• Die ownCloud-Hauptseite gibt den erwarteten HTTP-Statuscode zurück, anstatt 500/502/503.
• Die Entwicklertools des Browsers zeigen keinen wiederkehrenden schwerwiegenden JavaScript-Fehler oder ein fehlendes Core-Bundle an.
• Im ownCloud-Protokoll wird nicht sofort eine neue schwerwiegende Ausnahme für dieselbe Anfrage protokolliert.
• occ statusmeldet eine installierte Instanz und keine unerwartete Aktualisierungsanforderung.
• Der Wartungsmodus wird nach Abschluss der Wartungsarbeiten deaktiviert.
• Ein Testbenutzer kann sich anmelden und die Seite „Dateien“ öffnen.

Für ownCloud 11:

docker compose exec owncloud occ maintenance:mode --off
docker compose exec owncloud occ status
curl -I https://cloud.example.com/

Bildunterschrift: Die Wiederherstellung sollte auf beiden Ebenen bestätigt werden: Die ownCloud-Oberfläche wird geladen, und serverseitige Status- und HTTP-Prüfungen bleiben in Ordnung.

Welche Lösung bietet das beste Risiko-Nutzen-Verhältnis?

Was Sie nicht tun sollten, wenn ownCloud einen weißen Bildschirm anzeigt

• Aktivieren Sie PHP nicht display_errorsauf einer öffentlichen Produktionsseite, nur um Stacktraces im Browser anzuzeigen; verwenden Sie stattdessen Serverprotokolle.
• Setzen Sie nicht rekursiv die Berechtigungen für weltweites Schreiben auf den gesamten ownCloud-Baum.
• Führen Sie kein Downgrade von ownCloud durch, um schnell auf eine ältere Version zurückzugreifen, es sei denn, Sie stellen ein unterstütztes Backup in einer kompatiblen Umgebung wieder her.
• Löschen Sie nicht willkürlich das Datenverzeichnis, die Anwendungsdaten, die Datenbanktabellen oder die Cache-Verzeichnisse.
• Deaktivieren Sie nicht alle Apps gleichzeitig, wenn eine einzelne App isoliert werden kann.
• Bearbeiten Sie keine signierten Kerndateien, es sei denn, signature.jsondies dient lediglich der Unterdrückung von Integritätsfehlern.

Wann sollte man die Maßnahmen verschärfen, anstatt weiter zu experimentieren?

Nehmen Sie keine Änderungen mehr vor, wenn die Protokolle auf Datenbankbeschädigung, Probleme mit dem Verschlüsselungsschlüssel, wiederholte Integritätsfehler nach einer vollständigen Wiederherstellung oder einen Upgrade-Status hinweisen, der nicht mit dem dokumentierten OCC-Workflow abgeschlossen werden kann. Eskalieren Sie das Problem außerdem, wenn die leere Seite einen Produktionscluster betrifft und Sie einen einzelnen Knoten nicht isolieren können, ohne die Datenkonsistenz zu gefährden.

Bevor Sie ein Support-Ticket eröffnen, empfiehlt ownCloud, einen Konfigurationsbericht und die relevanten Protokolle zu erfassen. Für ownCloud 10.x lautet der dokumentierte Befehl:

sudo -u www-data ./occ configreport:generate > config_report.txt

Verwenden Sie die entsprechende OCC-Ausführungsmethode für Ihre Bereitstellung und prüfen Sie die Ausgabe auf Geheimnisse, bevor Sie sie außerhalb Ihrer Organisation weitergeben. Der ownCloud-Protokoll- und Konfigurationsleitfaden erläutert, welche Informationen Support-Mitarbeiter üblicherweise benötigen.

Offizielle Referenzen

• ownCloud Classic 11 Allgemeine Fehlerbehebung
• ownCloud Classic 11 Systemvoraussetzungen
• ownCloud Server – Versionshinweise
• ownCloud Classic 11 – Manuelles Upgrade
• ownCloud-Protokollierungskonfiguration