极客工场

Appearance

共 2,592 字预计阅读约 9 分钟

Calibre 权限被拒：Permission denied 速查 ​

更新时间：2026-10-22。FAQ 速查页，属于 EDA 工具排错系列。Calibre 一次 DRC/LVS/PEX 跑下来要在 run 目录里生成几十上百个文件（.db 工作库、svdb、*.results、*.report、PEX 网表与临时文件），同时要读 rule deck、GDS/OASIS、PDK 器件库——读写面比综合工具宽得多，权限问题也就更密集。报错文案是 Linux 内核或文件系统给的，不是 Calibre 自己的判断。综合侧同类问题见 Design Compiler 权限被拒，本系列总入口见 开源 EDA 报错排错中心。

本文要回答的问题 ​

  • Calibre transcript 里 Permission denied 和 Read-only file system 分别断在哪一层？
  • rule deck 能读完、跑了一半才报写失败，是哪里的权限不对？
  • 两个人并发跑同一个工程，为什么第二轮总是被第一轮的文件挡住？
  • sudo calibre 为什么既救不了权限、还会弄丢 license 环境？
  • 网络共享盘（NFS/AFS）和容器里跑 Calibre，权限问题有什么特有形态？

一、报错原文与典型现象 ​

Calibre 的权限报错分散在启动期和运行期，先认出三种典型形态。以下文案整理自常见 transcript（drc.results、lvs.report、pex_*._x.log），工程名已占位：

1. 读 rule deck / GDS 阶段被拒（启动即断，最靠前）：

text
***** ERROR: Cannot open include file "/opt/pdk/calibre/drcRules.svrf".
    Permission denied
Error: Could not open layout database "/proj/chip/top.gds".
    Permission denied

2. 写 run 目录 / results 阶段被拒（deck 读完、跑起来才断）：

text
Error: Cannot open file "./top.drc.results" for write.
    Permission denied
Error: Unable to create database file ./svdb/DB.
    Read-only file system

3. PEX 网表或临时文件写失败：

text
***** ERROR: Cannot create file "pex_netlist/top.pex.netlist".
    Permission denied

三种形态分别卡在「读输入」「建工作库」「写输出」——报错语句里的动词（open for read / create / open for write）直接告诉你缺的是读、写还是进入权限，先对号再动手。读这篇之前建议先看一眼 Calibre 物理验证实操 里 run 目录的组织方式，理解 Calibre 到底要往哪些路径写东西。

二、原因速查表 ​

报错现象可能原因处置
include deck / 读 GDS 被拒输入文件无读权限，或父目录无 xchmod 加读位，namei 查中间层
建 svdb / 写 results 被拒run 目录无写权限换可写目录或修目录属主权限
报 Read-only file system共享盘/库区以 ro 挂载mount 确认，输出改到可写分区
同事跑我建的工程被拒umask 022 导致新文件组只读umask 002 加组写，配 setgid
并发两轮互相挡共用 run 目录，文件属主交错每轮独立 run 目录，不共用工区
sudo 跑完后普通身份再跑被拒root 属主文件混进 run 目录chown 归还，禁止 sudo 跑 calibre
rwx 正常仍被拒ACL 细粒度限制或 NFS uid 映射getfacl 查 ACL，两边 id 比对
容器内跑挂载目录写不进挂载卷属主/属组与容器内 uid 不符挂载时指定 uid/gid 或用命名卷
PDK 目录整组不可读PDK 安装后权限没放开让管理员放开 o/g 读与目录 x

三、排查决策树 ​

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

颜色按语义分角色：红是报错入口与命中的根因，蓝是排查动作，橙是修复与清理动作，紫是防复发收尾。读这张图抓住主线：namei 逐层查路径能解决八成问题——文件本身权限对、但中间某层目录缺 x 进不去，是最常见的隐形坑；namei 全绿（图中「层层正常」分支）再查只读挂载、ACL 和并发互踩；最后独立 run 目录加 umask/setgid 是防复发，不做的话下一轮回归还会再见。

四、逐条排查展开 ​

先分清缺的是读、写还是执行。 读（r）管打开文件看内容，写（w）管修改与在目录里增删文件，执行（x）对目录是「能进入」。Calibre 一轮验证要「读 deck + 读 GDS + 在 run 目录里建库写报告」三件事同时成立，任何一件缺位就以对应形态报错。不要用 chmod 777 图省事——rule deck 和 GDS 被加上写权限，反而有被误改污染的风险。

namei 一条命令逐层定位。 文件本身权限看着正常却仍被拒，九成是路径中间某层目录缺 x：你能 ls /opt/pdk/calibre 不代表能进入 /opt/pdk：

bash
namei -l /proj/chip/run/top.drc.results
id

namei -l 把每一层的属主和权限都列出来，输出里第一个权限不足的层就是病灶；配合 id 看自己属于哪些组。Calibre 场景还要特别注意 run 目录里自动生成的 svdb/、pex_netlist/ 子目录——子目录权限是建库那一刻按 umask 定的，和顶层 run 目录分开查。

