docker: Error response from daemon よくあるエラーと対処法まとめ

Dockerを使っていると必ず遭遇する Error response from daemon。このメッセージは「Dockerデーモンがリクエストを拒否した」という総称であり、後ろに続くメッセージの内容によって原因も対処法も全く異なります。

しかし現実には:

• エラーメッセージが長くて何を見ればいいか分からない
• 「OCI runtime create failed」だけで何十パターンも原因がある
• ポートエラー、権限エラー、イメージエラー……どこから調べればいいか迷う
• docker compose 経由でのエラーは原因がさらに見えにくい
• ネットワーク・ボリューム・seccomp・capabilityなど上級者向けのエラーに情報が少ない

という声が多い領域です。

本記事では docker: Error response from daemon のエラーを後続メッセージのパターン別に完全分類し、それぞれの原因と対処法をリファレンスとしてまとめました。基本的なエラーから、OCI runtime系・ネットワーク系・ボリューム系・権限系・イメージ系・リソース系まで全パターン網羅。デバッグ手順・Compose連携・トラブルシューティング・FAQも完備。この1本をブックマークすれば Error response from daemon に関するあらゆる疑問が解決します。

結論：エラーメッセージ早見表

まず後続メッセージで大カテゴリに振り分けます。

デーモン未起動 / 接続できない

Error response from daemon の前に出る場合もある最初の関門です。

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?
Got permission denied while trying to connect to the Docker daemon socket

デーモンが起動していない

# デーモンの状態確認
sudo systemctl status docker

# 起動していなければ起動
sudo systemctl start docker

# 自動起動を有効化
sudo systemctl enable docker

# macOS/Windows: Docker Desktopを起動する
# （タスクトレイ/メニューバーのDockerアイコンを確認）

権限不足（Linux）

# 現在のユーザーがdockerグループに属しているか確認
groups $USER

# dockerグループに追加（ログアウト&ログインが必要）
sudo usermod -aG docker $USER

# 即時反映したい場合（セッション内のみ有効）
newgrp docker

# sudoで一時的に実行
sudo docker ps

Conflict: コンテナ名の重複

Error response from daemon: Conflict. The container name "/myapp" is already in use by container "abc123...". You have to remove (or rename) that container to be able to reuse that name.

原因と対処

同名のコンテナが既に存在しています（停止中でも名前は占有されます）。

# 該当コンテナの確認（停止中も含む）
docker ps -a | grep myapp

# コンテナを削除してから再実行
docker rm myapp
docker run --name myapp myimage

# 強制削除（実行中のコンテナも含めて削除）
docker rm -f myapp

# 使い捨てコンテナなら --rm で自動削除
docker run --rm --name myapp myimage

# 名前を変えて起動
docker run --name myapp-v2 myimage

docker compose での対処

# compose管理のコンテナが残っている場合
docker compose down        # コンテナ削除
docker compose up -d       # 再作成

No such container / No such image

Error response from daemon: No such container: myapp
Error response from daemon: No such image: myimage:latest

コンテナが存在しない

# 全コンテナ確認（停止中含む）
docker ps -a

# 名前・IDの部分一致で検索
docker ps -a --filter name=myapp

# 正確なコンテナ名/IDを確認してから操作
docker stop <正確なコンテナ名またはID>

イメージが存在しない

# ローカルのイメージ一覧確認
docker images
docker images | grep myimage

# pullして取得
docker pull myimage:latest

# タグ名を確認（latestと思っていたが別タグの場合も）
docker pull myimage:1.0.0

イメージ取得（pull）系のエラー

pull access denied（プライベートリポジトリ/認証エラー）

Error response from daemon: pull access denied for myimage, repository does not exist or may require 'docker login': denied: requested access to the resource is denied

# Docker Hubにログイン
docker login

# プライベートレジストリにログイン
docker login registry.example.com

# ログイン状態の確認
cat ~/.docker/config.json

# ECR（AWS）の場合
aws ecr get-login-password --region ap-northeast-1 | \
    docker login --username AWS --password-stdin <account_id>.dkr.ecr.ap-northeast-1.amazonaws.com

# GCR（Google Cloud）の場合
gcloud auth configure-docker

