Nextcloud Dockerのファイル保存場所とバックアップ先

Where Nextcloud in Docker stores files

Nextcloud in Docker stores files in a data directory inside the container, and the real location on your server is whichever volume or bind mount you attached to it. With the linuxserver.io image, lscr.io/linuxserver/nextcloud, user files live in /data, and the Nextcloud installation with its config.php lives in /config. Both of those are container paths. One command prints the host path behind them, and the rest of this guide covers the harder half of the question: everything the data directory does not hold.

Pin the image tag. Paths belong to an image rather than to Nextcloud, and a floating tag can move under you. As of August 2026 the current stable tag for this image is 34.0.3.

services:
  nextcloud:
    image: lscr.io/linuxserver/nextcloud:34.0.3
    container_name: nextcloud
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Etc/UTC
    volumes:
      - nextcloud_config:/config
      - nextcloud_data:/data
    ports:
      - 443:443
    restart: unless-stopped

  nextcloud-db:
    image: mariadb:11.8
    container_name: nextcloud-db
    environment:
      - MARIADB_ROOT_PASSWORD=${MARIADB_ROOT_PASSWORD}
      - MARIADB_DATABASE=nextcloud
      - MARIADB_USER=nextcloud
      - MARIADB_PASSWORD=${NEXTCLOUD_DB_PASSWORD}
    volumes:
      - nextcloud_db:/var/lib/mysql
    restart: unless-stopped

volumes:
  nextcloud_config:
  nextcloud_data:
  nextcloud_db:

The two passwords come from a .env file next to the compose file, so they stay out of the compose file itself. That is three volumes in the answer, and only one of them holds user files.

Those container paths come from the documentation for that one image. A different Nextcloud image lays out its filesystem differently and keeps the installation under its own web root, so a path copied from a forum post is a guess. Read the truth from the container you are running.

docker inspect nextcloud

The Mounts section of that output lists every mount, with Source on the host side and Destination on the container side. That listing answers the question for your setup, whichever image you chose.

ボリュームの実際のホストパスを確認するにはどうすればよいですか？

名前付きボリュームは Docker が管理するため、パスを自分で選ぶことはできません。パスを確認します。

docker volume ls
docker volume inspect nextcloud_nextcloud_data

名前が重要です。Docker Compose はボリューム名にプロジェクト名を付けます。プロジェクト名の既定値は、compose ファイルを置いたディレクトリ名です。そのため、ファイル内で nextcloud_data と記述したボリュームは、通常、ディスク上では nextcloud_nextcloud_data として存在します。docker volume ls で実際の名前を確認できます。inspect の出力は、抜粋すると次のようになります。

[
    {
        "CreatedAt": "2026-08-18T09:12:44Z",
        "Driver": "local",
        "Mountpoint": "/var/lib/docker/volumes/nextcloud_nextcloud_data/_data",
        "Name": "nextcloud_nextcloud_data",
        "Scope": "local"
    }
]

Mountpoint が答えです。パスは推測せず、コマンドの出力から読み取ってください。パスは変わる可能性があります。rootless Docker では、Docker のデータルート全体がデーモンを実行するユーザーのホームディレクトリ内に置かれます。そのため、パスの起点が異なります。

bind mount を使えば、この確認は不要です。compose ファイルに - /srv/nextcloud/data:/data と記述すると、ホストパスは入力したパスになります。docker inspect では、そのパスが Source として報告されます。選択によって変わるのはパスだけではありません。名前付きボリュームと bind mount では、所有権とバックアップの扱いも異なります。

データディレクトリだけではバックアップにならない理由

Nextcloud のマニュアルでは、バックアップに保持する必要があるものとして、config フォルダー、custom apps フォルダー、data フォルダー、theme フォルダー、データベースの5つを挙げています。このイメージでは、config、apps、theme フォルダーはすべて /config 以下にあり、データベースは専用のコンテナで独自のボリュームを使用します。/data だけをコピーしても、問題の中で重要度が最も低い部分しか保存できません。