只读挂载伪装成权限问题。 PDK 安装区、GDS 交接区通常按只读挂载，权限位看着有 w 也写不进去，内核直接回 Read-only file system：

bash
mount | grep " /proj"
touch /proj/chip/run/.write_test

mount 输出带 ro 即只读——这不是你能 chmod 修的，正确做法是把 run 目录和所有输出（svdb、results、PEX 网表）放到可写项目区。PDK/库区只读本身是对的保护，别让 Calibre 往安装区写任何东西，runset 里的相对路径尤其要当心默认落在 deck 旁边。

umask 与并发互踩是 Calibre 的高频事故。 你 umask 022 建出的 run 目录文件是 644，组内同事只有读权限；两人轮流回归同一个工程时，第二轮要覆盖第一轮的 .db/.results 就被拒，报错全是对方用户名属主的文件。处置两层：协作目录 umask 002（组可写）并配 setgid（chmod g+s <run根目录>，新建文件自动继承目录属组）；更根本的是每轮回归用独立 run 目录（如 run_<日期>_<工号>），Calibre 工区天然不是为并发共用设计的，svdb 被两个进程同时写还可能产生半损坏的数据库，症状比单纯权限报错更难查。

sudo 是最常见的自残方式。 权限被拒时图省事 sudo calibre -drc ...，有两个连锁后果：其一，跑完 run 目录里全是 root 属主文件，普通身份再跑继续被拒，权限问题「遗传」；其二，sudo 默认重置环境，MGC_HOME、LM_LICENSE_FILE、PDK_DIR 一起丢失，Calibre 可能立刻报 license 或 include 失败，老问题没走新问题先来。正确姿势是修权限本身，发现 root 属主残留一次性归还：sudo chown -R <自己>:<组> <run目录>。license 类报错的专门处置见同批 Calibre 模块/单元找不到速查 中环境变量一节。

NFS/AFS 与 ACL 两个隐蔽角落。 rwx 位全绿仍被拒时，先 getfacl <路径> 查有没有访问控制列表做了更细的限制（AFS 另有自己一套 ACL，不在传统权限位里显示，要用 fs listacl 看）。NFS 场景还有属主映射坑：登录节点和计算节点上同一用户名对应不同 uid 时，交互跑能过、提交到调度集群就被拒——两台机器各跑一次 id 比对 uid 即知，这类问题 chmod 修不了，要找 IT 统一 uid 或走集中账号。

容器挂载权限单独说。 在 Docker/Singularity 里跑 Calibre，挂载 -v /proj/chip:/data 后容器内进程写不进，通常是容器内运行 uid 与宿主目录属主对不上：宿主目录是个人 uid，容器里默认 root 或镜像固定 uid。修法是 docker run --user $(id -u):$(id -g) 对齐身份，或让挂载目录的组写权限覆盖容器内 gid；同时确认挂载本身没带 :ro——为了防误改把工程目录只读挂进去，Calibre 建 svdb 时必然失败。

修复顺序有讲究。 批量修权限先修目录再修文件、先修上层再修下层——上层目录缺 x 时，对下层的 chmod 本身就失败：

bash
find <run目录> -type d -exec chmod g+rwx {} +
find <run目录> -type f -exec chmod g+rw {} +

目录给 x（能进入）、文件不给 x（deck/GDS/报告都不需要执行位），避免一把 777 把整棵工程树变成可执行。

五、预防与纪律 ​

  • 库区与输出区分离：PDK/rule deck/GDS 交接区整区只读挂载，run 目录、svdb、results、PEX 网表一律写专门的可写项目区，从结构上消灭一半权限问题。
  • 一轮一个 run 目录：回归脚本每次新建独立工区，跑完归档；禁止多人、多轮共用同一 svdb，既防权限互踩也防数据库损坏。
  • 协作目录标准化：项目根建公共组、配 setgid、成员 umask 002，建目录时一次配好。
  • 禁止 sudo 跑 calibre：权限问题修权限本身；root 属主残留发现即 chown 归还。
  • 提交脚本环境自检：调度脚本开头打印 id、umask、MGC_HOME 并 touch 测写 run 目录，任一失败立即退出，别让环境问题混进几百行 transcript。

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

本篇是 EDA 排错速查簇的一员，总入口见 开源 EDA 报错排错中心；上游背景是 Calibre 物理验证实操，rule deck 的 INCLUDE 与路径机制见 Calibre SVRF rule deck 解剖；综合侧同构问题对照 Design Compiler 权限被拒，环境变量与文件找不到类报错见同批 Calibre 模块/单元找不到速查。

一句话总结 ​

Calibre 权限被拒固定三步排查：按报错动词确定缺读、写还是进入权限，用 namei -l 逐层看穿路径找出第一个不足的层（病灶多在 run 目录的中间层而非文件本身），namei 全绿再查只读挂载、ACL 与容器挂载三个隐蔽角落；PDK 只读、输出另放可写区、每轮回归独立 run 目录、协作配 umask 002 加 setgid、绝不 sudo 跑 calibre，五条纪律做到位这类报错基本绝迹。