セルフホスト型ファイルマネージャー4製品を比較

セルフホスト型ファイルマネージャーとは何か、何ではないか

セルフホスト型ファイルマネージャーは、VPS (virtual private server) にすでに存在するディレクトリツリーを Web ページとして表示するものです。ログインすると、ディスク上にある /srv/files の状態をそのまま確認でき、ファイルのアップロード、名前変更、ダウンロード、リンクの共有を行えます。別のシステムにコピーを作成しないため、ブラウザーから配置したファイルは、1 秒後には ls に表示されます。

検索結果では、別の役割を持つソフトウェアも同じものとして扱われがちです。同期ツールはすべてのデバイスに各ファイルのコピーを保持します。これは セルフホスト型 Dropbox 代替サービスの用途です。オブジェクトストレージにはディレクトリツリーがなく、バケットと API を使用します。そのため、S3 互換オブジェクトストレージとして MinIO を運用する方法は別の問題に答えるものです。サーバー管理パネルはファイルではなくマシンを管理します。これについては、Cockpit と Webmin の比較を参照してください。

同僚にサーバーから 300 MB のアーカイブを 1 つ取得してもらう場合や、スマートフォンから設定ファイルの誤字を修正したい場合に、ファイルマネージャーが役立ちます。作業は小規模であり、使用するツールも小規模です。

読み進める際は、次の点を意識してください。これは、ファイルシステムへの読み取りおよび書き込みアクセスを持ち、ポートで待ち受ける Web アプリケーションです。以下の選択はすべて、そのプロセスがディスクのどこまでアクセスできるようにするかに関する選択です。

FileBrowser はアーカイブ済みです。インストール前に確認してください

FileBrowser は filebrowser/filebrowser プロジェクトで、多くのガイドが今でも推奨する選択肢です。ただし、現在の README の冒頭には次の通知があります。

File Browser は 2026-09-01 にアーカイブされました。最後に予定されていたリリースはすでに公開されています。今後、リリース、バグ修正、セキュリティ修正は行われません。

Apache 2.0 ライセンスのコードは引き続き動作します。ただし、セキュリティ修正は停止します。このカテゴリでは、ほかの多くのソフトウェアよりも重大です。FileBrowser の主な目的は、HTTP 経由でファイルシステムへの書き込みアクセスを提供することだからです。

メンテナーは、運用を継続する方法を文書化しています。どのツールを選ぶ場合でも、この助言に従う価値があります。インターネットに直接公開しないでください。TLS (transport layer security) を終端し、独自の認証を行うリバースプロキシの背後に配置してください。コマンドランナーは無効にしてください。権限を持たないユーザーとしてコンテナ内で実行し、提供対象のディレクトリだけをコンテナにマウントしてください。

この README には、ほかの記述より重要な行があります。セッションはサーバー側の識別子ではなく、自己完結型の JWTs (JSON web tokens) です。そのため、無効化できません。漏えいしたセッショントークンは、有効期限が切れるまで有効です。パスワードを変更しても無効にはなりません。FileBrowser を使い続ける場合、実際のセキュリティ対策を担うのは、その前段に置いた認証層です。

FileBrowser Quantum: 現在も開発が続くフォーク

開発の中心は FileBrowser Quantum (gtsteffaniak/filebrowser) というフォークに移り、gtstef/filebrowser イメージとして公開されています。従来のコマンドラインフラグとデータベース設定の組み合わせではなく、単一の config.yaml を中心に構成を作り直しています。ドキュメントに記載された簡単な試行方法は次のとおりです。

docker run -d \
  -v $(pwd):/srv \
  -p 80:80 \
  gtstef/filebrowser:beta

これにより、カレントディレクトリが http://localhost で提供されます。初回ログインは admin / admin です。自分のマシン以外からコンテナに到達できる状態にする前に変更してください。

継続して使用するインスタンスでは Compose を使い、単一のデータベースファイルではなくデータ ディレクトリ をマウントし、ポートを localhost にバインドします。