manifest unknown（タグが存在しない）

Error response from daemon: manifest for myimage:lastest not found: manifest unknown: manifest unknown

# タグのスペルミスを確認（latest → lastest は最頻出ミス）
docker pull myimage:latest   # ← latest が正しい

# Docker Hubで存在するタグを確認
docker pull myimage           # タグなしでlatestを確認
docker images myimage         # ローカルに存在するタグ一覧

# 明示的にタグを指定
docker pull nginx:1.25.0

rate limit（Docker Hubの取得制限）

Error response from daemon: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading.

# Docker Hubにログインすると制限が緩和される（無料: 200回/6時間）
docker login

# rate limit 状況の確認
TOKEN=$(curl "https://auth.docker.io/token?service=registry.docker.io&scope=repository:ratelimitpreview/test:pull" | jq -r .token)
curl --head -H "Authorization: Bearer $TOKEN" https://registry-1.docker.io/v2/ratelimitpreview/test/manifests/latest 2>&1 | grep -i ratelimit

SSL/TLS エラー（プライベートレジストリ）

Error response from daemon: Get "https://registry.example.com/v2/": x509: certificate signed by unknown authority

# /etc/docker/daemon.json に insecure-registries を追加（HTTP/自己署名証明書の場合）
sudo tee /etc/docker/daemon.json << 'EOF'
{
  "insecure-registries": ["registry.example.com:5000"]
}
EOF

sudo systemctl restart docker

# 正式対応: CAを信頼させる（本番推奨）
sudo cp ca.crt /usr/local/share/ca-certificates/registry-ca.crt
sudo update-ca-certificates
sudo systemctl restart docker

ポート競合系のエラー

Error response from daemon: driver failed programming external connectivity on endpoint myapp: Bind for 0.0.0.0:80 failed: port is already allocated
Error starting userland proxy: listen tcp4 0.0.0.0:3000: bind: address already in use

原因の特定

# ポートを使用しているプロセスを確認（Linux）
sudo lsof -i :80
sudo ss -tlnp | grep :80
sudo netstat -tlnp | grep :80

# ポートを使用しているプロセスを確認（macOS）
lsof -i :80

# Dockerコンテナ側の確認（他コンテナが同ポートを使っている場合）
docker ps --format "table {{.Names}}\t{{.Ports}}"

対処法

# 方法A: ホスト側のポートを変更する（最もシンプル）
docker run -p 8080:80 nginx    # 80→8080に変更

# 方法B: 競合しているプロセスを停止する
sudo kill $(sudo lsof -t -i:80)

# 方法C: 競合しているDockerコンテナを停止
docker stop $(docker ps -q --filter publish=80)

# docker-compose.ymlでのポート変更例
services:
  web:
    image: nginx
    ports:
      - "8080:80"    # ホスト側を8080に変更

ディスク容量不足

Error response from daemon: write /var/lib/docker/tmp/...: no space left on device
Error response from daemon: failed to create rootfs: write /var/lib/docker/...: no space left on device

原因の確認

# ディスク使用量全体を確認
df -h
df -h /var/lib/docker    # Dockerのデータディレクトリを直接確認

# Docker が使っている容量の内訳を確認
docker system df
docker system df -v      # 詳細（イメージ・コンテナ・ボリューム・キャッシュ）

不要リソースの削除

# 使っていないリソースを一括削除（最も手軽）
docker system prune

# 停止中コンテナ・未使用イメージ・キャッシュも含めて全削除（強力）
docker system prune -af

# 種類別の個別削除
docker container prune    # 停止中コンテナのみ
docker image prune -a     # 未使用イメージ（全て）
docker volume prune       # 未使用ボリューム
docker builder prune      # ビルドキャッシュ

# 古いイメージを指定日数以上のものだけ削除
docker image prune -a --filter "until=720h"    # 30日以上前

ディレクトリの移動（根本対策）

# /var/lib/docker をディスクが大きいパーティションに移動する
sudo systemctl stop docker

# daemon.json でデータルートを変更
sudo tee /etc/docker/daemon.json << 'EOF'
{
  "data-root": "/mnt/large-disk/docker"
}
EOF

