Nextcloud: ошибки при синхронизации — причины и решение

MAATRIX

Клиент синхронизации мигает красным: файлы не выгружаются, висят конфликты, всплывает file is locked или обрыв соединения. Nextcloud ошибки при синхронизации портят весь смысл облака — данные перестают быть актуальными на всех устройствах. Причин несколько, и каждая имеет чёткое решение: залипшие блокировки, таймауты веб-сервера, лимиты на размер, конфликты имён. Разберём их по симптомам и наведём порядок в синхронизации.

Как понять, где именно проблема

Синхронизация — это цепочка: клиент, сеть, веб-сервер, PHP, база и хранилище. Ошибка может возникнуть на любом звене, поэтому сначала локализуйте её. Клиент Nextcloud ведёт лог, а сервер пишет свой — сопоставление двух логов почти всегда указывает на причину.

sudo -u www-data php occ log:tail
tail -f /var/www/nextcloud/data/nextcloud.log

На клиенте откройте журнал синхронизации (в десктопном приложении — «Общие» → журнал) и посмотрите точный текст ошибки для проблемного файла. Разные формулировки ведут к разным причинам: locked — блокировки, 504/timeout — веб-сервер, 413 — лимит размера, conflict — одновременное изменение. Определив тип, переходите к нужному разделу. Не пытайтесь чинить всё сразу — почти всегда за симптомами стоит одна конкретная неисправность.

Отдельно обратите внимание, ошибка касается всех файлов или только некоторых. Если не синхронизируется вообще ничего — проблема системная: недоступен сервер, кончилось место, сломан веб-сервер или PHP. Если же спотыкаются отдельные файлы, а остальные проходят — дело в самих этих файлах: их размер, имя, блокировка или конфликт. Это простое наблюдение сразу делит поле поиска надвое и избавляет от бессмысленного перебора глобальных настроек, когда виноват один-единственный большой файл или файл с запрещённым символом в имени.

Ошибка «file is locked»

Самая частая жалоба: файлы не синхронизируются, потому что помечены как заблокированные (Файл заблокирован / file is currently locked). Nextcloud использует блокировки, чтобы два процесса не изменили файл одновременно. Проблема в том, что при сбое (обрыв, падение PHP) блокировка может «залипнуть» и не сняться, навсегда заблокировав файл.

Корневое решение — перевести блокировки на Redis, если этого ещё не сделано. Блокировки в базе медленны и склонны залипать; Redis снимает проблему.

'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [ 'host' => '/var/run/redis/redis-server.sock', 'port' => 0 ],

Уже залипшие блокировки снимите вручную командой:

sudo -u www-data php occ files:scan --all
sudo -u www-data php occ maintenance:repair

Если блокировки хранились в базе, можно очистить таблицу oc_file_locks напрямую (только при остановленной активности). После перехода на Redis-блокировки и очистки залипших записей ошибка file is locked перестаёт возникать. Это же ускоряет синхронизацию в целом.

Таймауты и обрывы при загрузке

Файлы среднего и большого размера обрываются на середине, в логе 504 Gateway Timeout или Connection reset. Причина — веб-сервер или PHP разрывают долгий запрос, не дождавшись завершения загрузки. Нужно поднять таймауты и лимиты по всей цепочке.

В PHP (php.ini):

max_execution_time = 3600
max_input_time = 3600
memory_limit = 512M

В nginx для location Nextcloud:

client_max_body_size 10G;
proxy_read_timeout 3600;
fastcgi_read_timeout 3600;

Ключевой момент — согласованность: если хоть одно звено (nginx, PHP-FPM, PHP) обрывает раньше других, загрузка падает именно на нём. Поднимайте лимиты везде одинаково. Для очень больших файлов Nextcloud использует чанковую загрузку (дробит файл на части) — убедитесь, что она включена и что каждый чанк укладывается в лимиты. После правок перезапустите PHP-FPM и nginx.

Ошибка 413 и лимиты размера

Если синхронизация больших файлов сразу отбивается с 413 Request Entity Too Large, сервер отказывается принимать файл из-за лимита на размер тела запроса. Это отдельная от таймаутов проблема — тут файл даже не начинает грузиться. Проверьте и поднимите лимиты загрузки.

sudo -u www-data php occ config:system:set max_chunk_size --value 10485760

В PHP:

upload_max_filesize = 10G
post_max_size = 10G

И обязательно client_max_body_size в nginx (см. выше) — именно nginx чаще всего выдаёт 413, если этот параметр мал или не задан. Согласуйте все три места: PHP upload_max_filesize, PHP post_max_size и nginx client_max_body_size. Наименьшее из значений и станет фактическим потолком. После настройки большие файлы начнут проходить целиком.

Конфликты синхронизации

Клиент создаёт файлы вида имя (conflicted copy) — это конфликты: файл изменили в двух местах одновременно, и Nextcloud не знает, какую версию считать верной, поэтому сохраняет обе. Это не поломка, а защита от потери данных, но частые конфликты раздражают и засоряют папки.

Причины частых конфликтов: рассинхрон времени между устройствами (настройте NTP везде), одновременное редактирование одного файла на разных устройствах, синхронизация файлов, которые постоянно меняются в фоне (базы, кэши приложений). Решения: держите время на сервере и клиентах синхронным, исключите из синхронизации служебные и постоянно меняющиеся файлы, а для совместной работы над документами используйте не файловую синхронизацию, а онлайн-редактор (Nextcloud Office/Collabora), где правки сливаются на лету. Разобравшись с исходными версиями, удалите лишние conflicted-copy вручную.

Проблемы на стороне клиента и хранилища

Иногда сервер в порядке, а синхронизация всё равно сбоит — виноват клиент или рассинхрон файлового индекса. Если клиент показывает файлы, которых нет на сервере (или наоборот), пересканируйте хранилище — Nextcloud перечитает реальное состояние файлов на диске.

sudo -u www-data php occ files:scan --all
sudo -u www-data php occ files:cleanup

files:scan синхронизирует индекс базы с тем, что реально лежит в data, — это лечит ситуации, когда файлы клали в хранилище в обход Nextcloud или после восстановления из бэкапа. На стороне клиента помогает пересоздание аккаунта в приложении (без удаления файлов) или проверка, что нет запрещённых символов в именах и слишком длинных путей — Windows-клиенты чувствительны к длине пути. Также убедитесь, что на сервере хватает места: заполненное хранилище тихо ломает выгрузку. Регулярный files:scan по расписанию держит индекс в согласии с диском и предотвращает большинство странных сбоев.

Частые вопросы