NEW ARTICLE
Laravel『View [name] Not Found』の原因と対処法
  1. HOME
  2. その他
  3. docker『Failed to Mount Volume』の原因と対処法

docker『Failed to Mount Volume』の原因と対処法

docker『Failed to Mount Volume』の原因と対処法

コンテナ起動時に「Failed to Mount Volume」や「failed to mount local volume」「error while mounting volume」などのエラーが出る場合、ホスト側のディレクトリが存在しない・権限不足・パスの指定ミス・ドライバやリモートストレージの設定不備などが主な原因になる。bind mount（ホストパス）、named volume、NFS など種類ごとにチェックポイントが異なるため、「どのタイプのボリュームを、どのパスに、どんなオプションで」マウントしようとしたのかを整理して原因を絞り込む。

目次

エラーの意味と代表的な発生条件

「Failed to Mount Volume」に相当するメッセージは次のような形で出ることが多い。

Error response from daemon:
  failed to mount local volume: mount /host/path:/container/path: 
  failed: no such file or directory

Error while mounting volume '/var/lib/docker/...':
  failed to mount local volume: permission denied

failed to initialize logging driver: failed to mount volume ...

発生条件としてよくあるパターン：

  • ホストパス（bind mount）のディレクトリやファイルが存在しない
  • ホスト側の権限や SELinux によってアクセスが拒否されている
  • docker-compose.yml の volumes 記述ミス（書式・キー名・インデント）
  • named volume の driver / driver_opts 設定が間違っている
  • NFS / CIFS などのリモートストレージの接続先がダウン・設定不備
  • Windows / Mac の Docker Desktop でホストディレクトリへの共有設定が許可されていない

bind mount（ホストパス）の存在確認とパス指定ミス

ホストパスをそのままマウントする bind mount は最も単純な仕組みだが、それだけに「パスが存在しない」「パスの書き方が違う」でこけやすい。

# 例: bind mount
docker run -v /host/data:/app/data my-image

チェックポイント：

  • /host/data がホスト上に存在するか
  • ファイルなのかディレクトリなのか（コンテナ側と整合しているか）
  • 相対パスになっていないか（コンテナ起動時のカレントディレクトリに依存してしまう）

ホスト側で存在確認：

ls -ld /host/data
# もし存在しなければ作成
mkdir -p /host/data
[/code]
docker-compose.yml の場合も同様で、左側（ホストパス）の typo でよく失敗する。  
[code]
# docker-compose.yml の例
services:
  app:
    image: my-image
    volumes:
      - /host/data:/app/data   # 左側がホストパス

docker-compose.yml の場合も同様で、左側（ホストパス）の typo でよく失敗する。

# ホスト側で権限確認
ls -ld /host/data

# 例: rootだけがアクセス可能
drwx------ 2 root root 4096 ...

権限不足・SELinux による「Failed to Mount Volume」

ディレクトリは存在していても、権限不足でマウントできないケースも多い。特に /root 配下や他ユーザー所有のディレクトリをマウントする場合。

sudo chown -R $(whoami):$(whoami) /host/data
sudo chmod 755 /host/data

対処パターン：

  • 所有権やパーミッションを調整する
# コンテナ内アプリが UID=1000 で動いているなら…
sudo chown -R 1000:1000 /host/data

コンテナ側ユーザー（UID/GID）に合わせて所有権を変更する

# SELinuxコンテキストを自動調整する例
docker run -v /host/data:/app/data:Z my-image

SELinux が有効な環境（CentOS / RHEL / Fedora など）では、Z / z オプションが必要になることもある。

# SELinuxコンテキストを自動調整する例
docker run -v /host/data:/app/data:Z my-image

エラー例に「permission denied」「operation not permitted」「SELinux」などが含まれている場合は、まず権限と SELinux コンテキストを疑う。

named volume と local ドライバの設定ミス

named volume（docker が管理するボリューム）自体は、通常はディレクトリが自動作成されるため、パス存在問題を引き起こしにくい。ただし driver_opts を使ってローカルディレクトリを指定する場合は別。

# docker-compose.yml の例
services:
  app:
    image: my-image
    volumes:
      - appdata:/app/data

volumes:
  appdata:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /host/data

よくあるミス：

  • device で指定した /host/data が存在しない
  • type / o の値が間違っている
    チェック方法：
# ボリューム定義を確認
docker volume inspect appdata

device のパスが正しいか、type が none / nfs / cifs など意図通りになっているかを確認し、必要ならディレクトリを作成・修正する。

docker-compose.yml の書式ミスやパス解釈の違い

docker-compose.yml の volumes セクションは、「ホストパス:コンテナパス」なのか「named volume:コンテナパス」なのかで挙動が変わる。書き方を間違えると、存在しない named volume をホストパスだと思い込んでマウントを試みたり、その逆になったりする。

# NG例: 実はホストパスのつもりが named volume と解釈される
services:
  app:
    image: my-image
    volumes:
      - data:/app/data   # data が相対パスにも見える

# OK: 明示的にホストパスを指定
services:
  app:
    image: my-image
    volumes:
      - ./data:/app/data

さらに、インデントミスや YAML の書き方ミスでも意図しない volume 定義になる。compose の解釈結果は config コマンドで確認できる。

# compose が解釈した結果を確認
docker compose config

ここで volumes のセクションが期待通りになっているかを確認してから起動すると、ミスに気付きやすい。

リモートボリューム（NFS / CIFS / クラウドドライバ）の接続エラー