データベースが重要なのは、Web インターフェースがディレクトリを一覧表示しているのではないためです。表示しているのは file cache の行です。そのため、マニュアルでは data ディレクトリに手動でファイルをコピーした後、scan を実行するよう説明しています。空のデータベースの隣に /data を復元すると、インデックスのないバイト列だけが残ります。ユーザー、共有、ファイル一覧の項目は何もありません。空の /data の隣にデータベースを復元すると、すべての行が存在しないファイルを指します。

config.php にはデータベースの認証情報と trusted domains が保存されています。instance id も保存されています。これは data ディレクトリ内にある app data フォルダーの名前です。どちらの値も記憶に頼らず、実行中のインスタンスに確認してください。

docker exec -it nextcloud occ config:system:get datadirectory
docker exec -it nextcloud occ config:system:get instanceid

最初のコマンドは、このインスタンスが実際に使用している data ディレクトリを表示します。ここでは /data です。このイメージには occ wrapper が PATH 上に含まれているため、docker exec を通して直接実行します。コンテナ外のインストールを前提とした Nextcloud マニュアルの、より長い sudo と php occ の形式をそのままコピーしないでください。

データボリュームをひそかに圧迫しているものは何ですか？

プレビューとユーザーごとの履歴はファイルと同じボリュームに保存されますが、Web インターフェースでユーザーに表示されるストレージ使用量には、どちらも反映されません。

• プレビューは生成されたサムネイルです。data ディレクトリ内のアプリデータフォルダーに保存され、appdata_ の後ろにインスタンス ID が続く名前になります。
• 削除したファイルはごみ箱に残ります。trashbin_retention_obligation のデフォルト値は auto です。この設定ではファイルを 30 日間保持し、その後も容量が必要になった場合にだけ削除します。削除したファイルもユーザーのクォータに算入されます。クォータを超えると保持設定は無視され、クォータ内に収まるまでごみ箱が削減されます。
• 古いバージョンも残ります。versions_retention_obligation のデフォルト値も auto です。Versions アプリが使用する容量は、ユーザーが現在利用できる空き容量の 50% を超えません。削減時には最も古いバージョンから削除し、最新の 2 つは保持します。ユーザーが手動で名前を付けたバージョンは削除されません。

削除する前に測定してください。

docker exec -it nextcloud sh -c 'du -sh /data/*'
docker exec -it nextcloud sh -c 'du -sh /data/appdata_*'

最初の行には、各ユーザーフォルダーとアプリデータフォルダーの容量が 1 つずつ表示されます。アプリデータの容量が大きい場合は、プレビューが原因です。以下のクリーンアップコマンドは文書化されたものですが、いずれも意図的にデータを破壊します。

docker exec -it nextcloud occ trashbin:cleanup --all-users
docker exec -it nextcloud occ versions:cleanup alice
docker exec -it nextcloud occ preview:cleanup

preview:cleanup は生成済みのプレビューをすべて削除します。ユーザーがファイルを開くと Nextcloud が再生成するため、空いた容量は徐々に再び使用され、CPU 負荷も発生します。ボリュームの問題がディスク全体の問題の一部にすぎない場合は、古いイメージと残存したビルドキャッシュ も通常は原因になります。

ホストにコピーしたファイルがNextcloudに表示されないのはなぜですか？

Nextcloudはディレクトリではなく、データベース内のファイルキャッシュを読み取るためです。コピーによって、対応する行がないファイルがディスク上に作成されました。そのため、Webインターフェースには一覧表示する情報がありません。マニュアルにもこのケースが明記されています。データディレクトリへファイルを直接コピーした後は、scanが必要です。

docker exec -it nextcloud occ files:scan --path="/alice/files/Photos"
docker exec -it nextcloud occ files:scan --unscanned -v
docker exec -it nextcloud occ files:scan --all

