テクノロジー · 実用ガイド

Docker daemon socket が permission denied？クライアント・socket・daemon を先に証明

docker.sock を 666/777 にしません。クライアント ID、Docker context、正確な socket を固定し、rootful・rootless・コンテナへのマウントを分けて最小の主体だけを認可します。

執筆 Watch at Ease News · 3 分で読めます公開 2026/10/17 22:36 UTC

Docker の Unix socket で permission denied なら、クライアントプロセスがその pathname 境界を越えられません。daemon 停止や /var/run/docker.sock 選択を証明するものではありません。

クライアント ID、context、DOCKER_HOST、socket 情報を保存します。rootful ホスト daemon、rootless user daemon、コンテナ内のマウントを分類してからアクセスを変えます。

クライアント ID と選択 endpoint を固定

完全なエラー、command、有効 UID、補助 group を記録します。sudo や group 編集前に docker context show、DOCKER_HOST、解決済み endpoint を保存します。

正確な pathname の owner、group、mode、親 directory を名前と数値で調べます。pathname 不在は permission denied と別の分岐です。

rootful Linux daemon は root 所有 socket を docker group に開けます。この group は便利 group でなく特権管理として扱います。

rootless では user socket と context を確認します。CI や application container では mount した host socket と名前空間を分けます。

socket の数値 GID と実際に Docker を起動する process group を比較します。/etc/group の編集は既存 shell、IDE、agent、daemon の資格を変えません。

mount socket では両側の docker という名前が同じでも番号が違います。host socket を application user 所有に変えず、caller 側で GID を設計します。

rootful group access が承認済みなら必要な人・service だけを追加し、その session を更新します。恒久 root 相当が広すぎるなら rootless や隔離環境を検討します。

chmod 666/777 を恒久修復にしません。world-write は無関係な local process に強力な API を開き、daemon restart で管理 mode に再生成される場合もあります。

同じ caller から docker context show と docker info または docker version を実行し、context、server、rootless security option を確認します。sudo だけの成功は資格差の証拠です。

承認済み workload を一つ実行します。非 world-write socket が意図した主体だけに動き、無関係な非特権主体を拒否して初めて完了です。