Docker のよくあるエラーメッセージ集：原因と解決方法（実際の出力付き）

Q: エラーメッセージが長い場合、どこを見ればよいですか？

まず最後のコロンの後にある文を確認してください。そこに本当の原因が書かれていることが多く、たとえば port is already allocated や no such file or directory です。先頭の Error response from daemon や failed to create task は、どの層でエラーが発生したかを示しているだけです。

Q: インターネットで見つけたエラーメッセージが、表示されたものと違うのはなぜですか？

Docker のエラーメッセージはバージョンによって変わります。たとえば旧バージョンの Cannot connect to the Docker daemon at unix:///var/run/docker.sock は、Docker 29 では failed to connect to the docker API at unix:///var/run/docker.sock に変わっています。最後のキーワードで検索すると、答えを見つけやすくなります。

Q: docker run が失敗した後、もう一度実行すると名前が使用中と表示されるのはなぜですか？

ポートの競合など、多くのエラーが起きた時点でコンテナはすでに作成されており、起動に失敗しただけです。docker ps -a を実行すると、Created 状態のコンテナを確認できます。docker rm で削除してから、もう一度実行してください。

Q: コンテナが終了した理由を確認するにはどうすればよいですか？

docker ps -a で STATUS の終了コードを確認し、docker logs コンテナ名 でプログラムの出力を確認します。また、docker inspect -f "{{.State.ExitCode}} {{.State.OOMKilled}}" コンテナ名 も実行してください。終了コード 137 は強制終了（SIGKILL またはメモリ不足）、1 は通常、プログラム自体のエラーを示します。

このページでは、Docker でよく見られるエラーメッセージをまとめています。見出しにはエラーメッセージのキーワードを使っているので、ブラウザーの検索機能（Ctrl+F）で直接探せます。各エラーには、Docker 29 で実際に再現した出力、原因、解決方法を記載しています。

該当するエラーが見つからない場合は、次の基本手順で調べてください。

エラーメッセージの最後の部分にあるキーワードを確認します。
docker ps -a でコンテナの状態と終了コードを確認します。
docker logs コンテナ名 でプログラム自体の出力を確認します。
詳しいデバッグ方法はログの確認とデバッグを参照してください。

接続と権限

failed to connect to the docker API / Cannot connect to the Docker daemon

$ docker run --rm --entrypoint docker docker:29.9-cli -H unix:///var/run/docker.sock ps
failed to connect to the docker API at unix:///var/run/docker.sock; check if the path is correct and if the daemon is running: dial unix /var/run/docker.sock: connect: no such file or directory

旧バージョンでは Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running? と表示されていました。意味は同じで、docker コマンド（クライアント）が Docker Engine（サーバー）を見つけられないということです。

解決方法：

Windows / macOS：Docker Desktop が起動していることを確認します。システムトレイのクジラのアイコンの回転が止まり、状態が Engine running になっている必要があります。
Linux：Docker サービスを起動します：sudo systemctl start docker。さらに、起動時に自動で開始するよう設定します：sudo systemctl enable docker。
DOCKER_HOST 環境変数が設定されていないか、別の context に切り替わっていないか確認します：docker context ls。

permission denied while trying to connect to the docker API

$ docker run --rm -u 1000:1000 -v /var/run/docker.sock:/var/run/docker.sock docker:29.9-cli docker ps
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

Linux では、/var/run/docker.sock にアクセスできるのは root と docker グループだけです。一般ユーザーが docker を実行すると、このエラーが表示されます。

解決方法：ユーザーを docker グループに追加し、再ログインする（または newgrp docker を実行する）と反映されます。

sudo usermod -aG docker $USER

docker グループへの追加は root 権限を与えることと同じです。詳しくはセキュリティのベストプラクティスを参照してください。避けたい場合はRootless モードを利用できます。

ポートと名前

port is already allocated

$ docker run -d --name web1 -p 8080:80 nginx:1.30-alpine
7a72d42f052dfebded509314b1975c72fbb1fcbf0c97099d6d60c9dedbcad8a1

