So beheben Sie den ownCloud-Dateisperrungsfehler „Timeout des Sperrmechanismus“

Wenn ownCloud während der Synchronisierung, des Uploads, des Verschiebens, Umbenennens oder der Chunk-Zusammenstellung einen Timeout bei der Dateisperrung meldet, ist zunächst zu wissen, dass der Fehler in der Regel mit der transaktionalen Dateisperrung zusammenhängt und nicht mit der manuellen Dateisperrung für den Benutzer. Die transaktionale Sperrung ist ein interner Sicherheitsmechanismus, der verhindert, dass zwei Anfragen gleichzeitig dieselbe Datei speichern oder ändern. Sie ist in ownCloud standardmäßig aktiviert und kann die Datenbank oder Redis als Sperr-Backend verwenden.

Die aktuelle ownCloud 11-Dokumentation empfiehlt weiterhin Redis für die transaktionale Dateisperrung, da datenbankbasierte Sperren eine erhebliche Datenbanklast verursachen. In Clusterinstallationen muss jeder Anwendungsknoten dieselbe gemeinsam genutzte Redis-Instanz für die Sperrung verwenden. Dies ist die dauerhafte Lösung, die Sie verstehen sollten, bevor Sie Timeout-Werte ändern oder Sperrdatensätze löschen.

Dieser Leitfaden erläutert das Problem aus der Perspektive eines unerfahrenen Administrators: Was bedeutet die Sperre? Was sollte gesichert werden? Wie lässt sich die fehlerhafte Komponente identifizieren? Wie konfiguriert man Redis? Wie verändern Cluster das Bild? Und welche Abkürzungen können die Situation verschlimmern?

Was der Fehler bedeutet

Wenn ownCloud eine Datei ändert, wird eine Sperre gesetzt, um zu verhindern, dass eine andere Anfrage gleichzeitig eine inkompatible Änderung vornimmt. Die Sperre kann auch ein übergeordnetes Verzeichnis umfassen, sodass dieses nicht umbenannt werden kann, während darin Änderungen vorgenommen werden. Kann die Sperre nicht rechtzeitig gesetzt werden, schlägt der Vorgang mit einem Fehler aufgrund einer gesperrten Ressource oder eines Timeouts fehl, anstatt das Risiko einer beschädigten Datei einzugehen.

Laut der ownCloud 11-Dokumentation zur transaktionalen Dateisperrung verarbeitet dieser Mechanismus auch unterbrochene Uploads, gemeinsam genutzte Dateien, externen Speicher und verschlüsselte Dateien.

Dies unterscheidet sich von der manuellen Dateisperrung , der optionalen WebDAV-basierten Funktion zum Ein- und Auschecken von Dateien, mit der Benutzer Dateien gezielt über die Weboberfläche sperren können. Manuelle Sperren verfügen über konfigurierbare Ablaufzeiten. Das Ändern dieser Werte behebt jedoch kein Problem mit einem überlasteten oder falsch konfigurierten Transaktionssperrsystem.

Bevor Sie beginnen

• Sichern Sie die ownCloud-Datenbank und config/config.php.
• Notieren Sie Ihre ownCloud-Version und den Bereitstellungstyp: traditionelles Paket, Docker Compose oder Multi-Node-Cluster.
• Ermitteln Sie Ihre Datenbank-Engine und prüfen Sie, ob Redis bereits installiert ist.
• Notieren Sie genau den Vorgang, der fehlschlägt, z. B. eine Desktop-Synchronisierung, ein WebDAV-Upload, eine Ordnerumbenennung oder ein Chunked-Upload.
• Notieren Sie, ob das Problem eine Datei, einen Benutzer oder mehrere Benutzer gleichzeitig betrifft.

Ein großflächiger Ausfall, der viele Benutzer betrifft, deutet in der Regel auf eine gemeinsam genutzte Komponente wie das Sperr-Backend, die Datenbank, Redis oder den Speicher hin. Ein reproduzierbarer Fehler bei einer einzelnen Datei kann hingegen auf einen tatsächlich laufenden Vorgang oder eine veraltete Sperre hinweisen, deren Gültigkeit noch nicht abgelaufen ist.

