科技 · 实用指南
Docker 守护进程套接字“权限被拒绝”？先证明客户端、套接字与守护进程环境
不要把 docker.sock 设为 666 或 777。先固定客户端身份、Docker context 与准确套接字，区分 rootful、rootless 和容器挂载场景，再只授权需要的主体。
Docker Unix 套接字的权限错误表示客户端进程无法跨过这个路径边界；它不证明守护进程已停止，也不证明当前端点就是 /var/run/docker.sock。
保存准确客户端身份、context、DOCKER_HOST 与套接字元数据。先区分 rootful 主机守护进程、rootless 用户守护进程或容器内挂载套接字。
固定客户端身份与选中端点
记录完整错误、命令、有效 UID 与附加组。保存 docker context show、DOCKER_HOST 和解析后的端点，再使用 sudo 或改组。
用数值和名称检查准确路径的所有者、组、模式与父目录。路径不存在与权限被拒绝是不同分支。
区分 rootful、rootless 与挂载套接字
rootful Linux 守护进程可能向 docker 组开放 root 所有的套接字。把该组视为特权管理，而非普通便利组。
rootless 模式要确认用户套接字与 context。CI 或应用容器内要识别挂载的宿主套接字，并分开宿主与容器命名空间。
证明当前进程凭据与数值 GID
比较套接字数值 GID 与实际启动 Docker 的进程有效组。编辑 /etc/group 不会改变已有 shell、IDE、agent 或 daemon 的凭据。
挂载场景中两边都叫 docker 仍可能编号不同。应在调用者边界内有意映射 GID，而不是把宿主套接字改给应用账户。
选择最小的预期授权边界
若批准 rootful docker 组访问，只加入需要的人或服务并刷新其会话。若永久 root 等价权限过宽，评估 rootless 或隔离环境。
不要把 chmod 666/777 当持久修复。世界可写会让无关进程调用高权限 API，且守护进程重启还可能重建套接字。
验证预期守护进程且不隐藏边界
在同一调用者内运行 docker context show 与 docker info 或 docker version，确认 context、server 与 rootless 标志。仅 sudo 成功只证明凭据不同。
再运行一项获准工作负载。只有预期主体可用非世界可写套接字，而无关低权限主体仍被拒绝时才结案。