# データを移行
sudo rsync -aP /var/lib/docker/ /mnt/large-disk/docker

sudo systemctl start docker

permission denied 系のエラー

コンテナ内のファイル実行権限がない

Error response from daemon: OCI runtime create failed: ... exec: "/app/start.sh": permission denied

# Dockerfileで実行権限を付与する
COPY start.sh /app/start.sh
RUN chmod +x /app/start.sh

# イメージ内の権限確認
docker run --rm --entrypoint sh myimage -c "ls -la /app/start.sh"

# 一時的にentrypointを変えてデバッグ
docker run --rm -it --entrypoint sh myimage

ボリュームマウント先の権限エラー

Error response from daemon: failed to create shim: ... permission denied
mkdir ...: permission denied

# マウント先のディレクトリの権限確認
ls -la /host/path/to/mount

# 権限を修正
sudo chown -R $USER:$USER /host/path/to/mount
sudo chmod 755 /host/path/to/mount

# コンテナ実行ユーザーを指定
docker run -u $(id -u):$(id -g) -v /host/path:/container/path myimage

OCI runtime create failed 系のエラー

このエラーは「コンテナプロセスの起動そのものに失敗した」ことを示す総称で、後続メッセージによって原因が大きく異なります。

exec: “コマンド”: executable file not found in $PATH

OCI runtime create failed: ... exec: "python": executable file not found in $PATH

# イメージ内にコマンドが存在するか確認
docker run --rm --entrypoint sh myimage -c "which python3"
docker run --rm --entrypoint sh myimage -c "ls /usr/bin/python*"

# パスが違う場合はフルパスで指定
docker run myimage /usr/bin/python3 /app/script.py

# Dockerfileで修正
# CMD ["python3", "/app/script.py"]    ← python3を使う

exec: “/app/start.sh”: no such file or directory

OCI runtime create failed: ... exec: "/app/start.sh": stat /app/start.sh: no such file or directory

# ファイルがイメージ内に存在するか確認
docker run --rm --entrypoint sh myimage -c "ls -la /app/"

# Dockerfileのコピー先パスを確認
# COPY start.sh /app/start.sh  ← パスが正しいか

よくある原因として改行コード（CRLF）問題があります。Windowsで作成したシェルスクリプトをそのままコピーするとシバン行が #!/bin/sh\r と解釈され「no such file or directory」になります。

# 改行コードを確認
file start.sh

# CRLFをLFに変換
dos2unix start.sh
# または
sed -i 's/\r$//' start.sh

unknown runtime specified

Error response from daemon: Unknown runtime specified nvidia

# GPUランタイム（NVIDIA）がインストールされていない
# nvidia-container-toolkitをインストール
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | \
    sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt update && sudo apt install -y nvidia-container-toolkit
sudo systemctl restart docker

# GPUなしで代替実行したい場合はruntimeの指定を外す
docker run myimage   # --gpus all を削除

invalid mount configuration

OCI runtime create failed: ... invalid mount {Destination: ...}: mount destination ... not absolute

# マウント先のパスが絶対パスになっているか確認
# ❌
docker run -v mydata:data myimage

# ✅ コンテナ側のパスは必ず /から始まる絶対パス
docker run -v mydata:/data myimage

# Git Bash on Windows での特殊ケース（パス変換の問題）
# ❌
docker run -v $(pwd):/app myimage
# ✅ MSYS_NO_PATHCONV を設定
MSYS_NO_PATHCONV=1 docker run -v $(pwd):/app myimage

ネットワーク系のエラー

network not found

Error response from daemon: network mynetwork not found

# 存在するネットワーク一覧を確認
docker network ls

# ネットワークを作成してから実行
docker network create mynetwork
docker run --network mynetwork myimage

# docker-compose では自動的にネットワークが作成されるが、
# 外部ネットワークを参照している場合は external: true の設定が必要

# docker-compose.yml での外部ネットワーク参照例
networks:
  mynetwork:
    external: true

failed to create network … Pool overlaps

Error response from daemon: Failed to create network: ... Pool overlaps with other one on this address space

# 既存のDockerネットワーク一覧とサブネットを確認
docker network ls
docker network inspect bridge