services:
  filebrowser:
    image: gtstef/filebrowser:beta
    user: "1000:1000"
    volumes:
      - /srv/files:/folder
      - ./data:/home/filebrowser/data
    ports:
      - 127.0.0.1:8080:80
    restart: unless-stopped

設定は /home/filebrowser/data/config.yaml に、データベースは /home/filebrowser/data/filebrowser.sqlite に保存されます。バージョン 2.0.0 ではデータベース形式が変更され、1 回限りの移行が実行されます。そのため、ドキュメントではディレクトリのマウントを求めています。単一ファイルのマウントでは、新しいファイルの保存先がないためです。config.yaml 内のパスはコンテナ内のパスです。そのため、設定内のソースは /folder と読み取られ、/srv/files ではありません。これを逆にすると、ディレクトリが実際に存在しないため、エラーが出ないままファイル一覧が空になります。

このプロジェクトでは、動画サムネイル用の FFmpeg を同梱した約 60 MB の latest と stable、コア機能のみを含む約 15 MB の stable-slim が公開されています。これらは 2026 年 8 月時点のインストールページに記載された数値です。選択したタグを固定してください。latest は通知なく変更されるため、実行中のコンテナでファイルマネージャーの設定形式が変わると、運用上の問題になります。

この用途では、小規模なツールの中でも最も機能が充実しています。include ルールと exclude ルールで複数のソースを提供できるため、1 つのインスタンスから /srv/media と /srv/docs を異なる範囲で公開できます。共有には有効期限を設定でき、匿名または特定ユーザーに限定できます。認証は OIDC (OpenID Connect)、LDAP (lightweight directory access protocol)、2 要素認証付きパスワード、プロキシヘッダーモードに対応しています。このプロキシモードにより、セルフホストの Authentik サーバーによるシングルサインオン (SSO) の背後に配置でき、ユーザー一覧を別途管理せずに済みます。

Filestash: 既存のストレージを統合する単一インターフェース

Filestash は異なる構成の製品です。バックエンドに接続するフロントエンドであり、接続先として FTP、SFTP (SSH file transfer protocol)、S3、SMB、WebDAV、IPFS など、約 20 種類以上に対応しています。インターフェースを実行するサーバー上にファイルがない場合に適しています。

mkdir -p /srv/filestash && cd /srv/filestash
curl -O https://downloads.filestash.app/latest/docker-compose.yml
docker compose up -d

イメージは machines/filestash:latest です。http://your_domain:8334 を開くと、最初の画面で admin パスワードを設定できます。すぐに設定してください。設定するまで、ポートを見つけた誰でも admin コンソールにアクセスできるためです。

構築する前に、ID の扱いを理解してください。Filestash は、通常の意味でのユーザーデータベースを保持しません。認証情報は、暗号化、認証済み、HTTP only の cookie としてブラウザーに保存されます。share 機能を使用しない限り、サーバー側には何も保存されません。share 機能を使用すると、Filestash は認証情報の永続的な暗号化版を保持します。「ユーザー」とはストレージアカウントです。ID は Filestash ではなく、SFTP アカウントや S3 key などのバックエンド側に存在します。

この設計はシンプルですが、代償があります。料金ページによると、無料の self-hosted tier は AGPL v3 (GNU Affero General Public License) で、最大 3 ユーザーまでです。SSO (SAML、OIDC、LDAP) と role based access control は、2026 年 8 月時点で月額 $50 からの有料 self-hosted tier に含まれます。「会社の SSO の前段に Filestash を無料で置く」という計画であれば、このページを確認してから設計してください。

SFTPGo: Web インターフェースも備えたプロトコルサーバー

SFTPGo は、この中で最も高機能なソフトウェアです。ただし、推奨される理由を誤解されることが最も多い製品でもあります。ローカルファイルシステム、暗号化されたローカルファイルシステム、S3 互換オブジェクトストレージ、Google Cloud Storage、Azure Blob Storage、または別の SFTP サーバーをバックエンドとして、SFTP、HTTP/S、FTP/S、WebDAV を提供します。