Schritt 1: Prüfen Sie, welcher Verriegelungsmechanismus defekt ist.

Beginnen Sie mit der Überprüfung des ownCloud-Logs, des Webserver-Logs, des PHP-FPM-Logs und des Redis-Dienststatus. Achten Sie auf wiederholte Ausnahmen aufgrund gesperrter Ressourcen, Datenbank-Sperrwartefehler, Redis-Verbindungsfehler oder ein Muster, bei dem derselbe Pfad lange nach Abschluss des ursprünglichen Vorgangs blockiert bleibt.

Nützliche Prüfungen auf einem Linux-Host umfassen:

systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.log

Ein erfolgreicher Redis-Befehl sollte einen Wert zurückgeben PONG. Wenn ownCloud so konfiguriert ist, dass es Redis über einen Socket, einen Container-Hostnamen, ein Passwort oder einen Remote-Host erreicht, testen Sie den Verbindungspfad, den ownCloud tatsächlich verwendet, anstatt anzunehmen, dass ein lokaler redis-cliTest die Anwendungskonnektivität beweist.

Enthält das Protokoll eine Datenbankmeldung ähnlich wie „Zeitüberschreitung beim Sperren“, sollten Sie auch Datenbankkonflikte untersuchen. Das alte Sperr-Backend der Datenbank ist zwar funktionsfähig, aber die ownCloud-Dokumentation warnt ausdrücklich davor, dass es die Datenbank stark belastet.

Schritt 2: Transaktionsbasierte Dateisperrung nach Redis verlagern

Bei einer herkömmlichen ownCloud-Installation konfigurieren Sie Redis als memcache.lockingBackend in der config/config.phpKonfigurationsdatei. Die aktuelle ownCloud-Dokumentation zum Speicher-Caching enthält ein Redis-TCP-Beispiel, das dem folgenden ähnelt:

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => 'localhost',
    'port' => 6379,
    'timeout' => 0,
    'password' => '',
],

Kopieren Sie das leere Passwort nicht einfach in eine Redis-Umgebung, die über das Internet erreichbar ist. Die ownCloud-Dokumentation zum Speichercaching empfiehlt, Redis angemessen zu schützen. Idealerweise sollte Redis nur von vertrauenswürdigen ownCloud-Hosts oder dem internen Containernetzwerk aus erreichbar sein.

In der offiziellen ownCloud-Docker-Konfiguration wird Redis über Umgebungsvariablen aktiviert. Die aktuelle ownCloud-11-Dokumentation zeigt Folgendes:

OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379

Wenn Redis in diesem Bereitstellungsmodell aktiviert ist, konfiguriert ownCloud sowohl den verteilten Cache als auch den Sperrcache automatisch auf Redis. Verwenden Sie die für Ihre Installation dokumentierte, bereitstellungsspezifische Konfiguration, anstatt Docker-Umgebungsvariablen mit manuell gepflegten Einstellungen zu vermischen, config.phpes sei denn, Sie wissen genau, welche Ebene Vorrang hat.

Schritt 3: In einem Cluster sollte jeder Knoten dasselbe Redis verwenden.

Ein Cluster ist eine Bereitstellung mit mehreren ownCloud-Anwendungsservern hinter einem Load Balancer. In dieser Architektur muss eine auf einem Anwendungsknoten erstellte Sperre für alle anderen Knoten sichtbar sein. Knotenspezifische APCu-Caches oder separate knotenspezifische Redis-Instanzen können diesen gemeinsamen Sperrstatus nicht gewährleisten.

Die ownCloud-Richtlinien für geclusterten, gemeinsam genutzten Speicher sind eindeutig: Verwenden Sie eine gemeinsam genutzte Redis-Instanz, die von allen Anwendungsknoten erreichbar ist. Sie warnen davor, sich bei der Sperrung von ownCloud-Anwendungen auf Dateisystem- oder NFS-Sperren zu verlassen.

Prüfen Sie, ob jeder Knoten denselben Redis-Endpunkt und dieselben Anmeldeinformationen verwendet. Ein häufiges Fehlermuster ist, dass ein Knoten weiterhin die Datenbank oder ein lokales Redis nutzt, während die anderen den gemeinsam genutzten Dienst verwenden. Dies führt zu inkonsistentem Sperrverhalten, das sporadisch auftreten kann, da das Ergebnis davon abhängt, welcher Anwendungsknoten die jeweilige Anfrage verarbeitet.