--path引数を使うと、データディレクトリ内の構成も確認できます。各ユーザーにはユーザー名と同じ名前のフォルダーがあり、その中のfilesに、Webインターフェースで表示されるファイルが格納されています。ファイルのコピー先が分かっている場合は、1 つのパスだけをscanします。--allはすべてのユーザーを処理するため、大規模なインスタンスでは時間がかかります。--unscannedは、まだ完全にscanされていないとマークされたファイルだけを処理します。-vは処理中の各ファイルを表示します。これにより、停止したように見えるコマンドと、処理状況を確認できるコマンドを区別できます。

所有者も、scanだけで十分かどうかを左右します。コンテナのユーザーが書き込めないファイルはインデックス化されても移動できません。そのため、一覧は正しく表示されても、Webインターフェースからの名前変更や削除は失敗します。

PUID と PGID を設定した後も書き込みに失敗するのはなぜですか？

kernel は名前ではなく数値を比較するためです。PUID と PGID は、コンテナのプロセスが使用する数値のユーザー ID (uid) とグループ ID (gid) を設定します。ホスト上のすべてのファイルにも、数値の所有者が設定されています。2 つの数値が異なると、両側で表示される名前が同じように見えても、書き込みは拒否されます。

docker exec -it nextcloud id abc
sudo ls -ln /var/lib/docker/volumes/nextcloud_nextcloud_data/_data

id abc は、コンテナが実際に使用している uid と gid を表示します。これは設定した PUID と PGID です。ls -ln は数値の所有者を表示します。ここで重要なのは -n です。通常の ls -l は、ホスト独自のユーザー一覧を使って数値を名前に変換します。その名前はコンテナ内では意味を持ちません。2 つの数値を比較してください。

推測せず、実際に書き込みをテストします。

docker exec -u abc -it nextcloud touch /data/writetest

Permission denied を /data に指定して実行することが確認になります。コンテナ内から所有者を修正し、同じテストをもう一度実行してください。

docker exec -u 0 -it nextcloud chown -R abc:abc /data
docker exec -u abc -it nextcloud touch /data/writetest
docker exec -u abc -it nextcloud rm /data/writetest

コンテナ内から実行するのには理由があります。rootless Docker では、コンテナのユーザー ID が /etc/subuid の subordinate range を介してマッピングされます。そのため、コンテナ内の uid 1000 は、ホスト上ではさらに大きな uid に対応します。ホスト側で chown 1000:1000 を実行すると、コンテナが使用できない所有者が設定され、書き込みは引き続き失敗します。コンテナ内で chown を実行すると、Nextcloud プロセス自身が使用するものと同じマッピングが適用されるため、数値が確実に一致します。このため、他の問題を調査する前に、PUID と PGID をディスク上の所有者に一致させる必要があります。

実際に復元できるようにバックアップするには

データベースとディレクトリは、同じ時点のものを取得します。メンテナンスモードにするとログインが停止するため、ダンプ取得とコピーの間にアップロードが行われません。

docker exec -it nextcloud occ maintenance:mode --on
docker exec nextcloud-db mariadb-dump --single-transaction -u nextcloud -p"$NEXTCLOUD_DB_PASSWORD" nextcloud > nextcloud-sqlbkp.sql
docker run --rm -v nextcloud_nextcloud_data:/data:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-data.tgz -C /data .
docker run --rm -v nextcloud_nextcloud_config:/config:ro -v "$PWD":/backup alpine:3.22 tar czf /backup/nextcloud-config.tgz -C /config .
docker exec -it nextcloud occ maintenance:mode --off

ダンプの行にないものを確認してください。-tフラグがありません。TTY を経由すると改行コードが書き換えられます。TTY を経由した SQL ダンプは、復元時になるまで気付けない形で破損します。また、コマンドラインでパスワードを指定すると、コマンドの実行中に ps の出力から見えてしまいます。そのため、入力せずに .env ファイルから読み込み、シェルに渡します。古いデータベースイメージでは mariadb-dump の代わりに mysqldump が提供されます。マニュアルには両方の指定方法が記載されています。