バイナリ、Debian および Ubuntu パッケージ、コンテナイメージが公開されています。現在の APT リポジトリ行と署名キーは、SFTPGo ドキュメントのインストールページに記載されています。コンテナを使う方法が、最も早く起動する手段です。tag を必要なバージョンに置き換えて実行します。

docker run --name some-sftpgo -p 8080:8080 -p 2022:2022 -d "drakkan/sftpgo:tag"

SFTP は 2022 で待ち受け、Web インターフェースは 8080 で待ち受けます。/srv/sftpgo をボリュームとしてマウントしてください。ユーザーアカウントとそのファイルは、コンテナを再作成すると消失します。ユーザーのホームディレクトリは、デフォルトで /srv/sftpgo/data/<username> に作成されるためです。

Web インターフェースは 2 つあります。両者の違いは、多くの解説で暗黙のままにされている重要な点です。/web/admin の WebAdmin は管理用です。ここでユーザー、グループ、仮想フォルダー、イベントルールを作成し、クォータ、帯域幅制限、アクセス可能時間を設定します。/web/client の WebClient はエンドユーザー向けの画面です。ユーザーはここでファイルを参照し、自分の認証情報を変更し、2 要素認証を設定し、共有を作成します。

この共有機能は、この比較で最も優れています。ユーザーはファイルやフォルダーを共有する HTTP/S リンクを作成できます。ダウンロード数とアップロード数を制限し、パスワードで共有を保護し、送信元 IP アドレスでアクセスを制限し、自動的な有効期限を設定できます。

では、なぜ注意が必要なのでしょうか。中心となるのはファイル参照機能ではなく、アカウントモデルとプロトコルサーバーです。他のユーザーにクォータ付きの実アカウントが必要な場合、管理下にないシステムから SFTP または FTPS でアップロードを受け付ける場合、または 1 つのバケットを複数ユーザーのホームディレクトリ内に表示する場合は、SFTPGo を選択してください。最後の用途には仮想フォルダーを使います。ローカルディスク、S3、GCS、Azure Blob、SFTP、HTTP のいずれかをバックエンドとするフォルダーを、複数のアカウントにマウントできます。共有フォルダーに対して、ユーザーごとに個別のクォータも設定できます。/srv/files を参照できるページだけが必要なら、これは過剰な構成です。

さらに 2 点、確認しておく価値があります。Community エディションは追加条項付きの AGPL-3.0-only で、商用ライセンスの Enterprise エディションもあります。オープンソース版には OIDC ログインが含まれており、両方の Web インターフェースで、IdP のユーザーを SFTPGo の管理者およびユーザーに割り当てられます。httpd 設定の enable_web_client を使えば、クライアントインターフェースを全体で無効にできます。ユーザーごとに無効にする場合は、そのユーザーの拒否プロトコルに HTTP を追加します。これにより、ファイルマネージャーを 1 人だけに提供し、他のユーザーには提供しない構成も可能です。

Cloud Commander: 2 ペインとターミナルを 1 人で使用

Cloud Commander は、2 ペイン形式の MIT ライセンスの Node.js ファイルマネージャーです。組み込みエディター、コンソール、ターミナルを備えています。npm i cloudcmd -g でグローバルにインストールするか、公開済みのコンテナを実行します。

docker run -it --rm -v ~:/root -v /:/mnt/fs -w=/root -p 8000:8000 coderaiser/cloudcmd

実行する前に、このコマンドを確認してください。-v /:/mnt/fs はホストのファイルシステム全体をコンテナにマウントします。また、サンプルの ~/.cloudcmd.json には "root": "/"、"auth": false、"console": true が含まれています。この組み合わせでは、port 8000 に到達できる人がサーバー上のディスク全体とコマンドコンソールを利用できます。ノート PC では妥当な既定値ですが、VPS には適していません。

