If ownCloud reports a file locking timeout during sync, upload, move, rename, or chunk assembly, the first thing to know is that the error usually involves transactional file locking, not the user-facing Manual File Locking feature. Transactional locking is an internal safety mechanism that prevents two requests from saving or mutating the same file at the same time. It is enabled by default in ownCloud and can use the database or Redis as its locking backend.
Current ownCloud 11 documentation still recommends Redis for transactional file locking because database-backed locks create significant database load. On clustered installations, every application node must use the same shared Redis instance for locking. That is the durable fix to understand before changing timeout values or deleting lock records.
This guide walks through the problem from a beginner administrator's perspective: what the lock means, what to back up, how to confirm the failing component, how to configure Redis, how clusters change the picture, and which shortcuts can make the situation worse.
When ownCloud changes a file, it acquires a lock so another request cannot perform an incompatible change at the same time. The lock can also cover a parent directory so it cannot be renamed while work is happening inside it. If the lock cannot be acquired in time, the operation can fail with a locked-resource or timeout-style error rather than risking a corrupted file.
According to the ownCloud 11 transactional file locking documentation, this mechanism also handles interrupted uploads, shared files, external storage, and encrypted files.
This is different from Manual File Locking, the optional WebDAV-based check-in/check-out feature that lets a user deliberately lock a file in the web interface. Manual locks have configurable user-facing expiration values. Changing those values does not fix a transactional lock backend that is overloaded or incorrectly configured.
config/config.php.A broad outage affecting many users usually points to a shared component such as the lock backend, database, Redis, or storage. A repeatable error on one file may instead involve a genuinely active operation or a stale lock that has not yet expired.
Start with the ownCloud log, web server log, PHP-FPM log, and Redis service status. You are looking for repeated locked-resource exceptions, database lock-wait errors, Redis connection failures, or a pattern where the same path remains blocked long after the original operation ended.
Useful checks on a Linux host include:
systemctl status redis-server
redis-cli PING
ps -ef | grep php
tail -n 200 /path/to/owncloud/data/owncloud.logA healthy Redis command should return PONG. If ownCloud is configured to reach Redis through a socket, container hostname, password, or remote host, test the same connection path ownCloud actually uses rather than assuming that a local redis-cli test proves application connectivity.
If the log contains a database message similar to “lock wait timeout exceeded,” investigate database contention as well. The old database locking backend is functional, but ownCloud's documentation explicitly warns that it places significant load on the database.
For a traditional ownCloud installation, configure Redis as the memcache.locking backend in config/config.php. The current ownCloud memory caching documentation provides a Redis TCP example similar to this:
'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
'host' => 'localhost',
'port' => 6379,
'timeout' => 0,
'password' => '',
],
Do not copy the empty password literally into an Internet-exposed Redis setup. The ownCloud memory caching documentation recommends protecting Redis appropriately. Ideally, Redis should be reachable only from trusted ownCloud hosts or the internal container network.
In the official ownCloud Docker configuration, Redis is enabled with environment variables. Current ownCloud 11 documentation shows:
OWNCLOUD_REDIS_ENABLED=true
OWNCLOUD_REDIS_HOST=redis
OWNCLOUD_REDIS_PORT=6379When Redis is enabled in that deployment model, ownCloud sets both the distributed cache and locking cache to Redis automatically. Use the deployment-specific configuration documented for your installation instead of mixing Docker environment variables with a manually maintained config.php unless you understand which layer wins.
A cluster is a deployment with multiple ownCloud application servers behind a load balancer. In this design, a lock created on one application node must be visible to every other node. Per-node APCu caches or separate per-node Redis instances cannot provide that shared lock state.
Przewodnik po klastrowanym, współdzielonym magazynie danych ownCloud jasno określa: należy używać jednej współdzielonej instancji Redis, do której dostęp mają wszystkie węzły aplikacji. Ostrzega on przed poleganiem na blokadach systemu plików lub NFS do blokowania aplikacji ownCloud.
Sprawdź każdy węzeł pod kątem tego samego punktu końcowego Redis i poświadczeń. Częstym schematem awarii jest to, że jeden węzeł nadal korzysta z bazy danych lub lokalnego Redis, podczas gdy pozostałe korzystają z usługi współdzielonej. Powoduje to niespójne działanie blokady, które może sprawiać wrażenie przerywanego, ponieważ wynik zależy od tego, który węzeł aplikacji obsługuje każde żądanie.
Po skonfigurowaniu Redis sprawdź aktywne ustawienia ownCloud za pomocą occ. W zależności od instalacji, polecenie może zostać wywołane jako użytkownik serwera WWW lub przez Docker Compose.
sudo -u www-data php occ config:system:get memcache.locking
sudo -u www-data php occ config:system:get filelocking.enabledPierwsze polecenie powinno zgłosić błąd \OC\Memcache\Redis, a blokowanie plików transakcyjnych powinno pozostać włączone. Nie „rozwiązuj” problemu poprzez wyłączenie blokowania plików. To usuwa zabezpieczenie integralności danych zamiast naprawiać zaplecze.
Teraz spróbuj ponownie wykonać tę samą operację, która się nie powiodła. Jeśli przekroczono limit czasu przesyłania danych przez klienta stacjonarnego, powtórz przesyłanie. Jeśli przenoszenie folderu się nie powiodło, powtórz przenoszenie. Obserwuj logi ownCloud i Redis podczas testu. Pomyślna ponowna próba bez powtarzającego się przekroczenia limitu czasu blokady jest znacznie silniejszym dowodem niż uruchomienie niezwiązanego z tym polecenia konserwacyjnego.
Najpierw sprawdź, czy inna operacja rzeczywiście nadal korzysta z pliku. Duże operacje przesyłania, wywołania pamięci zewnętrznej, przenoszenie plików, szyfrowanie lub powolne działanie pamięci masowej mogą legalnie utrzymywać blokady dłużej niż oczekiwano. Zniesienie blokady, gdy operacja jest nadal aktywna, może spowodować wyścig, któremu blokada miała zapobiegać.
Blokady transakcyjne są zaprojektowane tak, aby były zwalniane po przerwaniu transakcji. Starsze odniesienia do konfiguracji ownCloud dokumentują również mechanizm czasu życia blokady, dzięki czemu stare blokady mogą być automatycznie usuwane. Ponieważ dokładne szczegóły konfiguracji mogą się różnić w zależności od wersji ownCloud, przed zmianą opcji należy sprawdzić w dokumentacji, czy odpowiada ona zainstalowanej wersji. Nie należy ustawiać bardzo krótkiego czasu życia (TTL) tylko po to, aby ukryć problem z wolnym działaniem pamięci masowej lub bazy danych.
Jeśli same metadane są niespójne, ownCloud udostępnia polecenia skanowania plików zorientowane na naprawę. Oficjalna dokumentacja polecenia occ zaleca utworzenie kopii zapasowej bazy danych przed skanowaniem w celu naprawy. Skanowanie w celu naprawy służy do wykrywania uszkodzonych lub niespójnych metadanych plików; nie jest to pierwsza linijka rozwiązania problemu z normalnym blokowaniem.
| Funkcja | Zamiar | Typowa kontrola |
|---|---|---|
| Blokowanie plików transakcyjnych | Chroni równoczesne operacje na plikach i zapisuje | memcache.locking, zwykle Redis |
| Ręczne blokowanie plików | Użytkownik celowo wyewidencjonowuje/blokuje współdzielony plik | Ustawienia limitu czasu blokady WebDAV i wyłącznika blokady |
Aktualna dokumentacja ownCloud 11 informuje, że ręczne blokowanie plików w interfejsie internetowym jest domyślnie wyłączone. Po włączeniu, blokada interfejsu internetowego trwa domyślnie 30 minut, a maksymalny czas to 24 godziny. Wartości te są opisane w przewodniku ręcznego blokowania plików .
Jeśli Twój problem dotyczy blokady ręcznej utworzonej przez użytkownika, wówczas odpowiednie będą następujące polecenia:
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 86400Jeśli problemem jest wewnętrzne przekroczenie limitu czasu podczas synchronizacji lub zapisywania pliku, zmiana tych wartości blokady ręcznej zazwyczaj nie jest właściwym rozwiązaniem.
Może to kolidować z aktywnymi żądaniami i usuwać prawidłowe blokady. Rozwiązuje to również problem bez naprawiania bazy danych lub konfiguracji Redis, która spowodowała przekroczenie limitu czasu.
Blokada transakcyjna służy ochronie operacji na plikach przed jednoczesną modyfikacją. Pozostaw ją włączoną i napraw zaplecze.
APCu to lokalna pamięć podręczna dla każdego węzła. Nadaje się do lokalnego buforowania, ale nie zapewnia jednego współdzielonego stanu blokady dla wielu serwerów aplikacji. Użyj współdzielonego Redis do rozproszonych i blokujących pamięci podręcznych we wdrożeniach klastrowych.
To sprawia, że każdy serwer ma inny widok blokad plików. Wszystkie węzły potrzebują tej samej współdzielonej usługi Redis do koordynacji blokad.
Dłuższy limit czasu bazy danych może jedynie wydłużyć oczekiwanie użytkowników. Przeniesienie ruchu związanego z blokadą transakcyjną do Redis zmniejsza obciążenie bazy danych związane z blokadą i eliminuje wąskie gardło architektoniczne.
Powolna operacja na zewnętrznym nośniku danych lub przesyłanie dużych ilości danych może wymagać czasu. Przedwczesne wygaśnięcie blokady może umożliwić kolejnemu żądaniu jednoczesną modyfikację tego samego zasobu.
memcache.lockingna \OC\Memcache\Redis.filelocking.enabledwłączone.Najpewniejszym sposobem rozwiązania błędów przekroczenia limitu czasu blokowania plików w ownCloud nie jest usuwanie blokad ani zwiększanie dowolnych wartości limitu czasu. Zacznij od ustalenia, czy błąd wynika z blokowania transakcji, a następnie przenieś obciążenie związane z blokadą do Redis i upewnij się, że każdy węzeł ownCloud widzi tę samą instancję Redis. Przetestuj ponownie tę samą operację, która się nie powiodła, i sprawdź opóźnienie bazy danych lub pamięci masowej, jeśli blokady nadal pozostają aktywne zbyt długo.
To podejście jest zgodne z aktualną dokumentacją ownCloud: blokowanie plików transakcyjnych pozostaje włączone, Redis obsługuje współdzielony stan blokady, a ustawienia limitu czasu ręcznego blokowania plików są traktowane jako osobna funkcja, a nie jako uniwersalne rozwiązanie problemu z limitem czasu blokady.
Porównaj 10 narzędzi do pingowania, które umożliwiają szybkie wykrywanie sieci LAN, skanowanie międzyplatformowe i zarządzanie adresami IP. Dowiedz się, co narzędzie pingujące może Ci powiedzieć, a czego nie.
Porównaj sześć narzędzi do zarządzania siecią służących do monitorowania wydajności, obejmujących zasięg SNMP, mapowanie, alerty, modele wdrażania i kompromisy kosztów.
Porównaj siedem darmowych i otwartych monitorów pingów — od kompletnych pakietów sieciowych po ukierunkowane sondy opóźnień — i wybierz odpowiedni monitor pod kątem dostępności, utraty pakietów i historii.
Dowiedz się, co oznacza QoS w sieciach, w jaki sposób oznaczenia DSCP i kolejki ruchu nadają priorytet aplikacjom głosowym, wideo i biznesowym oraz czego QoS nie jest w stanie naprawić.
Porównaj niezawodne oprogramowanie serwera SFTP dla systemów Windows i Linux, w tym OpenSSH, Bitvise, SolarWinds i SFTPGo. Znajdź rozwiązanie odpowiednie dla swoich potrzeb w zakresie bezpieczeństwa i transferu plików.
Porównaj siedem narzędzi do zarządzania adresami IP służących do wykrywania podsieci, koordynacji DNS i DHCP, inwentaryzacji sieci i otwartego oprogramowania IPAM.
Porównaj sześć narzędzi do monitorowania systemu Windows Server pod kątem zbierania danych systemu Windows, widoczności aplikacji, modelu wdrażania i licencjonowania, aby znaleźć odpowiednie rozwiązanie.
Porównaj narzędzia do skanowania sieciowego umożliwiające szybkie wykrywanie urządzeń, skanowanie adresów IP na wielu platformach oraz zarządzanie IPAM w przedsiębiorstwie. Znajdziesz tu wskazówki dotyczące dopasowania każdej opcji do swojej sieci.
Zbuduj praktyczny monitoring sieci z przejrzystym zakresem urządzeń, przydatnymi wskaźnikami wydajności, przydatnymi alertami oraz porównaniem SolarWinds NPM, PRTG i OpManager.
Użyj opcji --traceroute programu Nmap, aby mapować przeskoki do autoryzowanego hosta, zrozumieć dane wyjściowe dotyczące przeskoków i czasu RTT oraz rozwiązywać problemy z brakującymi odpowiedziami bez nadmiernego skanowania.