# 重複していないサブネットを指定して作成
docker network create --subnet=192.168.100.0/24 mynetwork

# 不要なネットワークを削除
docker network prune

DNS 名前解決エラー（コンテナ内）

Error response from daemon: Get "https://registry-1.docker.io/v2/": dial tcp: lookup registry-1.docker.io: no such host

# デーモンのDNS設定を変更
sudo tee /etc/docker/daemon.json << 'EOF'
{
  "dns": ["8.8.8.8", "8.8.4.4"]
}
EOF
sudo systemctl restart docker

endpoint with name already exists

Error response from daemon: endpoint with name myapp already exists in network mynetwork

# 孤立したエンドポイントのクリーンアップ
docker network disconnect -f mynetwork myapp
docker network connect mynetwork myapp

# または完全に作り直す
docker compose down
docker network prune
docker compose up -d

ボリューム系のエラー

bind source path does not exist

Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /host/path/to/dir

# ホスト側のパスが存在するか確認
ls -la /host/path/to/dir

# 存在しない場合は作成
mkdir -p /host/path/to/dir

# docker-compose.yml のボリューム指定を確認
# volumes:
#   - ./relative/path:/container/path   ← 相対パスはcompose.ymlの場所が基準

volume is in use

Error response from daemon: remove myvolume: volume is in use - [container_id]

# ボリュームを使用しているコンテナを停止・削除してから
docker stop <container_id>
docker rm <container_id>
docker volume rm myvolume

# 強制削除（使用中でも削除するが危険）
docker volume rm -f myvolume

# 全未使用ボリュームを削除
docker volume prune

cannot create directory: read-only file system

Error response from daemon: ... mkdir ...: read-only file system

# コンテナのrootfsが読み取り専用になっている（--read-only オプション等）
# 書き込みが必要なディレクトリをtmpfsまたはボリュームでマウント
docker run --read-only \
    --tmpfs /tmp \
    -v mydata:/app/data \
    myimage

seccomp/capability 系のエラー

operation not permitted

Error response from daemon: OCI runtime create failed: ... operation not permitted

# 必要なcapabilityを追加
docker run --cap-add SYS_PTRACE myimage      # straceなど
docker run --cap-add NET_ADMIN myimage       # ネットワーク操作
docker run --cap-add SYS_ADMIN myimage       # マウント操作など（要注意）

# seccompを無効化（デバッグ用・非推奨）
docker run --security-opt seccomp=unconfined myimage

# privilegedモードで全て許可（本番禁止）
docker run --privileged myimage

container_linux.go: … device or resource busy

Error response from daemon: error while creating mount source path ...: device or resource busy

# 別のプロセスがマウントポイントを使用している
lsof +D /host/path/to/dir

# Dockerの再起動で解消する場合もある
sudo systemctl restart docker

イメージ削除系のエラー

conflict: unable to delete / image is being used

Error response from daemon: conflict: unable to delete abc123 (must be forced) - image is being used by stopped container def456

# イメージを参照しているコンテナを確認
docker ps -a --filter ancestor=myimage

# コンテナを先に削除してからイメージを削除
docker rm def456
docker rmi myimage

# 強制削除（コンテナごと消す場合）
docker rmi -f myimage

conflict: unable to delete / image has dependent child images

Error response from daemon: conflict: unable to delete abc123 (cannot be forced) - image has dependent child images

# 子イメージ（派生イメージ）を先に削除する必要がある
# 依存関係を確認
docker image inspect --format='{{.RepoTags}} {{.Id}}' $(docker images -q)

# 子イメージを特定して削除
docker images --filter dangling=true
docker rmi <子イメージID>
docker rmi <親イメージID>

docker compose 特有のエラー

service failed to build

Error response from daemon: failed to create image: failed to get image ... failed to read dockerfile

# Dockerfile の場所と名前を確認
ls -la Dockerfile
ls -la docker/Dockerfile

# compose.yml で context と dockerfile を明示的に指定
# build:
#   context: ./docker
#   dockerfile: Dockerfile.prod

depends_on によるサービス順序問題