対象範囲を絞ります。コンテナは /root/.cloudcmd.json を読み取ります。公開されているコマンドでは、home directory をマウントしてこのファイルを指定しています。そのため、config のマウントだけを残し、それ以外を削除します。

docker run -d --name cloudcmd \
  -v ~/.cloudcmd.json:/root/.cloudcmd.json \
  -v /srv/files:/srv/files \
  -w=/srv/files \
  -p 127.0.0.1:8000:8000 \
  coderaiser/cloudcmd

その config file で、"root" を /srv/files に設定し、"auth" を true に設定します。その際、"username" と "password" を使用します。ブラウザーからの shell access が本当に必要でない限り、"console" と "terminal" は false に設定してください。コマンドラインで同等の設定を行う方法もあり、--root、--auth、--username、--password、--prefix などを使用できます。

このツールの性質を正しく理解してください。認証情報の組み合わせは 1 つだけで、ユーザーごとのアクセス範囲設定、quota、share link はありません。個人用ツールなので、上記のとおり localhost に bind し、tunnel 経由で接続してください。

ssh -L 8000:127.0.0.1:8000 you@your-vps

次に、自分のマシンで http://127.0.0.1:8000 を開きます。file manager は公開されず、インターネットに公開されるのは、すでに VPS でセキュリティ強化した SSH daemon だけです。

この用途には Nextcloud が適さない理由

Nextcloud は優れたソフトウェアですが、この用途には適していません。Nextcloud は、PHP アプリケーション、データベース、バックグラウンドジョブ、デスクトップ同期クライアント、アプリストアで構成されるコラボレーションプラットフォームです。/srv/files を Web で表示するために導入するには、小規模な用途に対して構成要素が多すぎます。さらに、用途との間に明確な不一致があります。Nextcloud は各リクエストでディレクトリを読み取るのではなく、ファイルのメタデータをデータベースのテーブルに保持します。そのため、rsync や cron ジョブで書き込まれたファイルは、スキャンが追いつくまでインターフェースに表示されないことがあり、sudo -u www-data php occ files:scan --all となります。ファイルマネージャーはページを読み込むときにディレクトリを一覧表示するため、このずれは発生しません。

Nextcloud は、カレンダー、連絡先、同期、デスクトップクライアントを必要とするユーザーとの共有など、得意な用途に使ってください。Docker、TLS、バックアップを使用した VPS 上の Nextcloud では、その構成を説明しています。すでに Nextcloud を運用していて、既存のディレクトリを表示するだけであれば、External Storage アプリを有効にして、それ以上の構成は行わないでください。同じディスクへの書き込み権限を持つ Web アプリケーションを追加すると、パッチを適用する対象も 1 つ増えます。

サーバー全体を公開せずに実行する方法

/を指定してはいけません。プロセスは、そのユーザーアカウントからアクセスできるすべての内容を読み書きできます。そのため、セッション トークンを盗まれると、それだけのファイルシステムへのアクセス権を奪われます。1 つのディレクトリだけを提供するために /srv/files を指定し、その用途専用に作成します。

root 以外のユーザーで実行し、提供対象だけをマウントします。Compose では user: "1000:1000" に加えて、ディレクトリごとに 1 つの bind mount を指定します。書き込みが不要な対象には :ro を指定します。

    volumes:
      - /srv/files:/folder
      - /srv/media:/media:ro

通常、この変更後は閲覧できる一方、アップロードは permission denied で失敗します。これは、コンテナ内のユーザー ID がコンテナ外のディレクトリの所有者ではないためです。2 つの環境を比較します。docker exec filebrowser id はコンテナ内のユーザーを表示し、ls -ln /srv/files はホスト上の数値形式の所有者を表示します。sudo chown -R 1000:1000 /srv/files で修正します。これは、Docker イメージの PUID と PGID が解決する所有権の問題と同じです。

