File Browser закрывается 1 сентября: чем заменить и как перенести

Что случилось

27 июля 2026 года вышел последний плановый релиз File Browser — v2.63.23. На следующий день автор проекта, Энрике Диас, опубликовал объявление о его закрытии. Репозиторий архивируется 1 сентября 2026.

File Browser — это тот самый лёгкий веб-интерфейс к папке на сервере: зашёл в браузере, видишь дерево файлов, можешь загрузить, скачать, переименовать, поделиться ссылкой. Один бинарник, никаких зависимостей. За десять с лишним лет проект собрал больше 35 тысяч звёзд на GitHub и стоит у огромного числа людей на домашних серверах и VPS.

Причину автор объясняет честно: проект начинался как хобби пятнадцатилетнего подростка больше десяти лет назад, и заложенная тогда архитектура не выдерживает современных требований к безопасности. Формулировка из объявления: это «нельзя залатать — File Browser нужно переписывать с нуля», а времени и желания на это уже нет.

Насколько это срочно лично для вас

Зависит от того, как у вас развёрнут File Browser. Автор отдельно упоминает проблемы с сессиями: истёкшие токены в некоторых случаях продолжают работать, а выход из аккаунта не отзывает токен — то есть если токен у вас украли, он останется действительным. И это не единственная архитектурная дыра, просто самая наглядная.

Дальше исправлений не будет вообще. Поэтому:

Главная хорошая новость дальше — переезд почти наверняка окажется проще, чем вы думаете.

Почему переезд — это не «миграция данных»

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

Поэтому «переезд» сводится к тому, чтобы направить новый инструмент на ту же самую папку и заново завести пользователей. Файлы при этом вообще не двигаются с места — вы их даже не копируете.

Что действительно придётся пересоздать вручную: учётные записи и публичные ссылки-шары — старые ссылки после переезда перестанут работать, потому что их выдавал старый сервис. Если вы кому-то раздавали такие ссылки, предупредите заранее.

Что ставить вместо

Автор File Browser сознательно не советует конкретную замену — и правильно делает, потому что «файловый менеджер в браузере» люди понимают очень по-разному. Вот четыре живых проекта и то, какую задачу каждый закрывает на самом деле:

Дальше подробно разберём FileBrowser Quantum — это замена «один в один» для большинства сценариев. В конце коротко покажу copyparty для тех, у кого другой профиль задач.

Чем FileBrowser Quantum отличается от оригинала

Quantum начинался как форк File Browser, но за это время разошёлся с ним настолько, что общего кода почти не осталось. Мотив в FAQ объясняется просто: базовые функции годами висели в оригинале нерассмотренными пул-реквестами — форк появился именно поэтому.

Что добавилось

• Мгновенный поиск по проиндексированным файлам — не рекурсивный обход при каждом запросе
• Несколько источников (папок) в одной установке, с правилами включения и исключения
• Нормальная аутентификация: пароль с двухфакторкой, OIDC, LDAP, вход через прокси
• Превью для видео, офисных документов, обложек и даже 3D-моделей
• WebDAV — можно подключить папку как сетевой диск
• Настройка через YAML-файл вместо флагов командной строки

Что убрали — и это важно проверить до переезда

Если вы использовали runners для автоматизации — заложите время на то, чтобы переписать эту логику отдельным скриптом по cron или через n8n. Это единственное, что может превратить получасовой переезд в полудневный.

Установка FileBrowser Quantum

Ставим рядом со старым File Browser, на другом порту. Так вы сможете спокойно всё проверить и выключить старый только тогда, когда убедитесь, что новый работает.

Дальше по тексту: файлы лежат в /srv/files, домен — files.example.com. Подставьте свои значения. Нужен установленный Docker — если его нет, есть отдельная статья про Docker Compose.

Шаг 1. Сделайте бэкап старой базы

Файлы вы не трогаете, но старую базу лучше сохранить — из неё можно подсмотреть список пользователей и их права, когда будете заводить их заново. Найдите её и скопируйте:

# Ищем базу старого File Browser
sudo find / -name "database.db" -not -path "*/docker/overlay2/*" 2>/dev/null

# Копируем найденный файл в надёжное место
cp /path/to/database.db ~/filebrowser-old-database.db.bak

Шаг 2. Создайте каталог и конфиг

mkdir -p ~/filebrowser/data && cd ~/filebrowser
nano data/config.yaml

Содержимое data/config.yaml:

server:
  port: 80
  baseURL: "/"
  # Домен, по которому сервис виден снаружи.
  # Без него ссылки-шары будут указывать на внутренний адрес.
  externalUrl: "https://files.example.com"
  # Кэш превью. Внутри каталога data, чтобы переживал перезапуск.
  cacheDir: "/home/filebrowser/data/tmp"
  database: "/home/filebrowser/data/database.db"
  sources:
    - path: "/folder"
      name: "files"
      config:
        defaultEnabled: true

