Docker daemon 启动失败并报错 socket unix 权限拒绝，通常是因为当前用户不在 docker 用户组内，或者 Docker 服务未运行。最推荐的处理方向是先将当前用户加入 docker 组，风险边界在于加入该组等同于获得 root 权限，需确保操作账户可信。

命令速用版

如果确定 Docker 服务已运行，仅需修复权限，可按顺序执行以下命令。

sudo systemctl status docker
sudo usermod -aG docker $USER
newgrp docker
docker info

如果服务未运行，先执行sudo systemctl start docker。

为什么会这样

Docker 客户端通过 Unix Socket 文件与守护进程通信，该文件默认只允许 root 和 docker 组用户访问。报错 permission denied 表示当前用户既不是 root 也不在 docker 组内，无法读写/var/run/docker.sock 文件。这是 Linux 文件权限机制的正常行为，旨在防止普通用户随意控制容器引擎。

分步处理

步骤 1：检查 Docker 服务状态
执行systemctl is-active docker。如果返回 inactive 或 failed，先执行sudo systemctl start docker。如果服务无法启动，需查看journalctl -u docker排查服务本身错误，而非权限问题。

步骤 2：确认当前用户组
执行groups命令。如果输出中不包含 docker，说明当前用户缺少组权限。这是导致 socket 权限拒绝的最常见原因。

步骤 3：添加用户到 docker 组
执行sudo usermod -aG docker $USER。该命令将当前登录用户追加到 docker 组，不需要移除原有组。操作完成后，权限变更不会立即在当前 shell 会话生效。

步骤 4：刷新组权限
执行newgrp docker或退出当前终端重新登录。直接使用sudo docker可以临时绕过此问题，但长期建议配置组权限以避免每次输入密码。

怎么验证是否生效

执行docker run `--rm` hello-world。如果能看到 Hello from Docker! 输出且无 permission denied 报错，说明 socket 权限已修复。也可执行docker info，如果正常返回服务器信息而非客户端错误，即验证通过。

常见坑

1. 修改组后未重新登录：执行usermod后直接在原终端测试仍会报错，必须执行newgrp或重新 SSH 登录。
2. 暴力修改 Socket 权限：不要执行chmod 777 /var/run/docker.sock，这会重置 systemd 管理的权限且存在安全风险，重启服务后会失效。
3. Rootless 模式路径不同：如果使用 Rootless Docker，Socket 路径通常在$XDG_RUNTIME_DIR/docker.sock，权限配置方式与标准模式不同。

常见问题

为什么加了组还是提示权限拒绝？

因为 Linux 组权限变更需要新会话生效。请执行newgrp docker命令刷新当前 shell 的组信息，或者关闭终端重新登录。

使用 sudo docker 可以绕过这个问题吗？

可以。使用sudo提权后能以 root 身份访问 Socket，但每次命令都需要输入密码，不适合脚本自动化或频繁操作场景。

重启 Docker 服务能解决权限问题吗？

不能。重启服务会重建 Socket 文件，但默认所有者和组依然是 root:docker。如果用户不在 docker 组内，重启后依然会报权限拒绝。

参考来源

• Docker Official Documentation, Manage Docker as a non-root user, https://docs.docker.com/engine/install/linux-postinstall/