NFS や CIFS、各種プラグイン（aws efs、gluster、RBD など）を使ったボリュームは、リモート側の状態やネットワークにも依存するため、「Failed to Mount Volume」が出やすい領域。
NFS の例：

volumes:
  nfsdata:
    driver: local
    driver_opts:
      type: nfs
      o: addr=10.0.0.10,nolock,soft
      device: ":/export/data"

この場合のチェックポイント：

  • NFS サーバ 10.0.0.10 が起動しているか
  • /export/data がエクスポートされているか（showmount -e）
  • FW / セキュリティグループで NFS ポートが開いているか
  • driver_opts の書式・パラメータに typo が無いか
    同様に CIFS/SMB の場合は、ユーザー名・パスワード・ドメイン・オプション（vers=3.0 など）が正しいかを確認する。

Windows / Mac の Docker Desktop でのホストディレクトリ共有設定

Windows や Mac の Docker Desktop では、ホストのディスクドライブを WSL2 / VM に共有する仕組みになっており、「共有が許可されていないパス」をマウントしようとすると失敗する。
例：

docker run -v C:\work\data:/app/data my-image

チェックポイント：

  • Docker Desktop の設定で C ドライブ / 特定フォルダの共有を有効にしているか
  • パスの指定形式（Windows パス vs WSLパス）を混同していないか
    WSL2 ベースの場合は、/mnt/c/work/data のような WSL パスで指定するパターンもある。
# WSL2 シェル内から実行する例
docker run -v /mnt/c/work/data:/app/data my-image

「Failed to Mount Volume」が出たとき、Docker Desktop のログ・設定画面も合わせて確認する。

コンテナ再起動時のボリューム衝突・古いマウント状態の残存

コンテナを何度も再起動したり、同じボリューム名・パスを使い回していると、古いマウント状態や半端なボリューム定義が残って衝突することがある。
対処パターン：

  • コンテナを完全に削除してから再起動
docker compose down
docker compose up -d

不要なボリュームを prune

docker volume ls
docker volume rm <volume_name>

# 一括で掃除（要注意）
docker volume prune
  • ログメッセージに「already mounted」「busy」などが含まれていれば、ホスト側でマウント状態の確認・解除を行う
mount | grep data
# 必要に応じて umount
sudo umount /host/data

トラブルシューティング用コマンド集（原因切り分けの順番）

ボリューム周りのエラーを切り分けるために、次のようなコマンドを順に使うと原因を見つけやすい。

# 1) ホストパスの存在・権限を確認
ls -ld /host/data
stat /host/data

# 2) ボリューム定義の確認
docker volume ls
docker volume inspect appdata

# 3) compose 解釈結果の確認
docker compose config

# 4) NFS/CIFSなどリモート先の疎通
ping -c 3 10.0.0.10
showmount -e 10.0.0.10   # NFS の場合

# 5) コンテナ内からのアクセス確認（起動できた場合）
docker exec -it app sh -lc "ls -ld /app/data && df -h /app/data"

このあたりを上から順に確認するだけでも、「パスの存在」「権限」「リモート先」「定義ミス」のどこに問題があるかがかなり絞れる。

NG→OK 早見表（よくあるパターンと修正例）

# 1) ホストパスが存在しない
# NG
docker run -v /data/app:/app/data my-image   # /data/app が無い

# OK: 事前にディレクトリ作成
mkdir -p /data/app
docker run -v /data/app:/app/data my-image


# 2) 権限不足（root専用ディレクトリ）
# NG
docker run -v /root/data:/app/data my-image   # permission denied

# OK: パスをユーザー領域に変える or 権限調整
mkdir -p /home/user/data
docker run -v /home/user/data:/app/data my-image


# 3) compose でホストパスのつもりが named volume に
# NG
services:
  app:
    image: my-image
    volumes:
      - data:/app/data  # data ディレクトリのつもり

# OK: 相対パスを明示
services:
  app:
    image: my-image
    volumes:
      - ./data:/app/data


# 4) NFS サーバダウン
# NG: mount失敗 → Failed to Mount Volume
volumes:
  nfsdata:
    driver: local
    driver_opts:
      type: nfs
      o: addr=10.0.0.10,nolock,soft
      device: ":/export/data"

# OK: NFSサーバを復旧し、エクスポート確認
showmount -e 10.0.0.10


# 5) SELinux がブロックしている
# NG
docker run -v /host/data:/app/data my-image   # permission denied

# OK: SELinuxコンテキストを適切に設定
docker run -v /host/data:/app/data:Z my-image

チェックリスト（上から順に確認する）

1) マウントしようとしているのは bind mount か named volume か、リモートボリュームかを整理したか
2) bind mount の場合、ホストパスが実際に存在し、期待どおりの種類（ファイル/ディレクトリ）になっているか
3) ホスト側の所有権・パーミッション・SELinuxコンテキストに問題がないか
4) docker-compose.yml の volumes 記述が、ホストパスかnamed volumeかを正しく表現しているか（docker compose configで確認したか）
5) named volume の driver / driver_opts が正しく、deviceで指定したパスやリモート先が存在するか
6) NFS/CIFSなどリモートボリュームの場合、サーバが起動し、ネットワーク・FW・エクスポート設定が正しいか
7) Windows / Mac の Docker Desktop では、対象のディレクトリ共有が許可されているか
8) 古いコンテナ・ボリューム・マウント状態が残っていないか（compose down / volume prune / umount を試したか）