時期も時期ですのでよく使うツールのトラブルシューティングを簡単にまとめました。
自分も触り始めや過去にやらかしたりしたことあるものを中心にざっくりとあつめたので何かの参考になればと。
エラー① Cannot connect to the Docker daemon
エラーメッセージ
Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?原因
Dockerデーモン（Dockerの本体となるバックグラウンドプロセス）が起動していない状態でコマンドを叩いたときに出ます。PCを再起動した直後や、Docker Desktopを閉じたまま作業しようとしたときによく遭遇します。
解決策
Mac / Windows（Docker Desktop使用の場合）
Docker Desktopのアプリを起動するだけでOKです。タスクトレイやメニューバーにクジラのアイコンが表示されていればデーモンが起動しています。
Linux（systemdの場合）
bash
# Dockerサービスを起動
sudo systemctl start docker
# PC再起動後も自動起動させたい場合
sudo systemctl enable dockerエラー② port is already allocated
エラーメッセージ
Error response from daemon: driver failed programming external connectivity on endpoint ...:
Bind for 0.0.0.0:8080 failed: port is already allocated原因
指定したポート（例：8080）がすでに別のプロセスに使われています。以前に起動したコンテナが残っていたり、別のアプリが同じポートを使っているケースがほとんどです。
解決策
方法1：そのポートを使っているプロセスを確認して終了する
bash
# Mac / Linux
lsof -i :8080
# Windows（PowerShell）
netstat -ano | findstr :8080表示されたPIDを使ってプロセスを終了します。
方法2：使うポートを変更する
docker run や docker-compose.yml のポート番号を変えるのが一番手っ取り早いです。
bash
# 8080が使われているなら8081を使う
docker run -p 8081:80 nginxyaml
# docker-compose.yml
ports:
- "8081:80" # ← ホスト側のポートを変えるエラー③ No space left on device
エラーメッセージ
Error response from daemon: no space left on device原因
Dockerが使えるディスクスペースが足りなくなっています。使わなくなったイメージやコンテナ、ボリュームが積み重なってディスクを圧迫しているのが主な原因です。長く使っていると意外とあっさり起きます。
解決策
まずどれくらいの容量が使われているか確認します。
docker system df不要なリソースをまとめて削除するには以下のコマンドが便利です。
bash
# 停止中コンテナ・未使用イメージ・未使用ネットワーク・未使用ボリュームを一括削除
docker system prune -a --volumes⚠️
--volumesをつけるとボリュームも削除されます。DBのデータなど必要なものが消えないか確認してから実行しましょう。
こまめに docker system prune を実行する習慣をつけておくと、ディスク不足を防げます。
エラー④ permission denied
エラーメッセージ（パターンA：Dockerコマンド自体に権限がない）
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sockエラーメッセージ（パターンB：コンテナ内のファイルに権限がない）
permission denied: ./entrypoint.sh原因と解決策
パターンA：Linuxでsudoなしでdockerを実行しようとしている
LinuxではデフォルトでrootユーザーしかDockerを操作できません。自分のユーザーをdockerグループに追加することで解決します。
bash
sudo usermod -aG docker $USER
# 変更を反映するためにログアウト&ログイン（またはターミナルを再起動）パターンB：コンテナ内のファイルに実行権限がない
Dockerfileで追加したシェルスクリプトなどに実行権限がついていないケースです。
dockerfile
# Dockerfileに追加
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.shエラー④ permission denied
エラーメッセージ（パターンA：Dockerコマンド自体に権限がない）
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sockエラーメッセージ（パターンB：コンテナ内のファイルに権限がない）
permission denied: ./entrypoint.sh原因と解決策
パターンA：Linuxでsudoなしでdockerを実行しようとしている
LinuxではデフォルトでrootユーザーしかDockerを操作できません。自分のユーザーをdockerグループに追加することで解決します。
bash
sudo usermod -aG docker $USER
# 変更を反映するためにログアウト&ログイン（またはターミナルを再起動）パターンB：コンテナ内のファイルに実行権限がない
Dockerfileで追加したシェルスクリプトなどに実行権限がついていないケースです。
dockerfile
# Dockerfileに追加
COPY entrypoint.sh /entrypoint.sh
RUN chmod +x /entrypoint.shエラー⑤ コンテナが起動してすぐ終了する
症状
docker run を実行するとコンテナが立ち上がるが、docker ps で確認すると何も表示されない。docker ps -a だと Exited になっている。
原因
コンテナはメインプロセスが終了すると自動的に止まる仕組みになっています。バックグラウンドで動かすつもりがフォアグラウンドで動いていなかったり、エントリポイントのコマンドがエラーで落ちていたりします。
解決策
まずログを確認してエラーの原因を調べます。
bash
# 終了したコンテナのログを確認
docker logs <コンテナID or コンテナ名>インタラクティブに起動してコンテナ内を直接確認したいときはこちら。
bash
docker run -it <イメージ名> /bin/bashdocker-compose の場合はフォアグラウンドで起動して出力を確認するのが有効です。
bash
docker-compose up # -d をつけずに実行エラー⑥ image not found / タグ指定ミス
エラーメッセージ
Unable to find image 'myapp:lastest' locally
Error response from daemon: manifest for myapp:lastest not found: manifest unknown原因
タグ名のスペルミスが最も多いです。latest を lastest と書いてしまうのは定番のやらかしです。また、ローカルにそのイメージが存在しない・Docker Hubに該当のタグが存在しない場合も同じエラーが出ます。
解決策
bash
# ローカルに存在するイメージ一覧を確認
docker images
# イメージを明示的にpullして確認
docker pull nginx:latestdocker-compose.yml などのタグ名を見直して、スペルミスがないか確認しましょう。特に latest の打ち間違いは肉眼で見つけにくいため注意が必要です。
エラー⑦ ボリュームの変更が反映されない
症状
docker-compose.yml でボリュームをマウントしているのに、ホスト側でファイルを変更してもコンテナ内に反映されない。
原因
よくあるのは以下の2パターンです。
- コンテナを再起動していない（イメージを再ビルドしないと反映されないと勘違い）
docker-compose.ymlのマウント設定のパスが間違っている
解決策
まずボリューム設定を確認する
yaml
# docker-compose.yml
services:
app:
volumes:
- ./src:/app/src # ホスト側:コンテナ側パスはプロジェクトルートからの相対パスになります。誤っていないか見直しましょう。
コンテナを再起動して確認する
bash
docker-compose down
docker-compose upボリュームマウントの変更はコンテナの再起動で反映されます（イメージの再ビルドは不要です）。
コンテナ内に入って実際にファイルを確認する
bash
docker exec -it <コンテナ名> /bin/bash
ls /app/src # マウント先を直接確認まとめ
Dockerのエラーで困ったときの基本的な調査の流れをまとめます。
docker logs <コンテナ名>でログを確認するdocker ps -aでコンテナの状態を確認するdocker exec -it <コンテナ名> /bin/bashでコンテナ内に入って直接調べるdocker system dfでディスク使用量を確認する
エラーメッセージをそのままGoogle検索するだけでも大抵は解決策が見つかります。最初は慌てず、まずログを読む習慣をつけることが大切です。
慣れてくるとDockerは本当に便利なツールなので、ぜひ使いこなしていきましょう！
ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。
- 選考ではありません
- 履歴書不要
- 技術の話が中心
- 所要時間30分程度
- オンラインOK