公開ポートは 8080:80 ではなく localhost の 127.0.0.1:8080:80 にバインドします。Docker は ufw より先に独自の netfilter ルールを書き込むため、ufw deny 8080 が有効でも、通常どおり公開したポートはインターネットから到達可能なままです。TLS のために前段へリバースプロキシを置きます。平文の HTTP ではセッション Cookie がネットワーク上をそのまま通過し、その Cookie がファイルシステムへのアクセス権になります。Compose 自体に不慣れな場合は、VPS 上の Docker Compose で、これらの例が前提とするファイル構成を確認できます。

アプリケーション独自の認証機能が不十分な場合は、認証層を追加します。単一ユーザーのインスタンスであれば、プロキシでの HTTP basic auth で十分です。複数人が利用する場合は、OIDC または identity provider に対する forward auth を使用します。これにより、1 つのアカウントを無効化すると、すべての場所でアクセスを取り消せます。

余分な機能を無効にします。シェル、コマンド実行機能、またはブラウザー内ターミナルを提供するファイルマネージャーは、有効なセッションを持つユーザーにリモートコード実行機能を提供することになります。FileBrowser 自身のガイダンスでは command runner を無効にするよう推奨しており、Cloud Commander のサンプル設定では console が有効になっています。デフォルトのままにせず、目的を明確にして判断してください。

最初に問題になる箇所と、表示されるエラー

listen tcp :80: bind: permission denied. Linux では、1024 未満のポートを特権プロセス用に予約しています。FileBrowser Quantum のドキュメントにある設定ではポート 80 を使用します。これはコンテナ内では問題ありませんが、ホスト上でバイナリを非特権ユーザーとして実行すると失敗します。config.yaml では 1024 より大きいポートを指定し、443 はプロキシに処理させます。

アップロードは失敗するが、参照はできる。 ディレクトリの一覧表示には r-x が必要で、書き込みには w が必要です。Web インターフェイスは汎用的なエラーを表示するため、最初にアプリケーションのログではなくファイルシステムを確認します。

413 Request Entity Too Large. このエラーはファイルマネージャーではなく nginx が出しています。デフォルトの client_max_body_size は 1 MB であるため、それを超えるアップロードはアプリケーションに届く前にプロキシで拒否されます。server ブロックで client_max_body_size 4096m; を設定するか、0 でチェックを無効にします。

アップロードしたファイルのグループが正しくない。 新しいファイルは、親ディレクトリの設定に関係なく、プロセスのユーザーが所有します。そのため、同じツリーを読み取る別のサービスで問題が発生します。両方のサービスに共有グループを割り当て、sudo chmod g+s /srv/files でディレクトリに setgid ビットを設定します。これにより、新しいファイルがディレクトリのグループを継承します。

ポート上では動作するが、プロキシ経由では動作しない。 サブパスで提供されるアプリケーションは、あらかじめ通知されたプレフィックスを基にリンクを生成します。Cloud Commander にはこのための --prefix があります。そのようなオプションがない場合は、アプリケーション専用のサブドメインを割り当て、ルートパスをプロキシします。

どのセルフホスト型ファイルマネージャーを運用すべきか

• 1 台の VPS で 1 つまたは 2 つのディレクトリを扱い、有効期限付きの共有リンクを発行し、将来的に SSO も導入する可能性がある場合: FileBrowser Quantum。
• ファイルが別の場所にあり、S3 バケット、SFTP ホスト、または SMB 経由の NAS を横断して 1 つの Web 画面で表示したい場合: 無料プランの制限内で Filestash。
• 他のユーザーにアカウント、クォータ、SFTP または FTPS 経由のアップロードが必要な場合: SFTPGo。Web クライアントは選定理由ではなく、便利な追加機能として扱います。
• エディターとターミナルを備え、SSH トンネル経由でアクセスし、外部公開しない個人用ツールが必要な場合: Cloud Commander。
• Nextcloud がすでに稼働していて、公開したい既存のディレクトリがある場合: External Storage アプリ。新しいソフトウェアは一切導入しません。

