Docker daemonに接続できない・Permission deniedの原因と安全な確認手順
Cannot connect to the Docker daemonやpermission denied while trying to connectが出たときに、接続先の違い・daemon状態・ソケットの権限を切り分けます。コンテナ内アプリの起動失敗とは別の問題です。
この記事の目的
接続先の設定、Docker Engine・rootlessモード、UNIXソケット権限を変更せずに確認します。
まず確認すること
docker context show、docker context inspect、docker versionを確認して接続先を特定します。
web01・app-data・ポート番号などは説明用です。Docker context・対象コンテナ・データ保存先を照合してください。関連ガイド
Docker基本操作
コンテナの状態確認、起動・停止、接続先の基本操作へ戻ります。
ガイドへ →DockerDockerコンテナ起動失敗
Exited・Restarting・OOMKilledなどの終了原因を切り分けます。
ガイドへ →DockerDockerのport is already allocated
対象と原因を絞り、変更前後の確認手順へ進みます。
ガイドへ →1. エラー文から接続経路を分類
| エラー例 | 最初の確認先 |
|---|---|
| Cannot connect to the Docker daemon | Docker context・DOCKER_HOST・daemonの実行状態 |
| permission denied ... docker.sock | CLI実行ユーザー・ソケット所有者とアクセス権 |
| connection refused | 接続先アドレス・ソケット・リモートdaemonの状態 |
| error loading config.json: permission denied | ユーザーの~/.docker所有者・権限 |
| TLS / SSH authentication failed | リモート認証・証明書・接続先と権限 |
Docker Desktop、通常のrootful Docker Engine、rootless Engineでは、接続先ソケットやサービス管理方法が違います。
2. 実際のDocker接続先を調べる
DOCKER_HOSTはCLIの接続先を上書きする場合があります。docker contextで選んだ対象と一致しないときは、環境変数・CLIオプション・コンテキスト優先順位を調べます。勝手にcontext use defaultへ切り替えると操作先が変わるため、作業前の変更管理が必要です。
3. UNIXソケットの所有者・権限
docker.sockが存在しない、または別パスならrootless Engine・Docker Desktop・リモート接続などの可能性もあります。systemctl statusが見られない構成や、Dockerが別のサービス名で管理される構成もあります。
chmod 666 /var/run/docker.sockなどの全員書き込み許可は避けてください。Docker daemon制御権限はホスト上で非常に強い権限となります。4. dockerグループを使う前のセキュリティ確認
Docker公式はdockerグループに属する利用者が実質的にroot相当の権限を得ることを説明しています。管理者が認めたユーザーだけに権限を与え、付与方法・監査ログ・代替手段（rootless、限定された運用経路）を検討します。
現在のユーザーのグループ所属はidで確認できます。sudoを付ければ解決、dockerグループ追加が正解、と機械的に判断しないことが重要です。
5. rootless・リモートDockerでは確認点が変わる
rootlessはユーザーサービス・ユーザーごとのソケットを利用する構成が多く、rootful Engine用の/var/run/docker.sockを前提に調査すると誤診します。リモートDockerならSSH/TLSの認証と接続先ホストの権限を確認します。
6. 変更後は接続先と影響範囲を再確認
権限・daemon・contextを変更した場合、意図したDocker Engineへ接続できるかを確認します。docker psが成功しても、別ホストを操作している可能性があるため、接続先を必ず明示的に照合してください。
接続後にコンテナがすぐ終了する場合はDockerコンテナ起動失敗の原因確認へ切り替えます。
7. 接続方式ごとに復旧条件を固定する
| 接続方式 | 確認対象 | 完了条件 |
|---|---|---|
| Linux rootful | context、Unix socket、docker.service、利用ユーザーの権限 | 意図したdaemonに接続でき、権限緩和せず対象コンテナ一覧を確認 |
| Linux rootless | ユーザー単位のsocket、systemctl --user、実行ユーザーと環境変数 | rootful側を誤操作せず、正しいユーザーEngineに接続 |
| remote（SSH/TLS） | 接続先ホスト、資格情報、SSH/TLS設定と認証 | 暗号化・認証を維持したまま対象ホストへ接続 |
障害前のcontextやユーザー権限を記録していない場合は、復旧前に運用管理者へ対象Engineを確認してください。エラー解消のためにchmod 666や無認証TCP公開へ切り替えることはしません。
8. 接続失敗の結果別対処
CLIがインストールされていても、Engineが稼働しているとは限りません。まず接続先と権限を参照操作で分けます。例はLinuxのrootful Engine向けで、Docker Desktopやrootlessでは確認対象が変わります。
| 調査結果 | 次に必要な対処・判断 |
|---|---|
daemonがinactiveでrootful systemd管理 | systemctl status dockerとjournalctl -u dockerで停止理由を確認。管理者が復旧を承認した場合だけサービス起動を検討 |
daemonはactiveだがpermission denied | 現在のユーザーの所属グループとsocket所有権を照合。運用管理者に権限設計を確認し、無条件にグループ追加・権限緩和しない |
| context/DOCKER_HOSTが期待と違う | 誤ったDocker Engineを操作しないよう対象ホストを確認し、接続設定の管理元から修正 |
socketがなくsystemctlも対象外 | rootlessのユーザーsocket・サービスやDocker Desktop/remote接続を確認し、rootful用の修正を適用しない |
| SSH/TLS認証エラー | 資格情報の管理元、接続先の証明書期限・SSH権限を確認。TLS無効化・無認証TCP公開は行わない |
9. 変更前の安全確認と復旧判定
次は、rootful Docker Engineが停止しており、管理者が起動を承認した場合に限る例です。daemon起動でコンテナや公開ポートが復活する場合があるため、業務影響とRestartPolicyを事前確認します。
| 結果 | 完了・次の判断 |
|---|---|
| Docker ClientとServerの双方が表示され、contextも対象ホストと一致 | daemon接続は復旧候補。必要なコンテナと意図しない外部公開がないことを確認 |
| Clientだけ表示されServerへ接続できない | 未解決。daemonログ・socket・環境変数・rootless/remoteの切り分けへ戻る |
| daemonへ接続できるがコンテナはExited | 接続は復旧、アプリは別障害。コンテナ起動失敗を調査 |
chmod 666 /var/run/docker.sock、root相当のdockerグループへの無条件追加、認証なしTCP接続の公開。設定変更に失敗した場合は管理者が変更元へ戻し、アクセス制御を再検証してください。