Schritt 4: Überprüfen Sie die Konfiguration und wiederholen Sie den ursprünglichen Vorgang.

Nach der Konfiguration von Redis überprüfen Sie die aktiven ownCloud-Einstellungen mit dem Befehl `ownCloud --config` occ. Je nach Installation kann dieser Befehl als Webserver-Benutzer oder über Docker Compose ausgeführt werden.

sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabled

Der erste Befehl sollte eine Fehlermeldung ausgeben \OC\Memcache\Redis, und die Transaktionsdateisperrung sollte aktiviert bleiben. Deaktivieren Sie die Dateisperrung nicht, um das Problem zu „lösen“. Dadurch wird eine Sicherheitsmaßnahme zur Datenintegrität entfernt, anstatt das Backend zu reparieren.

Führen Sie nun den exakten, fehlgeschlagenen Vorgang erneut aus. Wenn ein Upload auf einem Desktop-Client ein Timeout verursacht hat, wiederholen Sie diesen. Wenn das Verschieben eines Ordners fehlgeschlagen ist, wiederholen Sie den Vorgang. Überwachen Sie während des Tests die ownCloud- und Redis-Protokolle. Ein erfolgreicher Wiederholungsversuch ohne wiederkehrendes Timeout ist ein deutlich aussagekräftigerer Beweis als die Ausführung eines nicht damit zusammenhängenden Wartungsbefehls.

Was ist, wenn die Datei weiterhin als gesperrt angezeigt wird?

Prüfen Sie zunächst, ob die Datei tatsächlich noch von einem anderen Vorgang verwendet wird. Große Uploads, Zugriffe auf externe Speicher, Dateiverschiebungen, Verschlüsselung oder langsame Speicherzugriffe können Sperren berechtigterweise länger als erwartet beanspruchen. Wird die Sperre aufgehoben, während der Vorgang noch aktiv ist, kann dies zu einer Race Condition führen, die die Sperre eigentlich verhindern soll.

Transaktionssperren sind so konzipiert, dass sie nach unterbrochenen Transaktionen freigegeben werden. Ältere ownCloud-Konfigurationsdokumente beschreiben zudem einen Mechanismus zur Festlegung der Gültigkeitsdauer (TTL) von Sperren, sodass alte Sperren automatisch bereinigt werden können. Da die genauen Konfigurationsdetails je nach ownCloud-Version variieren können, überprüfen Sie die entsprechende Option in der Dokumentation Ihrer installierten Version, bevor Sie Änderungen vornehmen. Setzen Sie die TTL nicht extrem kurz, nur um ein Problem mit langsamem Speicher oder der Datenbank zu kaschieren.

Wenn die Metadaten selbst inkonsistent sind, bietet ownCloud Befehle zum Reparieren von Dateien. Die offizielle Dokumentation des Befehls occ empfiehlt, vor einem Reparaturscan die Datenbank zu sichern. Ein Reparaturscan dient der Behebung beschädigter oder inkonsistenter Dateimetadaten; er ist nicht die erste Wahl zur Behebung normaler Sperrkonflikte.

Verwechseln Sie nicht die Transaktionssperrung mit der manuellen Dateisperrung.

Laut der aktuellen ownCloud 11-Dokumentation ist die manuelle Dateisperrung in der Weboberfläche standardmäßig deaktiviert. Ist sie aktiviert, beträgt die Standardsperrdauer 30 Minuten und maximal 24 Stunden. Diese Werte sind im Leitfaden zur manuellen Dateisperrung dokumentiert .

Falls es sich bei Ihrem Problem speziell um eine vom Benutzer erstellte manuelle Sperre handelt, sind Befehle wie die folgenden relevant:

docker compose exec owncloud occ config:app:set files lock_timeout_default --value 1800
docker compose exec owncloud occ config:app:set files lock_timeout_max --value 86400

Wenn Ihr Problem ein interner Timeout beim Synchronisieren oder Speichern einer Datei ist, ist das Ändern dieser manuellen Sperrwerte in der Regel die falsche Lösung.

