Как разместить File Browser на собственном сервере в 2026 году: тома, учётные записи и безопасный общий доступ

Рассматривайте File Browser как небольшую систему, а не как Docker-образ. Пользовательская задача File Browser проста: веб-файловый менеджер для подключённого тома; развёртывание можно считать приемлемым только после того, как вы создадите пользователя с ограниченными правами, загрузите и переименуете файл, отредактируете текст, создадите ссылку общего доступа и убедитесь, что пользователь не может выйти за пределы назначенного ему корня.

Это различие позволяет обнаружить проблему, с которой операторы сталкиваются после локального тестирования: смонтированные файлы используют права хоста, а контейнер не может их прочитать. Кроме того, план резервного копирования и обновления становится достаточно конкретным для проверки.

Найдите все постоянные данные File Browser

Образ контейнера можно скачать заново, а обслуживаемые файлы, база данных и настройки File Browser — нельзя. Смонтируйте /srv до начальной настройки, запишите безвредные тестовые данные и замените контейнер, чтобы убедиться, что этот путь действительно сохраняется. Проверяйте фактическое подключение тома, а не доверяйте имени файла Compose, и убедитесь, что пользователь runtime может записывать данные туда, где этого ожидает File Browser.

Выберите срок хранения и внешнее хранилище, затем отрепетируйте восстановление, не затрагивая production. Проверка считается успешной только тогда, когда восстанавливаются обслуживаемые файлы, пользователи, области доступа, ссылки общего доступа и настройки, а пользователь с ограниченными правами по-прежнему не может выйти за пределы назначенной ему области. Для состояния, хранящегося в базе данных, сочетайте snapshots хранилища с согласованными с приложением экспортами, как описано в руководстве восстановление на момент времени и snapshots.

Запустите первый экземпляр, максимально близкий к production

Сделайте первоначальный запуск File Browser достаточно воспроизводимым, чтобы его можно было проверить в pull request.

docker run -d \
  --name file-browser \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v file-browser-data:/srv \
  -v file-browser-db:/database \
  -v file-browser-config:/config \
  filebrowser/filebrowser:latest

Не полагайтесь на latest, когда в системе уже появились реальные данные. Зафиксируйте рабочий digest, пользователя контейнера и владельца подключённых путей. Проследите за логом приложения в ходе полного теста — создайте пользователя с ограниченными правами, загрузите и переименуйте файл, отредактируйте текст, создайте ссылку общего доступа и убедитесь, что пользователь не может выйти за пределы назначенного ему корня, — и зафиксируйте все миграции до того, как направлять production-трафик на этот маршрут.

Определите границу runtime File Browser

Состояние процесса и состояние продукта — разные вещи для File Browser. Порт 80 может отвечать, даже если пользовательская операция по-прежнему завершается ошибкой. Локальное требование runtime — отдельный постоянный путь для базы данных и настроек. Проверяйте его в рамках рабочей нагрузки приёмки: health check в режиме простоя не может доказать, что ресурса достаточно.

После существенных изменений конфигурации выполняйте такую проверку готовности: создайте пользователя с ограниченными правами, загрузите и переименуйте файл, отредактируйте текст, создайте ссылку общего доступа и убедитесь, что пользователь не может выйти за пределы назначенного ему корня. Не помещайте дорогие внешние проверки в liveness probes, чтобы сбой провайдера не вызывал цикл перезапусков. При планировании ёмкости отслеживайте пропускную способность диска, размер загрузок, число параллельных скачиваний и количество каталогов — эти показатели лучше отражают реальную нагрузку File Browser, чем количество запросов к страницам.

Сделайте публичный origin однозначным

Откройте для File Browser один HTTPS-хостнейм, а исходящий порт 80 оставьте закрытым извне. Публикуйте UI по HTTPS, но тщательно ограничьте обслуживаемый корень. Это не позволит браузерам и API-клиентам использовать два конкурирующих адреса.

С чистого клиента выполните заведомо рабочую операцию и проверьте первый запрос, завершившийся ошибкой. Если проблема связана с DNS или TLS, воспользуйтесь руководством по custom domain. Если маршрут уже проверен, рассматривайте проблему «смонтированные файлы используют права хоста, а контейнер не может их прочитать» как отдельную диагностику приложения.

Критерии выпуска File Browser

Создайте небольшой временный fixture для File Browser и сохраняйте его для каждого выпуска. Fixture должен проверять реальный workflow: создание пользователя с ограниченными правами, загрузку и переименование файла, редактирование текста, создание ссылки общего доступа и невозможность выхода пользователя за пределы назначенного ему корня. Запишите digest образа, внешний хостнейм, адрес зависимости и ожидаемый результат, чтобы другой оператор мог повторить проверку без необходимости интерпретировать это руководство.

Запустите fixture три раза. Сначала используйте свежее развёртывание. Затем замените контейнер, не затрагивая постоянное состояние. Наконец, восстановите резервную копию в пустом окружении. Третий запуск считается успешным только тогда, когда восстанавливаются обслуживаемые файлы, пользователи, области доступа, ссылки общего доступа и настройки, а пользователь с ограниченными правами по-прежнему не может выйти за пределы назначенной ему области. Во время каждого запуска измеряйте задержку и использование ресурсов с учётом пропускной способности диска, размера загрузок, числа параллельных скачиваний и количества каталогов; это станет базой для alerting вместо произвольного процента загрузки CPU.