復元するには、空のデータベースにダンプを読み込み、2 つのアーカイブを新しいボリュームに展開してからコンテナを起動します。その後、メンテナンスモードを解除します。ディレクトリとダンプの取得時点が異なると、ファイルキャッシュとディスクの内容が一致しません。occ files:scan --all で修復できるのは一方向だけです。ファイルは存在するものの対応する行がない状態は検出できます。行が参照するファイルを復元することはできません。

復元結果はサーバーの外部に保管します。同じ VPS 内にあるコピーは、その VPS とともに失われます。そのため、この手順には サーバー外のリポジトリへの restic バックアップを組み込みます。また、プロバイダーのスナップショットはバックアップとは別のツールです。まだスタックを構築中であれば、VPS への Nextcloud の完全なインストールで、このガイドでは扱わないリバースプロキシと TLS (transport layer security) 証明書を設定できます。

FAQ

Nextcloud のデータディレクトリは Docker コンテナ内のどこにありますか？

linuxserver.io のイメージでは、コンテナ内のデータディレクトリは /data にあり、config.php によるインストールは /config 以下にあります。これらはコンテナ内のパスです。ホスト側のパスを確認するには、docker inspect nextcloud を実行して Mounts セクションの Source の値を読み取るか、ボリュームに対して docker volume inspect を実行して Mountpoint を読み取ります。ほかの Nextcloud イメージではコンテナ内のパスが異なるため、固定した tag のドキュメントを確認し、docker exec -it nextcloud occ config:system:get datadirectory で確かめてください。

ボリュームにコピーしたファイルが Nextcloud に表示されないのはなぜですか？

Nextcloud はディレクトリを直接読み取らず、データベースの file cache から一覧を作成します。そのため、Nextcloud を経由せずに追加されたファイルには行がなく、表示されません。1 つのフォルダーだけを対象にする場合は docker exec -it nextcloud occ files:scan --path="/alice/files/Photos" を実行し、すべてのユーザーを対象にする場合は occ files:scan --all を実行します。ファイルは表示されるものの、移動や削除ができない場合は、所有者が原因です。コンテナのユーザーがそのファイルへ書き込める必要があります。

データボリュームのコピーだけで Nextcloud を復元できますか？

いいえ。データボリュームにはファイルの内容が保存されています。データベースにはファイルインデックス、ユーザー、共有情報が保存され、config.php にはデータベースの認証情報と instance id が保存されています。正常に復元するには、データフォルダー、config フォルダー、データベース、さらに使用している場合はカスタムアプリとテーマのフォルダーが必要です。これらはすべて同じ時点のものを取得してください。データベースのほうがファイルより新しいと、存在しないファイルを参照することになるためです。

データボリュームがユーザーに表示されるファイルより大幅に大きいのはなぜですか？

プレビュー、削除済みファイル、古いバージョンは同じボリュームに保存されますが、ユーザーに表示される容量には含まれません。docker exec -it nextcloud sh -c 'du -sh /data/*' で使用量を確認します。ごみ箱はデフォルトで削除済みファイルを 30 日間保持し、空き容量が必要になった場合にだけ早く削除します。また、Versions アプリは、ユーザーが現在使用できる空き容量の最大半分を使うことがあります。occ trashbin:cleanup --all-users、occ versions:cleanup alice、occ preview:cleanup でそれぞれ削除してください。ユーザーがファイルを開くと、プレビューは再び増える可能性があります。

Nextcloud のデータディレクトリを別のディスクへ移動できますか？

Nextcloud が認識しているパスを変更せず、新しい場所を同じコンテナ内パスにマウントします。コンテナを停止し、所有権を維持したまま（cp -a または rsync -aAX）古い内容を新しいディスクへコピーします。次に、compose ファイルで volume または bind mount の参照先を新しい場所に変更し、コンテナを再起動します。Nextcloud からは引き続き /data に見えるため、データベースの行を変更する必要はありません。docker exec -it nextcloud occ config:system:get datadirectory とテスト用のアップロードで確認してください。