docker『Cannot Connect to the Docker Daemon』の原因と対処法
- 作成日 2025.11.06
- その他
Dockerクライアントがデーモンに接続できないときに出る代表的エラー。デーモン未起動、ソケット/ポート不一致、権限不足、環境変数やコンテキストの誤設定、WSL2・rootless・Docker Desktop特有の状態不整合などが主因。OS別の起動確認、接続先の正規化、権限の修復、ネットワーク/プロキシ確認、ログ診断の順で切り分ける。
- 1. 症状と発生条件(まず把握)
- 2. 最初に確認(共通クイックチェック)
- 3. Linux(systemd)での復旧
- 4. macOS(Docker Desktop)での復旧
- 5. Windows(WSL2/Hyper-V)での復旧
- 6. 権限エラー(permission denied / docker グループ)
- 7. DOCKER_HOST / context の誤設定を元に戻す
- 8. Unixソケットの破損・権限不整合の修復
- 9. rootless モード特有の落とし穴
- 10. HTTP プロキシ/Firewall/VPN の影響
- 11. Docker Desktop のファクトリリセット/リソース再割当(最終手)
- 12. デーモンログの読み方(原因の特定)
- 13. WSL2 連携の再構成(Windows で頻発する場合)
- 14. 再発防止の設定とヘルスチェック
症状と発生条件(まず把握)
・docker ps や docker info で「Cannot connect to the Docker daemon」や「Is the docker daemon running?」が表示される
・/var/run/docker.sock へ接続できない、あるいは TCP の DOCKER_HOST(例 tcp://127.0.0.1:2375)に到達できない
・デーモンが停止/クラッシュ、Docker Desktop/WSL2が未起動、権限不足、contextや環境変数の誤り、プロキシ/Firewallでブロック
最初に確認(共通クイックチェック)
# 1) クライアントと接続先の現在値を確認
docker context ls
docker context show
echo "DOCKER_HOST=$DOCKER_HOST DOCKER_CONTEXT=$DOCKER_CONTEXT"
# 2) デーモンの起動状態をOS別に確認
# Linux
sudo systemctl status docker
# macOS / Windows は Docker Desktop のUI起動を確認
# 3) ソケット/ポートに触れるか
ls -l /var/run/docker.sock 2>/dev/null || echo "no unix socket"
nc -vz 127.0.0.1 2375 2>/dev/null || echo "no tcp 2375 (if using tcp)"
# 4) 権限・グループ
id -nG | tr ' ' '\n' | grep -x docker || echo "not in docker group"
Linux(systemd)での復旧
# デーモン起動・自動起動設定
sudo systemctl enable --now docker
# 起動ログの要点を確認(直近)
journalctl -u docker -n 200 --no-pager
# 設定変更後はリロード→再起動
sudo systemctl daemon-reload
sudo systemctl restart docker・起動しないときは /etc/docker/daemon.json の文法やポート競合、ストレージドライバの警告をログで確認
macOS(Docker Desktop)での復旧
# CLI からの強制再起動(macOS)
osascript -e 'quit app "Docker"' ; sleep 2 ; open -a Docker
# エンジン再起動は Docker Desktop の Troubleshoot → Restart でも可・スペース不足や更新直後の移行待ちで時間がかかる場合がある
・設定の「Use Rosetta」「VPN Kit」「HTTP proxy」変更の影響を確認
Windows(WSL2/Hyper-V)での復旧
# WSL2 側でのサービス確認(dockerd を使う構成の場合)
wsl -l -v
wsl.exe -d Ubuntu -- sh -lc "ps aux | grep dockerd"
# Docker Desktop のエンジン再起動
"%ProgramFiles%\\Docker\\Docker\\DockerCli.exe" -SwitchLinuxEngine
"%ProgramFiles%\\Docker\\Docker\\DockerCli.exe" -SwitchWindowsEngine
# WSL ネットワーク/ディストリ再起動
wsl --shutdown
wsl --unregister <不要なDistro名> # ※注意:消えるので通常は不要
・Windows のサービス「Docker Desktop Service」が停止していないか確認
・企業向けセキュリティ製品でのブロックやポリシーを確認
権限エラー(permission denied / docker グループ)
# 自ユーザーを docker グループへ追加(Linux)
sudo usermod -aG docker "$USER"
# 反映(ログインし直す/新しいログインシェル)
newgrp docker
# 確認
id -nG | tr ' ' '\n' | grep -x docker && docker ps・一時的には sudo docker ps で動くが、恒久対応はグループ参加
・/var/run/docker.sock の所有とモードが壊れていたら修正(通常は root:docker の 660)
DOCKER_HOST / context の誤設定を元に戻す
# 環境変数を無効化
unset DOCKER_HOST DOCKER_CONTEXT
# default コンテキストに戻す
docker context use default
# 現在の接続先を明示確認
docker context inspect --format '{{json .Endpoints.docker}}' | jq .・rootless やリモートデーモン利用後に環境変数が残っていると「繋がるはずのソケット」に繋げない
Unixソケットの破損・権限不整合の修復
# ソケットの存在と所有権
ls -l /var/run/docker.sock
# 期待値:srw-rw---- 1 root docker ... /var/run/docker.sock
# おかしい場合は dockerd を再起動(直接 chmod での調整は最小限に)
sudo systemctl restart docker
# どうしても必要な緊急回避(再起動後は元に戻すこと)
sudo chgrp docker /var/run/docker.sock
sudo chmod 660 /var/run/docker.sock・ソケットそのものが無ければ dockerd が落ちているか、別パスを使っている
rootless モード特有の落とし穴
# rootless が有効なユーザー側で環境を再ロード
systemctl --user status docker
systemctl --user restart docker
# 必要な環境変数を再読み込み(インストール時のメッセージ参照)
grep -E 'DOCKER_HOST|XDG_RUNTIME_DIR' ~/.bashrc ~/.profile ~/.zshrc・rootless では DOCKER_HOST=unix:///run/user/UID/docker.sock を使う
・OS の cgroup 設定や unprivileged ports の制限で起動に失敗することがある
HTTP プロキシ/Firewall/VPN の影響
# daemon 側のプロキシ設定(Linux /etc/systemd/system/docker.service.d/proxy.conf)
[Service]
Environment="HTTP_PROXY=http://proxy:8080" "HTTPS_PROXY=http://proxy:8080" "NO_PROXY=localhost,127.0.0.1,::1,registry.local"
# 反映
sudo systemctl daemon-reload && sudo systemctl restart docker・プロキシ設定は「クライアント」と「デーモン」の双方で整合を取る
・VPN や ZTNA でローカルソケット/ポートへのアクセスが妨げられる例がある
Docker Desktop のファクトリリセット/リソース再割当(最終手)
# データ消去を伴うため事前にイメージ/ボリュームのバックアップを検討
# macOS/Windows: Docker Desktop → Troubleshoot → Clean / Reset to factory defaults・メモリ/CPU/ディスク容量を再割当してエンジン起動を安定化
デーモンログの読み方(原因の特定)
# Linux
journalctl -u docker --since "1 hour ago" --no-pager
# Desktop
# 画面右上 Troubleshoot → Support → "Get Support" から診断バンドルを取得
・storage driver, network, cgroup, aufs/overlay2 のエラー、iptables 失敗、証明書/レジストリ認証の警告を探す
WSL2 連携の再構成(Windows で頻発する場合)
# 連携をリセット
wsl --shutdown
# Docker Desktop → Settings → Resources → WSL Integration で対象Distroのチェックを入れ直す
# Distro から docker へ PATH が通っているか確認
wsl.exe -d Ubuntu -- sh -lc "which docker && docker version"
・/etc/resolv.conf の上書き、時計ずれ、アンチウイルスの干渉も疑う
再発防止の設定とヘルスチェック
# 自動起動
sudo systemctl enable docker
# 簡易ヘルスチェック(CIなどで)
docker version || exit 1
docker info || exit 1・contextとDOCKER_HOSTを明示的に管理し、スクリプトの先頭で検証
・ボリューム/ネットワーク/レジストリの可用性を監視に組み込む
-
前の記事
docker/k8s『Image Pull BackOff』の原因と対処法 2025.11.05
-
次の記事
GAS『Service Error: Drive』の原因と対処法 2025.11.06
コメントを書く