DockerでFileBrowserを構築：HomeLab向けの超軽量Webファイルマネージャー

Table of Contents

深夜2時にSSHやSMBが使えないトラブル

日曜日の深夜2時15分。ping値200msのホテルのWi-Fi環境にいるとき、ストレージノード上の45GBのバックアップアーカイブを即座に確認する必要があるというアラートが届きました。

SFTPクライアントを開こうとしますが、トラベルルーターのNATトラバーサルがうまく動作しません。次にWireGuard経由でSMB共有をマウントしますが、高レイテンシによりディレクトリ一覧の表示すら極度に遅延してしまいます。Nextcloudのようなフル機能のクラウドプラットフォームなら対応できますが、PHP-FPMプールとRedisキャッシュだけで設定ファイルのプレビューに2GBものRAMを消費してしまいます。

急を要するログファイルの確認や取得に、多機能なコラボレーションスイートは不要です。必要なのは、2秒未満で起動し、アイドル時のRAM消費が25MB未満で、マイクロコンテナ内で軽快に動作する専用のWebファイルマネージャーです。それこそがFileBrowserの強みです。

FileBrowserが軽量スタックに最適な理由

FileBrowserはGo言語で記述されており、40MB未満のAlpineベースのイメージにきれいにパッケージ化されています。状態管理の仕組みを理解しておくことで、後々のパーミッション問題を回避できます。

依存関係ゼロのアーキテクチャ

セルフホスト型のクラウドスイートでは、外部データベース（PostgreSQLやMariaDB）、バックグラウンドのRedisキャッシュ、定期実行用のcronコンテナが必要になることが一般的です。対照的に、FileBrowserが必要とするのは次の2つの要素だけです。

Webサーバーバイナリ： ドラッグ＆ドロップによるアップロード、オーディオ/ビデオのストリーミング、シンタックスハイライト対応のエディタを組み込んだVue.jsフロントエンドを提供する、コンパイル済みのGo実行ファイル。
SQLiteデータベース（filebrowser.db）： ユーザーのログイン情報、フォルダのスコープ設定、カスタムブランディング、共有トークンを保存する単一の組み込みデータベース。

直接的なファイルシステムパススルー

FileBrowserは仮想ストレージレイヤーや独自のオブジェクト形式を使用しません。コンテナ内にマウントしたディレクトリは、ZFSデータセット、unRAID共有、ローカルのext4マウントポイントなど、ホスト側のストレージに直接マッピングされます。rsyncでサーバーに10GBのISOファイルを配置した場合でも、インデックスの再構築を待つことなく即座にFileBrowser上に反映されます。

注意すべき点はUnixファイルの所有権です。メディアライブラリが標準ユーザー（UID 1000）の所有であるのに対し、コンテナがroot（UID 0）として実行されている場合、Web UIからアップロードされたファイルはroot権限で書き込まれます。これにより、Jellyfinなどの後続サービスやバックグラウンドのバックアップスクリプトがアクセスできなくなる恐れがあります。実行ユーザーの権限を明示的に指定することでこの問題を解決できます。

Dockerによる段階的なデプロイ手順

Docker Composeを使用して、永続的な設定と適切なファイルシステム権限を持つFileBrowserをセットアップする手順は以下の通りです。

ステップ1：ディレクトリの準備とデータベースの初期化

まず、FileBrowserの設定ファイルとマッピング用ストレージを配置するホストディレクトリを作成します。

mkdir -p /opt/filebrowser/config
mkdir -p /srv/storage

# Dockerを起動する前に空のデータベースファイルを作成
touch /opt/filebrowser/config/filebrowser.db

# 非rootユーザー（例：UID/GID 1000）に所有権を割り当て
sudo chown -R 1000:1000 /opt/filebrowser /srv/storage

コンテナを起動する前にfilebrowser.dbを作成しておくことが極めて重要です。存在しないファイルパスをDockerでマウントすると、その名前で空のディレクトリが自動生成されてしまい、Goバイナリが起動時にSQLiteファイルを開けずエラーになります。

ステップ2：Composeファイルの設定

/opt/filebrowser/内にdocker-compose.ymlファイルを作成します。

version: "3.8"

services:
  filebrowser:
    image: filebrowser/filebrowser:v2.30.0
    container_name: filebrowser
    restart: unless-stopped
    user: "1000:1000"
    ports:
      - "8080:80"
    volumes:
      # 管理対象のファイルを格納するルートストレージディレクトリ
      - /srv/storage:/srv
      # 永続化用SQLite設定データベース
      - /opt/filebrowser/config/filebrowser.db:/database/filebrowser.db
      # カスタム設定の上書き（任意）
      - /opt/filebrowser/config/settings.json:/.filebrowser.json
    security_opt:
      - no-new-privileges:true

ステップ3：起動と動作確認

コンテナをバックグラウンドで起動します。

cd /opt/filebrowser
docker compose up -d

コンテナのログを確認し、パーミッションエラーなくデータベースが初期化されたかを検証します。

docker logs -f filebrowser

数秒以内に以下のような確認ログが出力されるはずです。

Listening on [::]:80
Using database: /database/filebrowser.db

ステップ4：初期ログインとセキュリティ強化

ブラウザでhttp://<サーバーのIPアドレス>:8080にアクセスします。

デフォルトの認証情報： ユーザー名admin、パスワードadminでサインインします。
管理者パスワードの変更： すぐにSettings > Profile Settingsに移動し、強力なマスターパスワードを設定します。
シェルコマンドの制限： Web UIからサーバー側のシェルコマンドを実行する明示的な必要性がない限り、Settings > Global Settingsでコマンド実行が無効化されていることを確認します。
スコープ制限付きアカウントの作成： Settings > User Managementから制限付きユーザーを追加します。アカウントを/srv/backups/workのようなサブフォルダに制限し、ファイルの削除権限を剥奪することができます。

ステップ5：CLIを使用した緊急パスワードリセット

adminアカウントへのアクセスを失った場合でも、データベースを初期化したり設定を削除したりする必要はありません。稼働中のコンテナ内でFileBrowserバイナリを直接実行し、パスワードをリセットできます。

docker exec -it filebrowser /filebrowser users update admin --password "NewStrongPass2026!" --database /database/filebrowser.db

まとめ

深夜にストレージ関連のトラブルが発生した際、シンプルなツールこそが迅速で確実な復旧を可能にします。FileBrowserをDockerで運用することで、システムリソースをほぼ消費せず、データベースの肥大化を避け、実際のストレージドライブと直接連携できるWebベースのファイルポータルが手に入ります。