auth:
  adminUsername: admin
  # Через сколько часов истекает сессия в браузере
  tokenExpirationHours: 8
  methods:
    password:
      enabled: true
      minLength: 12
      signup: false

Шаг 3. Docker Compose

Создайте ~/filebrowser/docker-compose.yml:

services:
  filebrowser:
    image: gtstef/filebrowser:1.5-stable
    container_name: filebrowser
    restart: unless-stopped
    ports:
      # Наружу не выставляем — доступ только через Nginx
      - "127.0.0.1:8080:80"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    environment:
      # Значение берётся из файла .env рядом с этим файлом
      FILEBROWSER_ADMIN_PASSWORD: "${FILEBROWSER_ADMIN_PASSWORD}"

Обратите внимание на 127.0.0.1:8080:80. Внутри контейнера сервис слушает порт 80 — так задано в конфиге и на это же рассчитан встроенный healthcheck образа, поэтому внутренний порт лучше не менять. А снаружи мы публикуем его на 8080 и только на localhost: напрямую из интернета достучаться нельзя, всё пойдёт через Nginx.

Сам пароль держим в отдельном файле ~/filebrowser/.env — Docker Compose подхватывает его автоматически. Так пароль не попадёт в конфиг, который вы захотите кому-то показать или положить в git:

cd ~/filebrowser
echo 'FILEBROWSER_ADMIN_PASSWORD=ваш-длинный-пароль' > .env
chmod 600 .env

Шаг 4. Права на папки

Контейнер работает не от root, а от пользователя filebrowser с UID и GID 1000. Значит, он должен иметь доступ и к каталогу с базой, и к папке с файлами — иначе получите ошибки прав при первом же запуске:

# Каталог с конфигом, базой и кэшем
chown -R 1000:1000 ~/filebrowser/data

# Папка с вашими файлами — если она принадлежит root
sudo chown -R 1000:1000 /srv/files

Шаг 5. Запуск

cd ~/filebrowser
docker compose up -d
docker compose logs -f

В логах должно появиться сообщение о запуске сервера и об индексации источника. Проверим, что сервис отвечает:

curl -i http://127.0.0.1:8080/health

Ответ 200 OK — значит всё поднялось. Теперь можно открывать доступ снаружи.

Важный нюанс с паролем администратора

Это место работает не так, как ожидает большинство, и в документации об этом не сказано — поэтому разберём отдельно. Пока переменная FILEBROWSER_ADMIN_PASSWORD задана, пароль администратора принудительно устанавливается заново при каждом запуске контейнера, а не только при первом. В логах это видно строкой «Resetting admin user to default username and password».

Отсюда два практических вывода.

Хорошая новость: если первый запуск уже случился с паролем по умолчанию, ничего удалять не нужно. Достаточно задать переменную и перезапустить — новый пароль применится к существующей базе:

cd ~/filebrowser
echo 'FILEBROWSER_ADMIN_PASSWORD=ваш-длинный-пароль' > .env
chmod 600 .env
docker compose up -d --force-recreate

Nginx и HTTPS

Создайте /etc/nginx/sites-available/filebrowser:

server {
    listen 80;
    server_name files.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;

        proxy_set_header Host              $host;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        # Размер загружаемого файла. 0 — без ограничения со стороны Nginx
        client_max_body_size 0;

        # Не копить ответ в буфере: нужно для живых обновлений интерфейса
        proxy_buffering off;
        # Не копить загружаемый файл на диске Nginx перед отправкой дальше
        proxy_request_buffering off;

        # Запас по времени на большие загрузки
        proxy_read_timeout  3600s;
        proxy_send_timeout  3600s;
    }
}

Включаем сайт и выпускаем сертификат:

ln -s /etc/nginx/sites-available/filebrowser /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx

# Сертификат Let's Encrypt — certbot сам допишет секцию с HTTPS
certbot --nginx -d files.example.com

Домен должен уже указывать A-записью на IP сервера, иначе certbot не сможет подтвердить владение.

Первый вход и перенос пользователей

Откройте https://files.example.com и войдите как admin с паролем из файла .env. Вы увидите содержимое /srv/files — те же файлы, что показывал старый File Browser.

Заводим остальных пользователей

Настройки → User Management → создать пользователя. Права в Quantum разделены на группы: доступ к файлам (просмотр, скачивание, изменение, создание, удаление) и общие возможности (администрирование, API, создание ссылок).

Разумный минимум для обычного пользователя: разрешить скачивание и изменение, запретить администрирование и доступ к API. Не выдавайте админские права «чтобы работало» — в интерфейсе всё настраивается точечно.

Включите двухфакторную аутентификацию

