极客工场

Appearance

共 2,431 字预计阅读约 8 分钟

docker permission denied while trying to connect daemon socket：OpenLane 跑不起来速查 ​

更新时间：2026-10-24。FAQ 速查页，属于开源 EDA 排错系列。按 OpenLane Docker 安装实录 装完环境，第一次跑 flow.tcl 或先手敲 docker ps 验证，迎面就是一句 permission denied——这不是 OpenLane 的问题，是 Docker 自己的 socket 权限模型在拦人。同类权限报错在商用工具侧的对照见 Design Compiler Permission denied。

答案块（赶时间先看这里）

  • 报错原文：permission denied while trying to connect to the docker API at unix:///var/run/docker.sock
  • 环境：Ubuntu 22.04，Docker 已装好，OpenLane 准备首跑
  • 根因：/var/run/docker.sock 属主是 root:docker、权限 0660——只有 root 和 docker 组成员能连，当前用户不在这个组里
  • 修复：sudo usermod -aG docker $USER，然后退出重新登录（组变更不对已开的 shell 生效）
  • 验证：重新登录后 docker ps 能正常返回表头即修复成功

本文要回答的问题 ​

  • 报错里的 unix:///var/run/docker.sock 是什么？为什么连它要权限？
  • 明明 usermod 加过组了，为什么还是 permission denied？
  • 用 sudo docker 能跑通，为什么反而是个坑？
  • OpenLane 场景下这个坑为什么会二次咬人（runs/ 目录清不掉）？

一、报错原文与现象 ​

bash
$ docker ps
permission denied while trying to connect to the docker API at unix:///var/run/docker.sock

典型触发路径：新装一台云主机或新建一个用户，按教程装完 Docker、拉好 efabless/openlane 镜像，敲第一条 docker 命令验证环境——直接被拒。报错里没有任何 OpenLane 字样，所以很多人第一反应是「OpenLane 装错了」，跑去重装镜像，白等半小时。其实线索全在报错原文里：它说的是连 docker API 的 socket 文件被拒，跟镜像、跟 OpenLane 一点关系都没有。

新用户直接 docker ps 实录：组里没 docker，连接当场被拒

上面这张实录抓住关键事实：id 输出的组列表里只有 tnew 自己没有 docker，紧跟其后的 docker ps、docker images 双双报 permission denied——被拒的不是某一条命令，而是这个用户连 socket 的资格。看懂这两行，根因已经解完了一半。

二、根因：socket 文件的 root:docker 0660 权限模型 ​

Docker 客户端（docker 命令）本身不干活，它是通过 Unix socket /var/run/docker.sock 把请求发给后台的 dockerd 守护进程。这个 socket 文件的属主和权限位由 dockerd 启动时创建，默认就是：

text
srw-rw---- 1 root docker 0 Oct 20 18:21 /var/run/docker.sock

s 开头表示这是一个 socket 文件，rw-rw---- 即 0660：属主 root 可读写、属组 docker 可读写、其他人无任何权限。你的普通用户账号不在这个组里时，连 connect() 这一步都被内核拒绝，于是客户端原样抛出那句 permission denied。

为什么 Docker 要设计成这样？因为连上这个 socket 就等于拿到了 root——dockerd 以 root 身份运行，能挂载宿主机任意目录、改宿主机任意文件。所以发行版默认不开放给「other」，而是用 docker 组做一层显式授权：管理员把谁加进组，谁就获得了与 root 等效的能力。这也解释了为什么官方文档把「加 docker 组」和「信任该用户为 root」画等号——这台机器只给你一个人用时没差别，多人共用的 EDA 服务器上加组前要先想清楚。

eda/ts-openlane-docker-permission-denied.md D2 示意图

颜色按语义分角色：蓝是排查动作（id 查组）、红是命中的问题（不在组、报错原文）、灰是中性系统组件（socket 文件与 dockerd）、橙是修复动作、绿是通过分支。这张图的主线一句话：客户端连 daemon 的唯一通道是那个 socket 文件，能不能过只看你在不在 docker 组。所以排查方向永远收敛到「组」上，不用去翻 OpenLane 的配置。

三、三个场景的对照清单 ​

同样是这句报错，背后有三种常见来历，处置各不同：

场景判别方法处置
从没加过 docker 组id 输出里没有 dockersudo usermod -aG docker $USER 后重新登录
加过组但没重新登录id（旧 shell）无 docker 组，groups $USER（读 /etc/group）有退出重登；不想重登可用 sg docker -c "docker ps" 临时生效
一直用 sudo docker 凑合命令前都带 sudo 能跑，不带就拒见第五节：这不是解法，是暗伤

第二行是最容易误判的：管理员帮你加过组，你在加组之前开的终端里试还是报错，就以为没加成。组关系是登录时确定的，已存在的 shell 会话不会自动刷新——id 查的是当前会话的组，groups 用户名 查的是 /etc/group 里的静态配置，两者对不上就是「加了没生效」。tmux/screen 里挂着的长会话、IDE 里开着的远程终端，本质都是「加组之前建立的会话」，同样不刷新——别在一个三天前开的 tmux 窗口里验证组变更。

