Как установить и настроить File Browser на VPS

MAATRIX

Заливать файлы на сервер через SFTP-клиент неудобно, когда доступ нужен не только вам: показать клиенту папку с отчётами, дать дизайнеру право загружать макеты без SSH-ключа, быстро открыть файл в браузере с телефона. File Browser закрывает эту задачу одним бинарником — лёгкий веб-интерфейс с загрузкой, редактированием текста прямо в браузере, шарингом по ссылке и правами доступа на пользователя. Ниже — рабочая установка через Docker, настройка HTTPS через обратный прокси и типичные грабли.

Что такое File Browser и когда он нужен

File Browser — открытый проект на Go, который отдаёт файловую систему (или её часть) через веб-интерфейс: список файлов, drag-and-drop загрузка, встроенный редактор для текстовых файлов, превью изображений, скачивание архивом, публичные ссылки на файлы с ограничением по времени. Это не облачное хранилище с синхронизацией вроде Nextcloud — если нужна синхронизация между устройствами, общие календари и совместное редактирование документов, туда и стоит смотреть: у нас есть отдельный разбор, как установить Nextcloud на VPS. File Browser проще: это просто удобный доступ к папке на диске сервера через браузер, без баз данных офисных пакетов и тяжёлого рантайма.

Типичные сценарии:

• Доступ к папке с бэкапами или логами для коллег без выдачи SSH-доступа.
• Приёмка файлов от клиентов (фото, документы) через простую ссылку с логином.
• Быстрое редактирование конфигов на сервере из браузера, когда под рукой нет терминала.
• Раздача файлов небольшой команде — с квотами и разными правами для разных пользователей.

Требования минимальны: 512 МБ RAM и 1 vCPU хватает с запасом, диск — по объёму файлов, которые будете хранить. Подойдёт любой бюджетный VPS.

Установка через Docker Compose

Самый предсказуемый способ развернуть File Browser — Docker, так проще обновлять и не тащить зависимости в систему. Если Docker ещё не стоит, сначала разверните его: инструкция по установке Docker на Ubuntu 24.04 занимает пять минут.

Создаём рабочую директорию и структуру:

mkdir -p /opt/filebrowser/{config,database,srv}
cd /opt/filebrowser

• srv — папка, которую File Browser будет показывать (сюда кладёте файлы или монтируете нужные каталоги).
• database — SQLite-база с пользователями и настройками.
• config — файл конфигурации (settings.json), если понадобится тонкая настройка.

Файл docker-compose.yml:

services:
  filebrowser:
    image: filebrowser/filebrowser:s6
    container_name: filebrowser
    restart: unless-stopped
    ports:
      - "127.0.0.1:8080:80"
    volumes:
      - ./srv:/srv
      - ./database/filebrowser.db:/database/filebrowser.db
      - ./config/settings.json:/config/settings.json
    environment:
      - PUID=1000
      - PGID=1000

Обратите внимание на s6-тег образа — он даёт возможность гибко задавать PUID/PGID, чтобы файлы, созданные через веб-интерфейс, принадлежали нужному пользователю, а не root. Порт публикуем только на localhost (127.0.0.1:8080) — наружу File Browser отдаём через обратный прокси с HTTPS, напрямую в интернет сервис без TLS смотреть не должен.

Перед первым запуском нужно создать пустые файлы для монтирования — Docker иначе создаст на их месте директории:

touch database/filebrowser.db
touch config/settings.json
docker compose up -d

Проверяем, что контейнер поднялся и слушает порт:

docker compose ps
docker compose logs -f filebrowser

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

По умолчанию File Browser создаёт пользователя admin с автосгенерированным паролем — он попадёт в логи при первом запуске:

docker compose logs filebrowser | grep -i "randomly generated password"

Сразу после входа смените пароль — это критично, если сервис будет доступен извне даже через прокси. Сделать это можно и без веб-интерфейса, через CLI внутри контейнера:

docker compose exec filebrowser filebrowser users update admin --password 'НовыйСложныйПароль123!'

Заодно проверьте, что случайный пароль не попал в постоянно хранящиеся логи Docker — если сервер многопользовательский, стоит почистить вывод docker compose logs через docker compose logs --no-log-prefix в скрипте или ограничить ротацию логов драйвера.

Настройка пользователей и прав доступа

File Browser поддерживает несколько пользователей с разными правами: у кого-то полный доступ на запись, у кого-то — только просмотр и скачивание конкретной подпапки. Управлять можно через веб-интерфейс (Settings → Users) или CLI.

Создание пользователя только для чтения из CLI:

docker compose exec filebrowser filebrowser users add viewer 'ПарольДляПросмотра' \
  --perm.admin=false \
  --perm.create=false \
  --perm.rename=false \
  --perm.modify=false \
  --perm.delete=false \
  --perm.share=false \
  --perm.download=true