depends_on は「コンテナの起動順序」は保証しますが「サービスの準備完了」は保証しません。

# healthcheck と condition を組み合わせる（Compose v2.1+）
services:
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      timeout: 5s
      retries: 5

  app:
    image: myapp
    depends_on:
      db:
        condition: service_healthy

Compose でのネットワーク参照エラー

Error response from daemon: network <project>_default not found

# 一度完全に落としてから起動し直す
docker compose down
docker compose up -d

# ネットワーク名が変わった場合（プロジェクト名の変更等）
docker network ls | grep myproject
docker compose down --remove-orphans
docker compose up -d

デバッグ手順：エラー原因を素早く特定する

Step 1: エラーメッセージ全文を正確に読む

# エラーの後半部分が本当の原因
docker run myimage 2>&1 | tail -20

# dockerdのログを確認（デーモンレベルの詳細が見える）
sudo journalctl -u docker --since "5 minutes ago"

Step 2: コンテナの状態を確認する

# 終了したコンテナの詳細確認
docker ps -a
docker inspect <container_id>

# 終了コードを確認
docker inspect <container_id> --format='{{.State.ExitCode}}'

# 直近のコンテナログを確認
docker logs <container_id>
docker logs --tail=50 <container_id>

Step 3: entrypoint を上書きしてシェルで調査

# コンテナ内に入って直接調査（最も確実）
docker run --rm -it --entrypoint sh myimage

# 最小限の alpine シェルで試す
docker run --rm -it --entrypoint sh alpine

# 環境変数・パス・ファイル存在をその場で確認
echo $PATH
ls -la /app/
which python3

Step 4: Dockerデーモンのログを確認する

# systemd 環境
sudo journalctl -u docker -n 100 --no-pager

# /var/log/docker.log がある環境
sudo tail -100 /var/log/docker.log

# デバッグレベルのログを有効化（daemon.json）
# { "debug": true }

トラブルシューティング

エラーが断続的に発生する（安定しない）

# ディスク容量の逼迫を確認
df -h && docker system df

# デーモンの状態確認
sudo systemctl status docker

# Docker Desktop の場合はリソース（CPU/メモリ）制限を確認
# Settings → Resources → Advanced

docker compose up が途中で止まる

# フォアグラウンドで詳細ログを出力
docker compose up    # -d を外して実行

# 特定サービスのみ起動して確認
docker compose up db     # dbサービスだけ起動

# ビルドキャッシュを無効化して再ビルド
docker compose build --no-cache
docker compose up

イメージのビルドは成功するがコンテナ起動で失敗する

# ビルド後すぐにシェルで入って確認
docker build -t myimage .
docker run --rm -it --entrypoint sh myimage

# ENTRYPOINTとCMDの組み合わせを確認
docker inspect myimage --format='{{.Config.Entrypoint}} {{.Config.Cmd}}'

同じコマンドがローカルでは動くがCI/CD環境では失敗する

# 環境変数の違いを疑う
docker run --rm myimage env | sort

# ビルドキャッシュが古い可能性
docker build --no-cache -t myimage .

# アーキテクチャ（arm64 vs amd64）の違いを疑う
docker buildx build --platform linux/amd64 -t myimage .

実用パターン集

環境をまっさらにリセットする（最終手段）

# コンテナ・イメージ・ボリューム・ネットワーク・キャッシュを全削除
docker system prune -af --volumes

# 削除後に確認
docker system df

エラーログを保存して後で分析する

# コンテナログをファイルに保存
docker logs myapp > /tmp/myapp.log 2>&1

# docker events でリアルタイムにイベントを監視
docker events --filter container=myapp

マルチアーキテクチャ関連のエラー対応

# exec format error: アーキテクチャ不一致
# ビルド時にプラットフォームを明示する
docker buildx build --platform linux/amd64,linux/arm64 -t myimage .

# 実行時にプラットフォームを指定
docker run --platform linux/amd64 myimage

よくある質問（FAQ）

Q1. Error response from daemon と Error: No such container の違いは？

Error response from daemon はDockerデーモンが返すエラー全般を指し、その後に続くメッセージが本当のエラー原因です。No such container はその具体的な一例。まず後続メッセージを正確に読むことが解決への第一歩です。