Häufige Fehler, die Sperrzeitüberschreitungen verschlimmern

Sperrzeilen aus der Datenbank löschen, während ownCloud aktiv ist

Dies kann zu Konflikten mit laufenden Anfragen führen und gültige Sperren aufheben. Außerdem behebt es nur das Symptom, ohne die Datenbank- oder Redis-Konfiguration zu korrigieren, die den Timeout verursacht hat.

Deaktivierung der Transaktionsdateisperrung

Die Transaktionssperre dient dem Schutz von Dateivorgängen vor gleichzeitiger Änderung. Lassen Sie sie aktiviert und reparieren Sie das Backend.

Verwendung von APCu für gemeinsame Sperrung in einem Cluster

APCu ist ein lokaler, knotenbasierter Cache. Er eignet sich für lokales Caching, bietet aber keinen gemeinsamen Sperrstatus für mehrere Anwendungsserver. Verwenden Sie in Clusterumgebungen gemeinsam genutzte Redis-Server für verteilte und sperrende Caches.

Pro Anwendungsknoten wird eine Redis-Instanz ausgeführt.

Dadurch hat jeder Server eine andere Sicht auf die Dateisperren. Alle Knoten benötigen denselben gemeinsamen Redis-Dienst zur Sperrkoordination.

Erhöhung der Sperrwartezeit der Datenbank ohne Behebung von Konflikten

Ein längeres Datenbank-Timeout führt möglicherweise nur zu längeren Wartezeiten für die Benutzer. Die Verlagerung des Transaktionssperrverkehrs zu Redis reduziert die Sperrlast der Datenbank und behebt den architektonischen Engpass.

Die Gültigkeitsdauer von Sperren unrealistisch kurz zu gestalten

Ein langsamer Vorgang auf einem externen Speicher oder ein großer Upload kann unter Umständen Zeit benötigen. Ein vorzeitiges Ablaufen der Sperre kann dazu führen, dass eine andere Anfrage gleichzeitig dieselbe Ressource ändert.

Checkliste zur schnellen Fehlerbehebung

• Bitte prüfen Sie, ob der Fehler auf eine Transaktionssperre und nicht auf eine vom Benutzer erstellte manuelle Sperre zurückzuführen ist.
• Überprüfen Sie die ownCloud-, PHP-, Datenbank- und Redis-Protokolle etwa zum gleichen Zeitpunkt.
• Stellen Sie sicher, dass Redis von der ownCloud-Laufzeitumgebung aus erreichbar ist, nicht nur von Ihrer Shell aus.
• memcache.lockingAuf \OC\Memcache\Redis. eingestellt
• Aktiviert lassen filelocking.enabled.
• In einem Cluster sollten alle Knoten auf dieselbe Redis-Instanz verweisen.
• Wiederholen Sie den ursprünglichen Synchronisierungs-, Upload- oder Verschiebungsvorgang und überwachen Sie dabei die Protokolle.
• Reparaturscans oder Änderungen des Sperrablaufs sollten nur dann durchgeführt werden, wenn die Beweislage auf Metadatenbeschädigung oder veraltete Sperren hinweist.

Fazit

Die zuverlässigste Lösung für Timeout-Fehler bei der Dateisperrung in ownCloud besteht nicht darin, Sperren zu entfernen oder willkürliche Timeout-Werte zu erhöhen. Ermitteln Sie zunächst, ob der Fehler durch Transaktionssperren verursacht wird. Verlagern Sie dann die Sperrlast zu Redis und stellen Sie sicher, dass jeder ownCloud-Knoten dieselbe Redis-Instanz verwendet. Testen Sie die fehlgeschlagene Operation erneut und untersuchen Sie die Datenbank- oder Speicherlatenz, falls die Sperren weiterhin zu lange aktiv bleiben.

Dieser Ansatz entspricht der aktuellen ownCloud-Dokumentation: Die transaktionale Dateisperrung bleibt aktiviert, Redis verwaltet den gemeinsamen Sperrstatus, und die Timeout-Einstellungen für die manuelle Dateisperrung werden als separate Funktion und nicht als universelle Lösung für das Sperr-Timeout-Problem behandelt.