Полезная возможность — «scope» пользователя: можно ограничить его доступ конкретной поддиректорией внутри /srv, чтобы разные клиенты видели только свои папки, не пересекаясь друг с другом. Это задаётся полем Scope в настройках пользователя через UI (Settings → Users → выбрать пользователя → Scope: /client-a).

Для разграничения прав в целом полезно понимать общую модель прав в Linux — если сталкивались с путаницей вокруг того, кто на самом деле пишет в примонтированные тома, посмотрите на владельца файлов через ls -la /opt/filebrowser/srv после первой загрузки: он должен совпадать с PUID/PGID, которые вы задали в compose-файле.

Публикация через Nginx с HTTPS

Отдавать File Browser напрямую по порту 8080 без шифрования — плохая идея: пароли и файлы пойдут открытым текстом. Ставим Nginx как обратный прокси и получаем сертификат. Если ещё не настраивали домен на сервере, начните с настройки DNS и домена на Ubuntu 24.04.

Конфиг Nginx (/etc/nginx/sites-available/filebrowser.conf):

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-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;

        client_max_body_size 4G;
        proxy_read_timeout 600s;
        proxy_send_timeout 600s;
    }
}

client_max_body_size увеличен, потому что File Browser часто используют для загрузки больших файлов — с дефолтным лимитом Nginx в 1 МБ загрузка любого архива или видео будет падать с ошибкой 413. Таймауты тоже подняты — большие загрузки на медленном канале могут длиться дольше стандартных 60 секунд.

Активируем сайт и получаем сертификат Let's Encrypt:

ln -s /etc/nginx/sites-available/filebrowser.conf /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
certbot --nginx -d files.example.com

Если предпочитаете более простой в настройке вариант с автоматическим HTTPS без ручного Certbot, посмотрите на сравнение Caddy и Nginx для сервера — для одного сервиса вроде File Browser конфиг Caddy получится буквально в три строки.

Шаринг файлов и внешние ссылки

Одна из главных причин ставить File Browser — быстрая раздача файла по ссылке без учётки получателя. В интерфейсе выбираете файл → Share → задаёте срок действия ссылки (от часа до бессрочной) и, при желании, пароль на саму ссылку.

Нюансы, которые стоит знать заранее:

• Ссылка отдаёт файл напрямую через прокси-домен, поэтому HTTPS обязателен — иначе ссылка утечёт вместе с трафиком в общедоступном Wi-Fi.
• Бессрочные ссылки на конфиденциальные файлы — плохая практика: ставьте разумный TTL и удаляйте расшаренный файл, когда он больше не нужен.
• Публичная ссылка не проверяет права пользователя — если файл лежит в общей директории /srv, доступной нескольким пользователям, шарить его может любой с правом share, даже не автор файла. Разграничивайте директории через Scope, если это критично.

Резервное копирование данных File Browser

Терять нужно бояться не файлы (они и так на диске в /opt/filebrowser/srv), а базу с пользователями и настройками — filebrowser.db. Восстановить её из памяти нельзя, придётся заново создавать пользователей и права.

Простой скрипт бэкапа с ротацией:

#!/bin/bash
set -e
DEST=/opt/backups/filebrowser
DATE=$(date +%Y-%m-%d)

mkdir -p "$DEST"
docker compose -f /opt/filebrowser/docker-compose.yml stop filebrowser
tar -czf "$DEST/filebrowser-db-$DATE.tar.gz" -C /opt/filebrowser database config
docker compose -f /opt/filebrowser/docker-compose.yml start filebrowser

find "$DEST" -name "filebrowser-db-*.tar.gz" -mtime +14 -delete

Останавливать контейнер на секунду перед копированием SQLite-базы — не паранойя: при живой записи в базу можно получить неконсистентный файл. Для файлов из srv, если их объём большой, лучше отдельный инкрементальный бэкап — например, через BorgBackup, который умеет дедупликацию и не гоняет по сети одни и те же гигабайты повторно. Добавьте скрипт в cron:

crontab -e
# 0 3 * * * /opt/filebrowser/backup.sh >> /var/log/filebrowser-backup.log 2>&1

Обновление и базовая защита сервиса

Обновление образа — стандартная процедура Docker Compose:

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

Перед обновлением на продакшене имеет смысл сделать бэкап базы (см. выше) — если новая версия меняет схему хранения, откат станет проще.

По защите сервиса — минимальный набор:

• Порт 8080 не публикуется наружу (см. 127.0.0.1:8080:80 в compose-файле выше) — единственная точка входа это Nginx с HTTPS.
• Firewall на сервере разрешает только 22, 80, 443 — если ещё не настраивали, вот инструкция по установке firewall UFW на VPS.
• Пароли пользователей — не дефолтные и не короче 12 символов, особенно у аккаунтов с правом delete и share.
• Fail2ban или аналогичная защита от перебора логина полезна, если сервис смотрит в открытый интернет, а не только в VPN — File Browser сам по себе не банит IP за неудачные попытки входа.

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