Наконец, намеренно проверьте негативный сценарий: отправьте безвредные данные рядом с ограничением ресурса или формата, связанным с этой границей: смонтированные файлы используют права хоста, а контейнер не может их прочитать. Убедитесь, что File Browser явно сообщает об ошибке и не повреждает состояние, восстановите правильное условие и повторите успешную операцию. Запись о выпуске с этими четырьмя результатами — более весомое доказательство, чем screenshots dashboard или однократный ответ curl.

Проверки ёмкости и обновления

Health check в режиме простоя мало что говорит о File Browser. Следите за пропускной способностью диска, размером загрузок, числом параллельных скачиваний и количеством каталогов, а alerting настраивайте по симптому, который видит пользователь: сбою операции «создать пользователя с ограниченными правами, загрузить и переименовать файл, отредактировать текст, создать ссылку общего доступа и убедиться, что пользователь не может выйти за пределы назначенного ему корня». Liveness должна оставаться локальной и дешёвой; readiness должна сообщать о миграциях или инициализации, не вызывая шквал перезапусков.

Рискованная часть обновления заключается в том, что миграции базы данных и настроек File Browser важны, даже если обслуживаемые файлы находятся на отдельном подключённом пути. Прочитайте release notes, создайте snapshot состояния, разверните целевую версию поверх восстановленной копии и повторите приёмочную операцию. Если смонтированные файлы используют права хоста, а контейнер не может их прочитать, сопоставьте клиентский запрос с первой релевантной записью в логе приложения, а не удаляйте состояние и не добавляйте redirects вслепую.

Сократите полномочия File Browser

Учётные данные для начальной настройки временные, а модель доверия — постоянная. В случае с File Browser следите за тем, чтобы вместо выделенного общего каталога не обслуживался / или каталог с секретами, используйте выделенный каталог вместо корня хоста и назначайте каждой учётной записи минимально необходимую область доступа к файлам.

В этой базовой конфигурации File Browser не требует обязательного bootstrap-секрета; вместо этого защитите фактическую учётную запись администратора или upstream-аутентификацию. Запускайте образ без лишних Linux capabilities и открывайте только публичный маршрут приложения. Сохраняйте видимость действий администратора, не записывая значения секретов.

Используйте Dockup для платформенного слоя

Для File Browser Dockup особенно полезен на границе между образом и постоянным сервисом. Он сохраняет маршрут к порту 80, TLS, значения секретов и подключённое хранилище при замене контейнеров — независимо от того, где находится compute: в Dockup или на вашем подключённом сервере.

Завершайте настройку с учётом особенностей приложения: публикуйте UI по HTTPS, но тщательно ограничивайте обслуживаемый корень; подтвердите локальное требование — отдельный постоянный путь для базы данных и настроек; и выполните эту проверку: создайте пользователя с ограниченными правами, загрузите и переименуйте файл, отредактируйте текст, создайте ссылку общего доступа и убедитесь, что пользователь не может выйти за пределы назначенного ему корня. Сохраните результат как deployment check, чтобы следующая версия образа оценивалась по поведению, а не по статусу контейнера.

Часто задаваемые вопросы

Что нужно File Browser для развёртывания в production?

Направьте контейнер File Browser на порт 80 через один HTTPS-origin. Локальное требование runtime — отдельный постоянный путь для базы данных и настроек. Не объявляйте File Browser готовым, пока не сможете создать пользователя с ограниченными правами, загрузить и переименовать файл, отредактировать текст, создать ссылку общего доступа и убедиться, что пользователь не может выйти за пределы назначенного ему корня.

Какие данные File Browser нужно включать в резервную копию?

Сохраняйте /srv и включайте обслуживаемые файлы, базу данных и настройки File Browser в один recovery manifest. Восстановление File Browser в чистом окружении считается успешным только тогда, когда возвращаются обслуживаемые файлы, пользователи, области доступа, ссылки общего доступа и настройки, а пользователь с ограниченными правами по-прежнему не может выйти за пределы назначенной ему области.

Требуется ли File Browser HTTPS за reverse proxy?

Используйте HTTPS для публичного origin File Browser, а порт 80 оставьте во внутреннем маршруте. Корректно примените настройку File Browser: публикуйте UI по HTTPS, но тщательно ограничивайте обслуживаемый корень. Для File Browser HTTPS защищает учётные данные и пользовательский контент при передаче и обеспечивает согласованное поведение клиентов, зависящее от origin.

Как тестировать обновление File Browser?

Восстановите текущее состояние File Browser в изолированном развёртывании, примените candidate-версию и повторите приёмочную операцию. Обратите особое внимание на то, что миграции базы данных и настроек File Browser важны, даже если обслуживаемые файлы находятся на отдельном подключённом пути. Сохраняйте предыдущий образ File Browser, пока не будут понятны границы миграции данных и rollback.