科技 · 實用指南
Docker daemon socket「權限被拒」？先證明用戶端、socket 與 daemon 環境
不要把 docker.sock 設成 666 或 777。先固定用戶端身分、Docker context 與正確 socket，區分 rootful、rootless 和容器掛載，再只授權需要的主體。
Docker Unix socket 的權限錯誤表示用戶端程序無法跨越這個路徑邊界；它不證明 daemon 已停止，也不證明端點就是 /var/run/docker.sock。
保存用戶端身分、context、DOCKER_HOST 與 socket 中繼資料。先區分 rootful 主機 daemon、rootless 使用者 daemon 或容器內掛載 socket。
固定用戶端身分與選定端點
記錄錯誤、命令、有效 UID 與附加群組。保存 docker context show、DOCKER_HOST 與解析端點，再使用 sudo 或變更群組。
以名稱和數值檢查準確路徑的擁有者、群組、模式與父目錄。路徑不存在是另一個分支。
區分 rootful、rootless 與掛載 socket
rootful Linux daemon 可把 root 擁有的 socket 開放給 docker 群組。此群組是特權管理，不是普通便利群組。
rootless 模式要確認使用者 socket 與 context。CI 或應用容器須辨識掛載的宿主 socket，分開宿主與容器命名空間。
證明程序憑證與數值 GID
比較 socket 數值 GID 與真正啟動 Docker 的程序群組。修改 /etc/group 不會改寫現有 shell、IDE、agent 或 daemon 的憑證。
掛載情境下兩邊同名 docker 仍可能編號不同。應在呼叫端刻意映射 GID，而不是把宿主 socket 改給應用帳號。
選擇最小的預期授權邊界
若核准 rootful docker 群組，只加入需要的身分並刷新其工作階段。若永久 root 等價權限太廣，評估 rootless 或隔離環境。
不要把 chmod 666/777 當成持久修復。世界可寫會讓無關程序呼叫高權限 API，daemon 重啟也可能重建 socket。
驗證預期 daemon 而不隱藏邊界
由相同呼叫者執行 docker context show 與 docker info 或 docker version，確認 context、server 與 rootless 標記。只有 sudo 成功只證明憑證差異。
再執行一項核准的工作負載。預期主體可用非世界可寫 socket，而無關低權限身分仍被拒絕，才算完成。