$ docker run -d --name web2 -p 8080:80 nginx:1.30-alpine
6bcca59a67e5a5adbab1da7b2dbb7ef92f1df1f6e7680462a22541fd96f0ac9f
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint web2 (3a269ae1baae56a10b06552ba76fff69b3414885b2fa7a737344e081b4d5acd5): Bind for 0.0.0.0:8080 failed: port is already allocated

Run 'docker run --help' for more information

ホストの 8080 番ポートは、すでに別のコンテナ（ここでは web1）が使用しています。注意してください。エラーが発生した時点で web2 はすでに作成されていますが、起動していません（状態は Created）。そのため、修正後に同じコマンドを実行すると、次は「名前がすでに使用されています」というエラーが発生します。

解決方法：

別のホストポートに変更します：-p 8081:80。
または、使用中のコンテナを停止します：docker ps で 8080 を使用しているコンテナを見つけてから、docker stop を実行します。
作成に失敗したコンテナを削除します：docker rm web2。

address already in use

$ docker run -d --name web3 -p 9090:80 nginx:1.30-alpine
2c4649bbf85211d1ef6852c95fad52075b63d8d77e3fcd7c74db0bc7d15fbd8f
docker: Error response from daemon: failed to set up container networking: driver failed programming external connectivity on endpoint web3 (38386ef2562f999706b1d2b00eac0e48125eb006916dc857832ce18d36fe44d6): failed to bind host port 0.0.0.0:9090/tcp: address already in use

Run 'docker run --help' for more information

前のエラーとよく似ていますが、ポートを使用しているのはホスト上の別のプログラム（コンテナではありません）です。たとえば、ローカルにインストールした Nginx や MySQL、または実行中の開発サーバーが該当します。

解決方法：使用中のプログラムを見つけて終了するか、別のポートに変更します。

sudo lsof -i :9090          # Linux / macOS
netstat -ano | findstr 9090 # Windows

コンテナ名「/web1」はすでに使用されています

$ docker run -d --name web1 -p 8081:80 nginx:1.30-alpine
docker: Error response from daemon: Conflict. The container name "/web1" is already in use by container "7a72d42f052dfebded509314b1975c72fbb1fcbf0c97099d6d60c9dedbcad8a1". You have to remove (or rename) that container to be able to reuse that name.

Run 'docker run --help' for more information

コンテナ名は重複できません。停止中のコンテナも含まれます。

解決方法：

古いコンテナを削除します：docker rm -f web1。
または別の名前にします。
一時的に実行するコンテナには --rm を付けると、終了後に自動的に削除されるため、同じ名前のコンテナが残りません。

イメージ

not found / manifest unknown / pull access denied

$ docker pull nginx:9.99
Error response from daemon: failed to resolve reference "docker.io/library/nginx:9.99": docker.io/library/nginx:9.99: not found

$ docker pull ngnix-official-not-real
Using default tag: latest
Error response from daemon: failed to resolve reference "docker.io/library/ngnix-official-not-real:latest": docker.io/library/ngnix-official-not-real:latest: not found

イメージが見つかりません。よくある原因：

タグの入力ミス、またはタグが存在しない：nginx:9.99 というバージョンは存在しません。Docker Hub の Tags ページで確認するか、docker buildx imagetools inspect イメージ名 で調べます。
名前の入力ミス：ngnix。公式イメージの名前にプレフィックスはありません（例：nginx、postgres）。
プライベートイメージにログインしていない：まず docker login を実行します。

Docker のバージョンや Registry によって、同じ問題でも manifest unknown または pull access denied for ..., repository does not exist or may require 'docker login' と表示される場合があります。

repository name must be lowercase / invalid reference format

$ docker build -t MyApp .
ERROR: failed to build: invalid tag "MyApp": repository name must be lowercase

イメージ名に使えるのは小文字、数字、-、_、.、/ だけです。MyApp を myapp に変更します。名前に空白や余分なコロン（例：myapp::1.0）があると、invalid reference format が表示されます。