第三种场景单独说一下判别特征：如果你发现自己历史命令里全是 sudo docker ...、没有 sudo 就报错，说明环境从来没正规配置过组，一直在用提权硬绕。这种状态下的 OpenLane runs/ 目录几乎可以肯定有 root 属主文件，先去第五节对照清理，再回到正规流程。

四、修复示例：加组、重登、验证 ​

bash
sudo usermod -aG docker $USER
# 退出当前会话重新登录（ssh 断开后重连）
docker ps

-aG 两个字母都不能省：-a 是追加（append），漏了会变成「把用户的属组替换成只有 docker」，把 sudo 组顶掉，下一个坑等着；-G 指定操作的是附加组列表。改完重新登录，这是让组关系生效最稳的方式。如果当前会话里有跑了一半的活不想断，可以用 sg docker -c "docker ps" 在新组上下文中临时执行单条命令（本次实录就是这么验证的），但长期环境还是以重新登录为准。

加组重登前后：同一条 docker ps 两种命运

这张对照卡读法很简单：左边红区是「不在组」的日常——每条 docker 命令都被 socket 权限挡在门外，OpenLane 的 flow.tcl 第一步起容器就倒；右边绿区是加组重登之后——docker ps 返回空表头（没有运行中的容器）就是完全正常的状态。中间的 delta 是这次修复的全部成本：一条命令加一次重新登录，不需要重装 Docker、更不需要重装 OpenLane。

五、暗伤：sudo 跑 docker 留下的 root 属主 runs 目录 ​

很多人图省事，遇到 permission denied 就在所有 docker 命令前加 sudo——当下能跑，但在 OpenLane 场景里这是给未来埋雷。OpenLane 跑流程时会把设计结果写进挂载进容器的 runs/ 目录，容器内进程以 root 身份写文件，落回宿主机就是 root 属主：

text
drwxr-xr-x  3 root root 4096 Oct 20 22:14 runs/RUN_2026.10.20_22.14.01

后果链很实际：你的普通用户之后想删掉旧 run 腾磁盘——rm -rf runs/ 报 Permission denied；想改 run 里的配置重跑——编辑器存不了盘；下次 OpenLane 想在同目录新建文件——又是权限问题。于是只能继续 sudo rm -rf、sudo chown -R 一路 sudo 下去，权限越缠越死，多人共用机器时还会互相清不动对方的 runs。

正确姿势从一开始就是把用户加进 docker 组、不用 sudo 跑 OpenLane 容器（OpenLane 官方的 make mount / flow.tcl 流程默认容器内用户映射为宿主机当前用户，写出的 runs/ 属主就是你自己）。已经被 sudo 污染过的环境，补救一条命令：

bash
sudo chown -R $USER:$USER runs/

把属主改回自己，之后全部按「非 sudo + docker 组」的正规流程走，暗伤不再复发。

六、验证与防复发 ​

修复后按顺序确认三件事，每件一条命令：

bash
id                          # 组列表里应出现 docker
ls -l /var/run/docker.sock  # 确认是 srw-rw---- root docker
docker ps                   # 正常返回表头（空列表即正常）

三条全过，环境就是干净的，可以直接进入 OpenLane 首次跑通流程。防复发只有一条纪律：新机器/新用户装完 Docker 的第一件事就是 usermod -aG docker 并重新登录，把这件事写进装机清单，而不是等报错了再回来查。给团队搭 EDA 服务器时更进一步：把加组动作写进新人入职的账号初始化脚本，和创建 home 目录、发 SSH 公钥放在同一步，从流程上消灭这类工单的来源。

实验环境 ​

  • 机器/系统：云主机 16C32G / Ubuntu 22.04
  • 工具版本：Docker 29.1.3（efabless/openlane 镜像环境）
  • 日期：2026-10-24
  • 完整命令：sudo useradd -m -s /bin/bash tnew、sudo -u tnew sh -c 'id; docker ps; docker images'、sudo usermod -aG docker tnew、sudo su - tnew -c 'sg docker -c "id; docker ps; docker version"'

这一篇在知识体系里的位置 ​

本篇是开源 EDA 排错簇中「环境权限」节点的 FAQ 页，上承 OpenLane Docker 安装实录（安装阶段就该完成的加组动作），下接 OpenLane 首次跑通流程（权限修好后进入真正的设计流程）；商用工具侧的同类权限排查见 Design Compiler Permission denied，两者共享「先看报错原文、再查 OS 层权限模型」的同一套方法论。

一句话总结 ​

docker permission denied while trying to connect daemon socket 的本质是 /var/run/docker.sock（root:docker、0660）把非 docker 组用户挡在门外：sudo usermod -aG docker $USER 加组后必须重新登录才生效（旧 shell 不刷新组关系），docker ps 返回表头即修复；别用 sudo docker 凑合——那会让 OpenLane 的 runs/ 目录变成 root 属主，普通用户清不掉改不动，已中招的用 sudo chown -R $USER:$USER runs/ 一次性改回。