Dockerの「Mounts denied」エラーの解決策:ファイル共有設定ガイド

初級🐳 Docker2026-06-29| macOS (Intel/Apple Silicon) または Windows (Hyper-V バックエンド) 上の Docker Desktop

Error Message

Error response from daemon: Mounts denied: The path /Users/project is not shared from the host and is not known to Docker.
#docker-desktop#volume#macos#file-sharing#mount

想定されるシナリオ開発を始めようとして docker-compose up を実行したものの、すべてが停止してしまった経験はありませんか?先日、-v フラグを使ってカスタムソースコードディレクトリをコンテナにマッピングしようとした際、この問題に直面しました。実行環境が立ち上がる代わりに、ターミナルには次のような無機質なエラーメッセージが表示されました。

docker: Error response from daemon: Mounts denied: 
The path /Users/project is not shared from the host and is not known to Docker. 
You can configure shared paths from Docker -> Preferences... -> Resources -> File Sharing.

この問題が発生するのは、Docker Desktop がハードドライブへの全アクセス権限を持っていないためです。Docker は軽量な仮想マシン (VM) 内で動作しており、セキュリティ上の理由から制限されたサンドボックス内で実行されます。Docker の「許可リスト」に含まれていないディレクトリをマウントしようとすると、システムを保護するためにエンジンがリクエストをブロックします。

原因についてDocker Desktop がホストマシンのフォルダにアクセスするには、明示的な許可が必要です。デフォルトでは、macOS の /Users/Volumes/private/tmp といった一般的なパスは信頼されています。しかし、プロジェクトが独自の /Data パーティションや特定のルートフォルダなど、カスタムの場所に保存されている場合、Docker はコンテナによる不正なファイルアクセスを防ぐためにマウントを拒否します。

回避策:プロジェクトの移動急いでいる場合は、プロジェクトフォルダを Docker が既に信頼しているパスに移動するのが最も早い解決策です。Mac の場合、フォルダを /Users/ユーザー名/ 内にドラッグするだけで、通常はすぐに解決します。ほとんどの Docker Desktop インストール環境では、/Users がデフォルトで共有されているためです。

恒久的な解決策:ファイル共有の設定マウントのためだけにワークフロー全体を変更する必要はありません。プロジェクトの場所を変えずに、以下の手順でパスを許可してください。

ステップ 1: Docker Desktop の設定を開くメニューバー (macOS) またはシステムトレイ (Windows) の Docker アイコンをクリックし、Settings を選択します。バージョン 4.0 より古いものを使用している場合は、Preferences と表示されている場合があります。

ステップ 2: File Sharing に移動するサイドバーの Resources を開き、File Sharing タブをクリックします。現在 Docker VM がアクセスを許可されているディレクトリの一覧が表示されます。

ステップ 3: カスタムパスを追加する「+」(プラス) ボタンをクリックします。プロジェクトディレクトリ (例: /Users/project) を参照するか、開発作業をまとめている親フォルダを選択します。Open をクリックしてリストに追加します。

ステップ 4: Apply & Restart を実行するApply & Restart ボタンをクリックします。新しい権限を読み込むために Docker の内部エンジンが再起動します。ハードウェアの性能によりますが、通常 30 秒から 60 秒ほどかかります。

修正の確認Docker の再起動が完了したら、軽量なコンテナを使ってマウントをテストします。ターミナルで次のコマンドを実行してください。

docker run --rm -v /Users/project:/app alpine ls /app

エラーではなくローカルファイルの一覧が表示されれば、設定は完了です。

ファイル同期トラブルの解決マウントは成功しても、変更が即座に同期されないことがあります。これは通常、ファイル共有の実装方式に起因します。Docker Desktop 4.6 以降では macOS 向けに VirtioFS が導入され、従来の gRPC FUSE よりも大幅にパフォーマンスが向上しています。

ファイルが正しく反映されていない疑いがある場合は、ハッシュ値を比較してみてください。私は ToolCraft の Hash Generator を使って、ホスト上の設定ファイルの MD5 または SHA-256 ハッシュを作成しています。次に、コンテナ内で md5sum を実行します。文字列が一致すれば、同期は完璧です。推測に頼るよりも、この 10 秒のチェックを行う方が確実です。

Windows ユーザーへの注意点WSL 2 バックエンドで Windows を使用している場合、「File Sharing」タブが完全に消えていることに気づくでしょう。これは、WSL 2 が Linux カーネルを通じてファイルアクセスを管理しているためです。ここでマウントエラーが発生する場合、Windows のパス (C:\Projects など) を Linux コンテナにマウントしていることが原因である可能性が高いです。パフォーマンスを 2 〜 5 倍向上させるには、ファイルを \\wsl$\Ubuntu\home\user\project のような WSL ファイルシステム内に直接移動してください。

まとめチェックリスト- Docker Settings > Resources > File Sharing に正確なパス(またはその親フォルダ)がリストされていますか?- 「Apply & Restart」をクリックしましたか?- macOS Ventura または Sonoma を使用している場合、システム設定で Docker に「フルディスクアクセス」を許可していますか?- スクリプト内で、制限されたディレクトリに解決される相対パスを使用していませんか?

Related Error Notes