toomanyrequests: You have reached your pull rate limit

Docker Hub からログインせずにイメージをダウンロードする場合、回数制限があります。短時間に大量に pull すると（たとえば CI で毎回再ダウンロードする場合）、このエラーが発生します。このエラーは本チュートリアルの環境では再現していないため、エラーメッセージは公式の説明に基づいています。

解決方法：

docker login で Docker Hub アカウントにログインすると、制限が緩和されます。
CI ではキャッシュを使うか、別の Registry のイメージミラーを使います。
ローカルにあるイメージは再 pull する必要はありません。コマンドに --pull always をむやみに追加しないでください。

exec format error

イメージの CPU アーキテクチャとホストのアーキテクチャが異なります。たとえば、Apple Silicon Mac でビルドした arm64 イメージを amd64 サーバーで実行する場合です。実際の出力と解決方法はマルチプラットフォームイメージを参照してください。

コンテナの起動に失敗する

exec /entrypoint.sh: no such file or directory（ファイルが存在するのに）

Windows ユーザーによくある問題です。シェルスクリプトが Windows の改行コード（CRLF）で保存されています。

$ docker build -q -t crlf-demo .
sha256:194d0a73ff66c601a1e7b1bf80417ae47c5de6e5e076415f17b483e642929fc2

$ docker run --rm crlf-demo
exec /entrypoint.sh: no such file or directory

$ od -c entrypoint.sh | head -n 2
0000000   #   !   /   b   i   n   /   s   h  \r  \n   e   c   h   o    
0000020   "   h   e   l   l   o       f   r   o   m       e   n   t   r

od -c を見ると、1 行目の末尾が \r \n になっています。Linux が読み取るインタープリターは /bin/sh\r（見えない \r が余分に付いています）です。このプログラムは存在しないため、非常に紛らわしい no such file or directory が発生します。

解決方法：

エディターで改行コードを LF に変更します（VS Code の右下にある CRLF をクリックして LF に変更します）。
Git は Windows で改行コードを CRLF に変換する設定がデフォルトです。プロジェクトのルートに .gitattributes を追加して、スクリプトで常に LF を使うようにします：
```
*.sh text eol=lf
```
または Dockerfile で変換します：RUN sed -i 's/\r$//' /entrypoint.sh。

exec: "/entrypoint.sh": permission denied

$ docker build -q -t noexec-demo .
sha256:4f37fec89287104ccf6b509fef5c1836d2a1a65b36d858ff63b95fecc3340a0e

$ docker run --rm noexec-demo
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "/entrypoint.sh": permission denied

Run 'docker run --help' for more information

スクリプトに実行権限がありません。Windows のファイルシステムには Linux の実行権限がないため、Windows からビルドすると特に起きやすい問題です。

解決方法：Dockerfile で実行権限を付与します：

COPY --chmod=755 entrypoint.sh /entrypoint.sh

または Linux / macOS で chmod +x entrypoint.sh を実行してからビルドします。

executable file not found in $PATH

$ docker run --rm alpine:3.23 bash
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: exec: "bash": executable file not found in $PATH

Run 'docker run --help' for more information

コンテナ内にこのプログラムがありません。alpine イメージには bash ではなく sh だけがあります。

解決方法：sh に変更するか、Dockerfile でインストールします（RUN apk add --no-cache bash）。CMD に存在しないプログラム名を書いた場合や、プログラムがイメージにコピーされていない場合にもよく起きます。

コンテナ起動直後に Exited (0) になる

$ docker run -d --name u1 ubuntu:26.04
9ff7034514a469602b48cc1bb3758514b32af8de6c602ce1bee11cd85813671c

$ docker ps -a --filter name=u1 --format "table {{.Names}}\t{{.Status}}"
NAMES     STATUS
u1        Exited (0) 2 seconds ago

$ docker rm u1
u1

これはエラーではありません。コンテナはメインプロセスの終了時に停止します。ubuntu イメージのデフォルトコマンドは bash です。バックグラウンド（-d）で実行し、ターミナルがないと、bash は入力を読み取れず終了します。

