适用：使用 systemd 的 Linux 服务器、常规 rootful Docker Engine；Compose 示例使用
docker composeV2。本文为教学故障场景，错误文本和结果为示意，具体输出以现场为准。
一、遭遇情况：同一台机器，两个人执行结果不同
新同事登录服务器，运行 docker ps 时看到：
permission denied while trying to connect to the Docker daemon socket
at unix:///var/run/docker.sock
改成 sudo docker ps 后能列出容器。于是有人提议把 socket 改成 777。这可能让报错消失，却把控制 Docker 的能力交给了本机所有用户，也没有解释为何原来拒绝访问。
本篇场景是常规 rootful Docker Engine，socket 由 root 和 docker 组管理，当前用户没有所需组权限。不是容器内挂载目录的权限故障，后者见第 12 篇。
二、原因分析：访问 socket 也是一次文件权限检查
Linux 上的 Unix socket 有拥有者、所属组和权限位。Docker 客户端需要打开这个入口，才能向后台发送操作。典型权限类似：
srw-rw---- root docker ... /var/run/docker.sock
root 和 docker 组成员有读写权限，其他用户没有。实际拥有者、路径和权限以现场为准，不能因为与示例不同就直接改。
三、排查思路：用对照实验缩小范围
1. 先确认 sudo 前后连接的是同一个服务
docker context show
docker context inspect
sudo docker context show
sudo docker context inspect
env | grep -E '^DOCKER_(HOST|CONTEXT)='
sudo 可能使用 root 的客户端配置，也可能清除环境变量。如果普通用户连远程 daemon，而 sudo 连本机，那么“sudo 成功”不能直接证明是同一个 socket 的权限问题。先核对目标，再继续比较。
2. 查看入口与用户身份
ls -l /var/run/docker.sock
id
getent group docker
sudo systemctl is-active docker
getent group docker 反映系统用户组信息，id 反映当前会话实际携带的组。刚加入用户组后，旧 SSH 会话可能仍未更新，这能解释“管理员说已经加组，为什么还是报错”。
如果 socket 路径不存在，优先检查服务和 context；如果 root 也无法连接，就不能只围绕普通用户权限处理。
四、修复实践：选择符合服务器授权方式的方案
方案 A：使用已经获准的 sudo 操作
sudo docker ps
在通过 sudo 管理 Docker 的服务器上，这可能已经是正确方式。是否给予某人 Docker 管理能力，要遵循现有授权安排，不是为了少打一个单词就改变权限。
方案 B：允许目标账号管理 Docker 时加入用户组
以下假定目标运维账号名为 opsuser，要先替换并确认它确实存在：
getent passwd opsuser
getent group docker
sudo usermod -aG docker opsuser
-aG 表示追加到附加组，少写 -a 可能覆盖原有附加组。若系统没有 docker 组，应先查安装方式和服务设计，不要机械创建后就认定问题解决。
完成后退出该账号的旧 SSH 会话，重新登录，再执行 id 和 docker ps。也可以用 newgrp docker 开启带新组身份的子 shell，但要理解它只影响相应会话。
Docker 官方说明，docker 组具有接近 root 的管理能力，因为成员可以操作宿主机相关资源。因此它不是普通的“只读查看容器”权限组。若需要细分权限，应由平台层或专门的授权方案实现，不能把所有用户都加进去。
五、为什么不使用 chmod 666 或 777
修改 socket 为所有用户可写，扩大了服务器管理入口；服务重启后权限还可能被重建，问题表面上反复出现。正确修复对象是授权与会话，而不是把入口改成谁都能访问。
如果异常权限来自系统服务配置、手动修改或安装混乱，应找到来源并恢复该安装方式的正常管理规则。不要在不知道原因时直接 chown socket，更不要把业务容器挂上 Docker socket 来“解决部署权限”。
六、验证：分别确认身份与功能
id
docker version
docker ps
确认当前会话出现预期组、Server 连接成功、能看到预期服务器的容器。若仍然报错，对照 socket 所属组、context 和新旧会话逐项复查。
若是 ~/.docker/config.json 所有者异常，则是另一个文件权限问题，可先查看 ls -ld ~/.docker 与 ls -l ~/.docker/config.json，仅修正有证据的目标，避免递归改变整个家目录权限。
七、总结：权限问题要修授权，不是取消权限
排查顺序是：核对目标 → 对照 sudo → 查看 socket → 查看当前会话组 → 按授权调整 → 新会话验证。把“能运行命令”与“应该拥有管理权限”同时想清楚，才算完成修复。