SpyGlass 权限被拒：sg_shell permission denied 速查
更新时间：2026-10-23。FAQ 速查页，属于 EDA 工具排错系列。SpyGlass 报 Permission denied 几乎从不是工具本身坏了，而是操作系统层「当前用户对这个文件/目录摸不得」的直白转述——sg_shell 起不来、工程目录写不进、license 读不了，都是同一套 Unix 权限模型在不同环节上的表现。同族问题见 PrimeTime 权限被拒、Calibre 权限被拒；「找得到但摸不得」的相邻问题「找不到」见 SpyGlass 语法解析报错 系列排查思路。
本文要回答的问题
- sg_shell 启动就 Permission denied，是二进制问题还是环境问题？
- 工程目录明明存在，为什么写不进去？
- license 文件权限设多宽才合适？
- 为什么 sudo 之后在 NFS 上反而更没权限？
一、报错原文与现象
sg_shell: Permission denied
Error: cannot open file '/proj/work/spyglass/spyglass.log' for writing: Permission denied
Error: cannot create directory 'spyglass_reports': Permission denied
Error: cannot read license file '/opt/spyglass/license.dat': Permission denied先定三件事：什么动作（执行二进制 / 读 license / 写工作目录 / 写报告目录）、什么对象（报错文本里通常带完整路径）、以什么身份（id 一条命令确认当前用户与组）。三要素齐了，对照下表走。与「路径不存在」那类报错的分工很明确：那篇是找不到，这篇是找得到但摸不得——路径在报错里真实存在，只是权限不放行。
二、可能原因总览
| 报错现象 | 可能原因 | 处置 |
|---|---|---|
| sg_shell 本身拒绝执行 | 二进制执行位被误 chmod 掉 | ls -l 核对后 chmod +x 恢复 |
| 工程目录写不进 | 属主是别人，组无写权限 | 找属主放开组写或换自己空间 |
| spyglass 工作/日志目录创建失败 | 父目录只读或无 w 位 | 换本地可写目录重定向 |
| license 文件读不了 | 600 且属 root，普通用户无 r | 调整 license 文件为 644 |
| 共享 NFS 上 sudo 仍被拒 | root squash 把 root 映射成 nobody | 不用 sudo，修对属主与组 |
| 新建文件同事打不开 | umask 太宽（027/077）锁死组权限 | 流程脚本固定 umask 002 |
| 某台机器行、另一台不行 | 该节点挂载为只读 ro | mount 核对挂载选项 |
三、逐条排查展开
先分清「执行被拒」与「读写被拒」。 sg_shell 启动瞬间报 Permission denied、连 banner 都没出，是二进制或脚本缺执行位——安装目录被人误 chmod -R 之后常见。判别一条命令：
ls -l $(which sg_shell)
ls -l <工程目录>
idls -l 第一位是 - 的文件看第九位的 x（执行位），是 d 的目录看属主与组权限。id 确认你是谁、在哪些组里——属主是不是你、你不在属主组里时组权限对你无效，两条线索直接决定走 chmod 还是走「找属主」。
工程目录属主是别人，是共享 NFS 工作区的主战场。 多人共用一个项目区，上次同事跑 SpyGlass 留下的 spyglass 工作目录、缓存与日志属主是同事，组权限又没开写，你重跑立刻写不进。正解不是自己 chmod 别人的东西（你没权限 chmod 不属于你的文件），而是：临时让属主放开组写，或把 SpyGlass 工作目录重定向到自己的空间；长期按组协作建目录（统一项目组 + setgid 位 + umask 002），从建目录第一天配好。
license 文件太严是隐蔽的一条。 license.dat 被运维设成 600 且属主是 root，加密含义是好的，但普通用户跑 sg_shell 时读不了、checkout 直接失败，报错文本只提 cannot read license file 而不提是谁的锅。判别：ls -l <license路径>。license 内容不含可写机密，读权限放开到 644 是行业惯例（644 属 root：root 可写、所有人可读）。改完仍失败再走 license 专项排查，见 SpyGlass license checkout 失败。
NFS root squash 让 sudo 变成反效果。 直觉上「权限不够就 sudo」，在 NFS 挂载点上恰好相反：服务端默认把客户端 root 映射成 nobody 用户，sudo 之后权限反而更小。而且 sudo 跑工具的所有产物属主变 root，后续正常用户集体撞墙，问题滚雪球。判别：
mount | grep <挂载点>
sudo touch <挂载点>/test && ls -l <挂载点>/test看到属主是 nobody 就坐实 root squash。正解永远是修对属主/组/umask，不是抬高身份；已被 sudo 污染的目录由管理员统一 chown 回项目属主。
umask 决定新文件的默认权限，是「建出来就锁死同事」的根源。 umask 027 或 077 的登录环境里，你跑 SpyGlass 生成的报告目录组无写甚至组无任何权限——你自己续跑没事，同事接手立刻 Permission denied。判别：umask 直接看当前值。协作项目的 env 脚本里固定 umask 002，既保组可写又不对外放开。
「文件权限全对仍被拒」查父目录链条。 有时 ls -l 看文件本身权限完全正常，SpyGlass 还是打不开——九成是路径上某一级父目录没有 x 位（对目录而言 x 是「可穿越」，缺了它连目录里的文件名单都摸不到）。namei -l <完整路径> 把路径上每一级目录的权限与属主逐层列出来，哪一级缺 x 一跑就现形，比一层层 ls -ld 手动爬快得多。
「这台机器行、那台不行」先查挂载选项。 共享盘在不同计算节点挂载选项可能不同——某台挂了 ro（只读），该节点上所有写操作集体 Permission denied，读却完全正常，极具迷惑性。mount | grep <挂载点> 看到 ro 就找运维重挂或换节点。
颜色按语义分角色：红是报错入口，蓝是排查动作，橙是修复，紫是收尾防复发。主线是「先定三要素，再按动作分三条通道：启动即拒查执行位与 license 可读性、工作中拒查属主与组、换机才拒查挂载选项」。sudo 在任何一条通道里都不是出口——NFS root squash 下它反而让你更没权限。
四、预防与纪律
- 项目目录统一组协作配置：统一项目组 + setgid + env 脚本固定
umask 002，建目录第一天配好，别等撞墙再补。 - 安装目录权限纳入巡检：sg_shell 所在安装树定期核对执行位，防止误
chmod -R整树锁死。 - license 文件权限写进部署清单：644 属 root，部署文档里固化，运维变更后核对一次。
- 禁 sudo 跑工具写进团队公约：sudo 产物属主污染比原问题更难收拾，发现统一 chown 清理并复盘来源。
- 排查留三件套：
id、ls -l <路径>、mount | grep <挂载点>的输出连同报错原文一起记录，跨人交接不靠口述。
这一篇在知识体系里的位置
本篇是 EDA 排错速查簇中「权限」节点的 SpyGlass FAQ 页，与 PrimeTime 权限被拒、Calibre 权限被拒 同族；SpyGlass 工具族的其他高频报错见 SpyGlass 语法解析报错、SpyGlass license checkout 失败，SpyGlass 工具本身的能力定位见 SpyGlass RTL Lint 实战。
一句话总结
SpyGlass 权限被拒先定三要素（动作、对象、身份），再按动作分流：启动即拒查 sg_shell 执行位与 license 文件 644，工作中写不进查工程目录属主与组（协作场景靠项目组 + setgid + umask 002 根治），换机才拒查 mount 只读挂载与 NFS root squash；sudo 跑工具在 NFS 上反而更没权限，明确禁止；最后靠「组协作配置 + 安装与 license 权限巡检 + 排查三件套留痕」三条纪律防复发。