解決方法：

操作する場合：docker run -it ubuntu:26.04 bash。
実行を続けたい場合：Web サーバーなど、終了しないプログラムを指定します。テストでは sleep infinity を使えます。
終了コードが 0 以外の場合は、docker logs でプログラムのエラーメッセージを確認します。

Exited (137) または OOMKilled

終了コード 137 は、コンテナが SIGKILL で強制終了されたことを示します（128 + 9）。よくある原因：

メモリ不足：--memory の制限を超えた、またはホストのメモリが不足したため、システムによって終了されました。docker inspect -f "{{.State.OOMKilled}}" コンテナ名 で確認します。true ならメモリ不足です。
docker stop が 10 秒待ってもプログラムが終了せず、強制終了されました。原因についてはNode.js アプリケーションの PID 1 の実測を参照してください。
docker kill または docker rm -f。

本チュートリアルのテスト用ホストでは swap 制限が有効になっておらず、メモリ不足を安定して再現できないため、この項目には実際の出力を掲載していません。

cannot attach stdin to a TTY-enabled container because stdin is not a terminal / the input device is not a TTY

$ docker run -d --name a1 alpine:3.23 sleep 300
55637ca715821720e55fa1366d8df8813915bf12b7520f65b9e85922ea7c475c

$ docker exec -it a1 bash
cannot attach stdin to a TTY-enabled container because stdin is not a terminal

-t はターミナルを割り当てますが、入力がターミナルではありません。スクリプト、CI、cron で docker exec -it を使う場合や、<、| でファイルをコンテナに渡す場合によく起こります。

解決方法：対話操作をしない場合は -t を外し、入力が必要なら -i だけを残します。入力が不要なら何も付けません。たとえば、データベースを復元する場合は docker exec -i を使います。

ビルド（docker build）

failed to read dockerfile: open Dockerfile: no such file or directory

$ docker build -t x .
#0 building with "default" instance using docker driver

#1 [internal] load build definition from Dockerfile
#1 transferring dockerfile: 2B done
#1 DONE 0.0s
ERROR: failed to build: failed to solve: failed to read dockerfile: open Dockerfile: no such file or directory

現在のディレクトリに Dockerfile がありません。

解決方法：

正しいディレクトリで実行していることを確認します。最後の . はビルドコンテキストのパスです。
ファイル名は Dockerfile（大文字と小文字も一致）で、拡張子は付けません。Windows のメモ帳は自動的に .txt を追加し、ファイル名が Dockerfile.txt になることがあります。
ファイル名が異なる場合は -f で指定します：docker build -f Dockerfile.dev .。

failed to calculate checksum ... not found（COPY でファイルが見つからない）

$ docker build -t copy-demo .

[+] Building 0.1s (6/6) FINISHED                                                                                                       docker:default
 => [internal] load build definition from Dockerfile                                                                                             0.0s
 => => transferring dockerfile: 88B                                                                                                              0.0s
 => WARN: CopyIgnoredFile: Attempting to Copy file "config.json" that is excluded by .dockerignore (line 2)                                      0.0s
 => [internal] load metadata for docker.io/library/alpine:3.23                                                                                   0.0s
 => [internal] load .dockerignore                                                                                                                0.0s
 => => transferring context: 52B                                                                                                                 0.0s
 => [internal] load build context                                                                                                                0.0s
 => => transferring context: 2B                                                                                                                  0.0s
 => CACHED [1/2] FROM docker.io/library/alpine:3.23@sha256:85fe1e81d6758c208f3e1eed4338a1997e19d4be002d4dd32d3100c9a8c010a0                      0.0s
 => => resolve docker.io/library/alpine:3.23@sha256:85fe1e81d6758c208f3e1eed4338a1997e19d4be002d4dd32d3100c9a8c010a0                             0.0s
 => ERROR [2/2] COPY config.json /app/config.json                                                                                                0.0s
------
 > [2/2] COPY config.json /app/config.json:
