Облако Seafile на сервере: частые ошибки и решения

MAATRIX

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

Seahub не запускается или падает сразу после старта

Самый частый сценарий: вы выполняете ./seahub.sh start, команда отрабатывает без явной ошибки, но веб-панель недоступна, а systemctl status seahub показывает, что процесс умер. Первым делом всегда смотрите логи — Seafile довольно подробно пишет причину.

tail -n 50 /opt/seafile/logs/seahub.log
tail -n 50 /opt/seafile/logs/seafile.log

Три типичные причины. Первая — не установлены Python-зависимости: в свежих сборках Seahub требует конкретные версии django, pillow, mysqlclient и других пакетов, и при их отсутствии падает с ImportError. Поставьте недостающее через pip именно в то окружение, из которого запускается сервер. Вторая — не запущен сам движок seafile: Seahub это только веб-морда, и без работающего seaf-server она стартовать не будет, поэтому порядок запуска строгий — сначала seafile, потом seahub. Третья — занят порт 8000: если раньше процесс завис, новый не сможет подняться. Проверьте, кто держит порт, и снимите зависший процесс.

ss -tlnp | grep 8000
kill <PID_зависшего_процесса>

После починки зависимостей и порядка запуска панель поднимается стабильно. Если вы завели systemd-юниты, обязательно пропишите зависимость seahub от seafile через After= и Requires=, иначе после перезагрузки сервера гонка запуска будет периодически ронять веб-часть.

Ошибка 502 Bad Gateway в Nginx

502 означает, что Nginx получил запрос, но не смог достучаться до бэкенда Seafile. Причина почти всегда в том, что Seahub не слушает ожидаемый порт или проксирование настроено на неверный адрес. Начните с проверки, что панель действительно работает локально.

curl -I http://127.0.0.1:8000

Если curl возвращает ответ, а снаружи всё равно 502 — дело в конфиге Nginx. Убедитесь, что proxy_pass указывает на http://127.0.0.1:8000, а не на внешний адрес, и что SELinux или AppArmor не блокируют исходящие соединения веб-сервера. Если же curl тоже не отвечает — значит, упал Seahub, и надо возвращаться к предыдущему разделу с логами. Отдельный подводный камень: после смены домена или порта нужно перечитать конфиг Nginx, а не просто перезапустить Seafile.

nginx -t && systemctl reload nginx

Иногда 502 появляется только под нагрузкой. Это признак того, что встроенный сервер разработки Seahub не тянет поток запросов. В продакшене Seahub положено запускать под Gunicorn — в современных сборках это уже так по умолчанию, но если вы поднимали панель древним способом через runserver, переведите её на Gunicorn с несколькими воркерами.

Большие файлы обрываются на загрузке

Классическая жалоба: файлы до сотни мегабайт заливаются нормально, а крупные архивы или видео обрываются на середине. Причина в двух ограничениях, которые работают независимо. Первое — лимит размера тела запроса в Nginx. По умолчанию он около мегабайта, и всё, что больше, отсекается. Снимите ограничение в блоке location, отвечающем за передачу файлов.

client_max_body_size 0;
proxy_request_buffering off;

Второе ограничение живёт внутри самого Seafile — это отдельный сервис передачи файлов на порту 8082, который должен корректно проксироваться по пути /seafhttp. Если этот location настроен неверно или отсутствует, синхронизация мелких файлов будет работать, а крупные загрузки через веб — падать. Проверьте, что в конфиге Nginx есть отдельный блок для /seafhttp с тем же снятым лимитом размера. И помните про таймауты: для многогигабайтных файлов на медленном канале увеличьте proxy_read_timeout и proxy_send_timeout, иначе прокси разорвёт соединение по тайм-ауту раньше, чем файл дойдёт до конца.

Клиент не синхронизируется, хотя веб работает

Бывает так, что через браузер всё видно, а десктопный или мобильный клиент выдаёт ошибку соединения. Почти всегда виноват неверный адрес сервиса передачи файлов. Seafile хранит два адреса: адрес веб-панели и отдельный адрес для клиентов, по которому они забирают и отдают блоки данных. Если после установки HTTPS вы поменяли домен только в одном месте, клиенты будут стучаться не туда.

Проверьте в веб-панели раздел настроек системного администратора — там указан URL сервиса передачи файлов. Он должен вести на ваш домен по HTTPS через путь /seafhttp, а не на голый IP с портом 8082. После правки перезапустите Seahub. Ещё одна причина — самоподписанный сертификат: клиент по умолчанию не доверяет ему и рвёт соединение. Решение честное и правильное — используйте валидный сертификат Let's Encrypt, а не самоподпись, тогда клиенты подключаются без ручных исключений.

Проблемы с базой данных MariaDB

Если в логах мелькает Access denied for user 'seafile' или Unknown database, значит, движок не может достучаться до базы. Частая причина — при установке вы указали пароль с спецсимволами, который мастер настройки прочитал неверно, либо права на базы не выданы полностью. Зайдите в консоль базы и перепроверьте права.

mysql -u seafile -p
SHOW DATABASES;

Пользователь должен видеть три базы: ccnet_db, seafile_db и seahub_db. Если каких-то нет или доступ закрыт, выдайте права заново командами GRANT и выполните FLUSH PRIVILEGES. Отдельная беда возникает при нехватке памяти: на VPS с 1 ГБ RAM MariaDB под нагрузкой может убиваться OOM-киллером, и тогда Seafile теряет базу в самый неподходящий момент. В dmesg вы увидите записи об убитом процессе mysqld. Лечится это либо увеличением памяти сервера, либо настройкой swap как временной меры — но swap для базы это компромисс, а не решение.

Если базе стабильно не хватает ресурсов, честнее перейти на VPS помощнее. Для облака Seafile на сервере с активной командой комфортный минимум — 2 ГБ RAM, а лучше 4. У MAATRIX можно взять такой VPS в нужной локации с оплатой из России картой, СБП или криптой и поднять хранилище за несколько минут, не упираясь в нехватку памяти под базу.

Облако не стартует после перезагрузки

Вы всё настроили, перезагрузили сервер — и хранилище недоступно. Причина в том, что ручной запуск через seafile.sh start не переживает ребут. Нужны юниты systemd с правильными зависимостями: движок должен ждать сеть и базу, а Seahub — движок. Проверьте статус.

systemctl status seafile seahub
journalctl -u seahub -n 40

Если юнит падает при загрузке с ошибкой доступа к каталогам, дело в правах: все каталоги данных должны принадлежать пользователю, от которого запускается сервис, а не root. Исправьте владельца рекурсивно и включите автозапуск обоих юнитов. Ещё один нюанс — база MariaDB может подниматься дольше, чем стартует Seafile, поэтому в юните движка полезно добавить не только After=mariadb.service, но и небольшую задержку или повторную попытку старта. После этого облако будет стабильно подниматься само после любой перезагрузки.

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