Раз уж вы переезжаете из-за проблем с безопасностью — не повторяйте старую конфигурацию. Если сервис смотрит в интернет, включите обязательный одноразовый код. Для этого в уже созданном data/config.yaml допишите одну строку в конец блока password — остальные строки уже на месте, заменять блок целиком не нужно:

auth:
  adminUsername: admin
  tokenExpirationHours: 8
  methods:
    password:
      enabled: true
      minLength: 12
      signup: false
      enforcedOtp: true   # добавили: обязательный код из приложения-аутентификатора

После docker compose restart вход по одному паролю перестанет работать: пока пользователь не привяжет приложение-аутентификатор, сервер будет отвечать отказом. Так и задумано — привязка происходит в настройках профиля.

Пересоздайте ссылки-шары

Старые публичные ссылки работать не будут — их выдавал прежний сервис. Пересоздайте нужные через кнопку «поделиться» на файле или папке. В диалоге создания есть то, чего в оригинале не хватало: срок жизни ссылки, пароль на доступ, запрет анонимного доступа и ограничение списком конкретных пользователей. Если раньше вы раздавали вечные ссылки без пароля — сейчас хороший повод это поменять.

Выключаем старый File Browser

Убедились, что новый сервис работает и все файлы на месте — гасим старый. Если он в Docker:

cd /путь/к/старому/filebrowser
docker compose down

# Убедитесь, что контейнер действительно остановлен
docker ps | grep -i filebrowser

Если он был установлен как systemd-сервис:

systemctl stop filebrowser
systemctl disable filebrowser

Не удаляйте старый конфиг и базу сразу — подержите пару недель, пока не убедитесь, что ничего не забыли перенести.

copyparty — если главное для вас загрузки

copyparty решает ту же задачу под другим углом. Его сильная сторона — передача файлов: загрузка идёт кусками и продолжается после обрыва связи, а не начинается заново. Плюс он одновременно отдаёт содержимое по WebDAV, FTP, SFTP и SMB — то есть ту же папку можно подключить сетевым диском без дополнительных сервисов.

Расплата — интерфейс. Он функциональный, но заметно более «инженерный», чем у Quantum. Берите copyparty, если регулярно заливаете многогигабайтные файлы по нестабильному каналу; в остальных случаях Quantum будет привычнее.

Минимальная установка

Создайте каталог и файл конфигурации ~/copyparty/copyparty.conf:

[global]
  e2dsa          # индексировать файлы, чтобы работал поиск
  ansi           # цветные логи

[accounts]
  anna: ЗАМЕНИТЕ_НА_ПАРОЛЬ

[/]              # том в корне веб-интерфейса
  /w             # отдаём каталог /w внутри контейнера
  accs:
    rwmda: anna  # чтение, запись, перемещение, удаление, админ — только anna

Файл ~/copyparty/docker-compose.yml:

services:
  copyparty:
    image: copyparty/ac:latest
    container_name: copyparty
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "127.0.0.1:3923:3923"
    volumes:
      - ./:/cfg          # сюда кладём copyparty.conf
      - /srv/files:/w    # раздаваемая папка

Права нужны те же, что и для Quantum, — контейнер тоже работает от UID 1000:

chown -R 1000:1000 ~/copyparty
sudo chown -R 1000:1000 /srv/files

cd ~/copyparty
docker compose up -d

Конфиг подхватывается из каталога /cfg — важно, чтобы имя файла заканчивалось на .conf, иначе он будет проигнорирован. Nginx настраивается так же, как выше, только порт 3923.

Одно отличие от Quantum, о котором стоит знать заранее: copyparty создаёт служебный каталог .hist внутри раздаваемой папки — там лежат поисковый индекс и миниатюры. Это нормально, но учтите при настройке бэкапов: этот каталог копировать не нужно, он пересоздаётся сам.

Обновление и бэкап

Стабильная ветка Quantum обновляется раз в 1–3 месяца:

cd ~/filebrowser
docker compose pull
docker compose up -d

Тег 1.5-stable даёт патчи внутри ветки 1.5, но не утащит вас на 2.0 внезапно. Переход на v2.0.0 — это отдельная одноразовая миграция базы с BoltDB на SQLite, и делать её нужно осознанно, по официальной инструкции, а не случайным pull.

Бэкапить нужно каталог data — в нём конфиг и база с пользователями. Контейнер на время копирования лучше остановить, чтобы база не оказалась в промежуточном состоянии:

cd ~/filebrowser
docker compose stop
# tmp — это кэш превью, он пересоздаётся сам и в бэкапе не нужен
tar czf ~/filebrowser-backup-$(date +%F).tar.gz --exclude=data/tmp data .env
docker compose start

Сами файлы бэкапятся отдельно и обычным способом — про это есть статья про restic и rclone.

Частые проблемы