------

 1 warning found (use docker --debug to expand):
 - CopyIgnoredFile: Attempting to Copy file "config.json" that is excluded by .dockerignore (line 2)
Dockerfile:2
--------------------
   1 |     FROM alpine:3.23
   2 | >>> COPY config.json /app/config.json
   3 |
--------------------
ERROR: failed to build: failed to solve: failed to compute cache key: failed to calculate checksum of ref v1wocdfz4uxsgxp2q2kukkuqp::jww9anqv7tl0n3ksy
1tlwp8fv: "/config.json": not found

COPY のファイルがビルドコンテキストにありません。先頭の WARN: CopyIgnoredFile が原因を示しています。config.json が .dockerignore で除外されています。

よくある原因：

ファイルが .dockerignore で除外されています（Docker 29 では先に警告が表示されます）。
パスが間違っているか、ファイルがビルドコンテキスト（docker build の最後の .）の外にあります。COPY ../file では親ディレクトリにアクセスできません。
大文字と小文字が一致していません。Windows と macOS は大文字と小文字を区別しませんが、Linux は区別します。

RUN ... did not complete successfully: exit code: 1

ビルド中に RUN コマンドが失敗しました。------ の間にある出力を上にたどると、そのコマンド固有のエラーメッセージが見つかります。たとえば、Python アプリでは STATIC_ROOT が設定されていないため Django の collectstatic が失敗します。出力全体が表示されない場合は --progress plain を付けます。

Volume とネットワーク

volume is in use

$ docker volume create data
data

$ docker run -d --name holder -v data:/data alpine:3.23 sleep 300
38eb68e3f9c7020fdb86ded25f1e73dc0a9fdcb932dea1353d04c4474e0e50d7

$ docker volume rm data
Error response from daemon: remove data: volume is in use - [38eb68e3f9c7020fdb86ded25f1e73dc0a9fdcb932dea1353d04c4474e0e50d7]

$ docker rm -f holder
holder

$ docker volume rm data
data

Volume はまだコンテナ（停止中のコンテナも含む）で使われているため、削除できません。エラーメッセージの ID が、それを使用しているコンテナです。先にコンテナを削除してから Volume を削除します。

network ... not found

$ docker run --rm --network appnet alpine:3.23 true
docker: Error response from daemon: failed to set up container networking: network appnet not found

Run 'docker run --help' for more information

指定したネットワークがありません。docker network create appnet で作成するか、docker network ls で名前を確認します。Compose プロジェクトのネットワーク名にはプロジェクト名のプレフィックスが付きます。たとえば shop_default です。

invalid mount config for type "bind": bind source path does not exist

存在しないホストパスを --mount type=bind でマウントすると発生します。実際の出力と -v との違いはVolume とデータの永続化を参照してください。

Docker Compose

yaml: ... did not find expected key / mapping values are not allowed

$ docker compose config
go-yaml load error in parser (while parsing a block mapping) at L3.C5-L6.C6: did not find expected key

YAML のインデントに誤りがあります。この例では environment: のインデントが 1 段深くなっています。エラーメッセージの L3.C5-L6.C6 は、3 行目 5 列目から 6 行目 6 列目までのブロックに問題があることを示します。

解決方法：

インデントにはスペースだけを使い、Tab は使いません。
同じ階層のキーを揃えます。
docker compose config で確認します。エラーがなければ、整形済みの設定全体が出力されます。

depends on undefined service

$ docker compose up -d
service "app" depends on undefined service "db": invalid compose project

depends_on に存在しないサービス名を指定しています。通常は入力ミスか、サービスが profiles に含まれていて有効になっていないことが原因です。

The "DB_PASSWORD" variable is not set. Defaulting to a blank string.

$ docker compose config
time="2026-10-13T05:27:10Z" level=warning msg="The \"DB_PASSWORD\" variable is not set. Defaulting to a blank string."
name: c3
services:
  db:
    environment:
      POSTGRES_PASSWORD: ""
    image: postgres:18
    networks:
      default: null