どれを選ぶかよりも、デプロイ方法が重要です。ディレクトリは 1 つに限定し、root 以外のユーザーで実行し、ポートは localhost にバインドし、前段に認証を置きます。この構成のファイルマネージャーは便利なツールです。同じソフトウェアを / に向け、共有パスワードを設定すると、見栄えのよいインターフェースを備えたリモートシェルになります。

FAQ

FileBrowser は 2026 年時点でも安全に実行できますか？

上流の filebrowser/filebrowser README には、File Browser が 2026-09-01 にアーカイブされ、それ以降のリリース、バグ修正、セキュリティ修正が行われないと記載されています。コード自体は引き続き動作しますが、ファイルシステムへの書き込み権限を持つ未修正のソフトウェアは、時間の経過とともにリスクが高まります。使い続ける場合は、プロジェクト自身の推奨に従ってください。インターネットへ直接公開せず、TLS と独自の認証を行うリバースプロキシを前段に置き、コマンドランナーは無効のままにし、提供対象のディレクトリだけをマウントした非特権コンテナで実行します。また、セッションはサーバー側の識別子ではなく自己完結型の JWT であるため、失効させられません。変更後のパスワードでも、発行済みのトークンは無効になりません。新規に導入する場合は、開発が継続している FileBrowser Quantum fork を使用してください。これは gtstef/filebrowser image として公開されています。

セルフホストのファイルマネージャーで既存の SSO を使用できますか？

FileBrowser Quantum は OIDC、LDAP、プロキシヘッダーモードをサポートしているため、ユーザーリストを別に持たずに既存の identity provider の背後へ配置できます。SFTPGo の OpenID Connect 統合は open source build に含まれており、WebAdmin と WebClient の両方で identity provider のユーザーを SFTPGo の管理者およびユーザーに対応付けます。注意が必要なのは Filestash です。2026 年 8 月時点で、料金ページでは SSO（SAML、OIDC、LDAP）が月額 $50 からの有料 self-hosted tier に含まれています。一方、free tier は AGPL v3、最大 3 ユーザーと記載されています。アプリケーションが SSO をまったくサポートしていない場合は、リバースプロキシで forward authentication を使用するのが代替策です。これによりログインページは保護できますが、アプリケーション内部の権限は変更されません。

期限切れになる共有リンクを提供するのはどれですか？

最も完全な実装を備えているのは SFTPGo です。ユーザーは WebClient から HTTP/S リンクを作成し、ダウンロード数とアップロード数を制限したり、パスワードを設定したり、送信元 IP アドレスでアクセスを制限したり、自動有効期限を設定したりできます。FileBrowser Quantum は有効期限付きの共有をサポートしており、匿名アクセスまたは特定ユーザーに限定したアクセスを選択できます。共有ごとに、表示、編集、アップロードの権限も設定できます。Filestash にも共有機能があります。ここでは、ブラウザーのセッションが終了してもリンクを機能させる必要があるため、サーバーがストレージ認証情報の暗号化された永続コピーを保持する点が異なります。Cloud Commander には共有リンクがありません。

自分しか利用しない場合、ファイルマネージャーを / に向けても安全ですか？

いいえ。リスクは、自分自身を信頼できるかどうかにあるわけではありません。プロセスは、そのユーザーアカウントがアクセスできるすべての対象に対して読み取りおよび書き込み権限を持ちます。そのため、そのセッションに到達する経路、盗まれた cookie、upload handler の未修正のバグ、再利用されたパスワードのいずれかが、/etc、SSH keys、すべてのサービスのデータディレクトリへのアクセスにつながります。マウント範囲は 1 つのディレクトリに限定してください。/ ではなく /srv/files を使用します。Cloud Commander では、この問題が特に深刻です。公開されている Docker コマンドはホストの root を /mnt/fs にマウントし、サンプル設定では "root": "/" に "auth": false を設定しています。このコンテナが localhost 以外で待ち受ける前に、両方を変更してください。