Q2. docker run と docker compose up で同じエラーが出ます

docker compose up のエラーは最終的には docker run と同じDockerデーモンへのリクエストなので、エラー原因は同じです。compose経由で見づらい場合は、docker inspect で対応するコンテナの詳細を確認するか、docker compose run サービス名 sh でシェルに入って確認してください。

Q3. --privileged で全部解決しますが、本番でも使っていいですか？

避けてください。--privileged はコンテナのセキュリティ隔離をほぼ無効化します。本番環境では必要なcapabilityを --cap-add で個別に追加する方法が正解です。

Q4. Docker Desktopのリセット方法は？

Docker Desktop → Troubleshoot → Reset to factory defaults

設定・認証情報・ボリューム・イメージが全て消えるため最終手段ですが、原因不明のデーモンレベルエラーが解消することがあります。

Q5. エラーメッセージに unknown とだけ出ます

runc や containerd レベルの低レベルエラーで情報が少ない場合です。

# daemonのデバッグログを有効化して詳細を確認
sudo tee -a /etc/docker/daemon.json << 'EOF'
{"debug": true}
EOF
sudo systemctl restart docker
sudo journalctl -u docker -f

Q6. Windows/WSL2特有のエラーへの対処は？

# WSL2のメモリ・CPUリソース制限（C:\Users\<user>\.wslconfig）
# [wsl2]
# memory=4GB
# processors=2

# Docker Desktopのリソース設定も要確認
# Settings → Resources → WSL Integration

Q7. コンテナが起動してすぐ終了します（Exited (0) または (1)）

# 終了コードとログを確認
docker ps -a
docker logs <container_id>

# インタラクティブモードで原因を確認
docker run -it myimage bash   # または sh

終了コード 0 は正常終了（フォアグラウンドプロセスが終わった）、1 はアプリケーションエラー、127 はコマンドが見つからない、137 はOOM Kill（メモリ不足）です。

Q8. no space left on device が出るが df -h では容量に余裕があります

# inodeが枯渇している可能性
df -i

# inode使用量が100%なら小さいファイルが大量にある
# docker system prune で不要なファイルを削除
docker system prune -af

参考リンク・関連資料

公式ドキュメント

• Docker Engine トラブルシューティング – 公式トラブルシューティングガイド
• Docker Desktop トラブルシューティング – Desktop固有の問題
• docker run リファレンス – オプション一覧

関連記事（本サイト）

• Linux OOM Killerの確認方法まとめ – コンテナが突然消える原因のひとつ
• Linux「No such file or directory」エラーの原因と確認方法まとめ – コンテナ内のパス問題
• tarコマンドの使い方と実用例まとめ – コンテナ内外のアーカイブ操作

まとめ

docker: Error response from daemon は総称メッセージであり、後続のメッセージが本当の原因です。要点を再整理します。

• まず後続メッセージを正確に読む: 本記事の早見表でカテゴリを特定するのが最短ルート
• コンテナ名の重複 → docker rm で削除、または --rm で使い捨て運用
• イメージ取得失敗 → docker login、タグのスペルミス確認、rate limit 対策
• ポート競合 → lsof -i :ポート番号 で犯人特定、ホスト側ポートを変更
• ディスク不足 → docker system prune -af で一括掃除、データルートの移動
• OCI runtime エラー → exec not found/permission denied/no such file でそれぞれ原因が異なる
• CRLFシバン行問題 → dos2unix で変換（Windows作成のシェルスクリプト特有）
• ネットワーク → docker network ls で存在確認、プール重複はサブネット指定で回避
• ボリューム → ホスト側パスの実在確認、コンテナ側パスは絶対パス必須
• デバッグの基本 → --entrypoint sh で中に入って直接確認するのが最確実
• 最終手段 → docker system prune -af --volumes で全リセット、Docker Desktopは factory reset

本記事は2026年6月時点の情報をもとに、Docker Engine 26.x・Docker Desktop 4.x での動作確認に基づき作成しています。バージョンによって一部のオプションや挙動が異なる場合があるため、最新の情報は公式ドキュメントもあわせてご確認ください。