networks:
  default:
    name: c3_default

これはエラーではなく警告ですが、危険です。compose.yaml で ${DB_PASSWORD} を使っていますが、.env または環境変数に設定されていないため、空文字列に置き換えられています。その結果、データベースが空のパスワードで初期化される可能性があります。

解決方法：.env に変数を設定するか、${DB_PASSWORD:?DB_PASSWORD is required} と記述します。未設定の場合にエラーを出して停止します。詳しくは環境変数と .env ファイルを参照してください。

dependency failed to start: container ... is unhealthy

$ docker compose up -d
[+] up 3/3
 ✔ Network c4_default Created                                                                                                                     0.0s
 ✘ Container c4-db-1  Error dependency db failed to start                                                                                         2.8s
 ✔ Container c4-app-1 Created                                                                                                                     0.0s
dependency failed to start: container c4-db-1 is unhealthy

depends_on に condition: service_healthy が設定されていますが、依存先のサービスのヘルスチェックが失敗し続けています。この例では、意図的にヘルスチェックで false を実行しています。

トラブルシューティング：

docker inspect --format "{{json .State.Health}}" コンテナ で、各ヘルスチェックの出力を確認します。
ヘルスチェックのコマンド自体が正しいか確認します。たとえば、パスワードやホスト名を確認してください。データベースのヘルスチェックの書き方はMySQLとPostgreSQLを参照してください。
起動に時間がかかるサービスでは、start_period と retries の値を大きくします。

ディスク容量

No space left on device

$ docker run --rm --tmpfs /data:size=1m alpine:3.23 dd if=/dev/zero of=/data/big bs=1M count=2
dd: error writing '/data/big': No space left on device
2+0 records in
1+0 records out
1048576 bytes (1.0MB) copied, 0.001369 seconds, 730.5MB/s

書き込み先の容量が不足しています。この例では 1 MB の tmpfs を使い、コンテナ内で起きる状況を示しています。実際には、ホスト上の Docker のデータディレクトリがいっぱいになり、イメージのビルドやプル時に同じエラーが出ることのほうがよくあります。

解決方法：

docker system df で容量を何が使っているか確認し、ディスク容量を解放するの手順に従って整理します。
コンテナログが大きくなりすぎていないか確認し、ログの上限を設定します。
Docker Desktop では、Settings → Resources で仮想ディスクの上限を大きくできます。

Windows 固有のエラー

以下は PowerShell 7.4 で実行した結果です（同じ環境で動作を確認するため、PowerShell 公式イメージを使ってコンテナ内で pwsh を実行しています。そのため、コマンドの先頭に docker run ... pwsh -Command が付いています）。Windows PowerShell 5.1 ではメッセージの文言が少し異なりますが、原因は同じです。

Variable reference is not valid. ':' was not followed by a valid variable name character

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; mkdir /home/me/project -Force | Out-Null; Set-Location /home/me/project; Write-Output "$(pwd)/site:/app"; Write-Output "${PWD}/site:/app"'

/home/me/project/site:/app
/home/me/project/site:/app

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; Write-Output "$PWD:/app"'
ParserError:
Line |
   1 |  $PSStyle.OutputRendering="PlainText"; Write-Output "$PWD:/app"
     |                                                      ~~~~~
     | Variable reference is not valid. ':' was not followed by a valid
     | variable name character. Consider using ${} to delimit the name.

PowerShell で "$PWD:/app" と記述するとエラーになります。PowerShell は $PWD: を特殊な変数構文として扱うためです。"${PWD}:/app" と書けば正常に動作します。"$(pwd)/site:/app" という書き方も PowerShell で使えます（最初のコマンドでは、2 行の出力は同じです）。

Windows での書き方の詳しい比較は最初のコンテナを参照してください。

The '<' operator is reserved for future use

$ docker run --rm -e NO_COLOR=1 -w /home/me/project mcr.microsoft.com/powershell:latest pwsh -NoProfile -Command '$PSStyle.OutputRendering="PlainText"; docker exec -i mysql mysql app < app.sql'
ParserError:
Line |
   1 |  … OutputRendering="PlainText"; docker exec -i mysql mysql app < app.sql
     |                                                                ~
     | The '<' operator is reserved for future use.

PowerShell は < によるコマンドへのファイル入力をサポートしていません。そのため、チュートリアルにあるデータベース復元用の docker exec -i ... < backup.sql は PowerShell では実行できません。

解決方法：まず docker cp でファイルをコンテナにコピーし、コンテナ内でインポートします。この方法はどのシステムでも使えます。また、PowerShell 5.1 で > を使うとファイルが UTF-16 エンコードで保存される問題も避けられます。PostgreSQL の例を示します。

$ docker compose exec db psql -U app -c 'CREATE TABLE t (id int); INSERT INTO t VALUES (1),(2);'
CREATE TABLE
INSERT 0 2

$ docker compose exec db pg_dump -U app -Fc -f /tmp/app.dump app

$ docker compose cp db:/tmp/app.dump app.dump
 pgwin-db-1 Copying pgwin-db-1:/tmp/app.dump to app.dump
 pgwin-db-1 Copied pgwin-db-1:/tmp/app.dump to app.dump

$ ls -l app.dump
-rw-rw-rw-    1 root     root          1251 Oct 13 05:30 app.dump

$ docker compose exec db psql -U app -c 'DROP TABLE t;'
DROP TABLE

$ docker compose cp app.dump db:/tmp/restore.dump
 pgwin-db-1 Copying app.dump to pgwin-db-1:/tmp/restore.dump
 pgwin-db-1 Copied app.dump to pgwin-db-1:/tmp/restore.dump

$ docker compose exec db pg_restore -U app -d app /tmp/restore.dump

$ docker compose exec db psql -U app -c 'SELECT count(*) FROM t;'
 count
-------
     2
(1 row)

MySQL での方法はMySQLのバックアップの節を参照してください。

まとめ

エラーメッセージの最後にあるキーワードを確認し、docker ps -a と docker logs で状態を確認します。
ポートが使用中の場合や名前が競合している場合、失敗したコンテナが作成済みのことがあります。忘れずに docker rm を実行してください。
Windows では、スクリプトの改行コードを LF にし、実行権限を付与してください。そうしないと、誤解を招く no such file or directory や permission denied が表示されることがあります。
Compose の問題では、まず docker compose config を実行します。
PowerShell では ${PWD} を使い、< によるファイル入力は避けます。

よくある質問

エラーメッセージが長い場合、どこを見ればよいですか？

まず最後のコロンの後にある文を確認してください。そこに本当の原因が書かれていることが多く、たとえば port is already allocated や no such file or directory です。先頭の Error response from daemon や failed to create task は、どの層でエラーが発生したかを示しているだけです。

インターネットで見つけたエラーメッセージが、表示されたものと違うのはなぜですか？

Docker のエラーメッセージはバージョンによって変わります。たとえば旧バージョンの Cannot connect to the Docker daemon at unix:///var/run/docker.sock は、Docker 29 では failed to connect to the docker API at unix:///var/run/docker.sock に変わっています。最後のキーワードで検索すると、答えを見つけやすくなります。

docker run が失敗した後、もう一度実行すると名前が使用中と表示されるのはなぜですか？

ポートの競合など、多くのエラーが起きた時点でコンテナはすでに作成されており、起動に失敗しただけです。docker ps -a を実行すると、Created 状態のコンテナを確認できます。docker rm で削除してから、もう一度実行してください。

コンテナが終了した理由を確認するにはどうすればよいですか？

docker ps -a で STATUS の終了コードを確認し、docker logs コンテナ名 でプログラムの出力を確認します。また、docker inspect -f "{{.State.ExitCode}} {{.State.OOMKilled}}" コンテナ名 も実行してください。終了コード 137 は強制終了（SIGKILL またはメモリ不足）、1 は通常、プログラム自体のエラーを示します。

更新日 2026年10月13日