本地开发环境的 MES（Spring Boot + EasyUI 微服务架构，部署在内网）突然报错：基础数据页点「下载导入模板」，接口抛 jcifs.smb.SmbAuthException: Access is denied.（jcifs 1.3.17）。模板存在文件服务器的 SMB 共享里，这行异常有两种完全不同的解读——“你的凭据我认了，但你不能进来”（授权问题），还是”你根本不是你”（认证问题）。两种解读指向的修法天差地别。
这类报错最怕一步跨错：看到 Access denied 就去改密码、重置账号、怀疑 NTLM 版本，改一圈发现方向全错。这次排查没有赌任何一个”想当然”的修复，而是用一个 20 行的 Java 探针把三种假设（账号密码错 / NTLM 协商不兼容 / 单共享 ACL 漏授权）逐一拆开，最后锁定第三种——文件服务器上单个共享目录漏了给服务账号授权，一条 icacls 修完当场生效，服务重启都不用。
这篇复盘完整定位过程，重点讲三个可复用的手法：denied 与 absent 的语义区分、同账号跨共享对比、修复后验证到与报错完全相同的操作层。
一、链路定位：两个数据来源拼出一个 URL
异常栈很干脆：模板下载接口 → 导入服务 → 框架 jar 里的 SmbUtils.downloadFileSmb。框架 jar 没有源码，用 CFR 反编译 SmbUtils 后发现，SMB 地址不是配置文件写死的，而是运行时从数据库两张表拼出来的：
- 系统参数表的四个 System 组参数：SMB 主机、SMB 账号、SMB 密码、文件服务器根目录——负责”连到哪、以谁的身份”；
- 模板定义表里每个导入实体对应的模板相对路径——负责”取哪个文件”。
flowchart LR
UI["基础数据页 下载模板按钮"] --> CTRL["模板下载接口"]
CTRL --> SVC["导入服务"]
SVC --> SMBU["框架 SmbUtils 无源码 CFR 反编译"]
CFG["系统参数表 SMB 四参数"] --> SMBU
DEF["模板定义表 模板相对路径"] --> SVC
SMBU --> SMB["文件服务器 SMB 共享"]
SMB -. "0xC0000022 拒绝" .-> SMBU
把参数连库取出来，实际访问的 URL 是：
1 | smb://mesuser:***@192.168.x.x/MesFileShareA/WorkDir/Template/zh_CN/CheckItemTemplate.xlsx |
这一步的价值是把”接口报错”翻译成”这个账号访问这个 URL 被拒“——问题从应用层降到文件服务器层，后面所有探测都有了明确靶子。URL 拼接逻辑确认无误，也顺带排除了”配置改了没生效””路径拼错”这类应用侧假设。
二、独立复现：为什么不用 net use
拿到 URL，第一反应往往是在 Windows 上 net use \\192.168.x.x\... 试一下。真试了，报错误 67（找不到网络名）——顺着它查会去怀疑共享名拼错、网络不通，全是歧途。问题出在工具本身：net use 走 Windows 自己的 SMB 客户端栈，而应用走的是 jcifs 1.3.17 这个 2014 年就停止维护的老客户端，两者的认证协商、方言协商行为都不一样。用不同的客户端去验证另一个客户端的行为，结论可能是矛盾的——错误 67 和应用的 Access denied 根本不是同一层的事。
正确做法是”用什么报的错，就用什么复现”：从 maven 仓库把应用同款 jcifs-1.3.17.jar 拉下来，写一个 20 行的探针，凭据构造方式与应用完全一致——尤其注意 domain 参数传的是服务器 IP：
1 | NtlmPasswordAuthentication auth = |
domain 传 IP 这种非常规写法直接影响 NTLM 应答的生成，探针里差一点，复现就不成立——同构复现的要求细到凭据对象的构造方式。
三、denied vs absent：一条不存在路径的基线
探针打出去，exists() 没有返回 false，而是抛异常，消息里带着 ERR[-1073741790]——换算成十六进制是 0xC0000022，STATUS_ACCESS_DENIED。这里有一个容易被忽略的语义区分：
- 返回
false（absent）= 路径不存在； - 抛 ACCESS_DENIED = 路径存在（或存在性不可知），但无权访问。
关键的坑在于：Windows ACL 会用 denied 掩盖存在性——当父目录无权限时，深层路径不论真假都可能报 denied 而不是 not found，因为探测者无权”知道它不存在”。也就是说，denied 单独出现时你无法区分“真路径无权”和”路径根本不存在 + 存在性被掩蔽”。
所以探测组里必须放一条已知不存在的路径做基线对照——这是整个排查里性价比最高的一步：
- 基线路径报 absent → 服务器愿意对我们”讲真话”，真实路径报 denied 就是存在但无权；
- 基线路径也报 denied → 连存在性都被掩蔽，得先解决上层目录的权限。
实测：不存在的 Template/zh_CN/NoSuchFile.xlsx 干脆返回 absent，真实模板路径报 0xC0000022——路径存在，纯粹是权限问题，模板定义表的路径配置也不用怀疑了。整个判定逻辑收成一张决策树：
flowchart TD
P["探针 同凭据同客户端探测"] --> L{"能列出共享清单?"}
L -- "能" --> AUTH["认证成功 排除账号与NTLM假设"]
L -- "不能" --> FAIL["认证层问题 账号或协议协商"]
AUTH --> B{"已知不存在的路径作基线"}
B -- "报 absent" --> H{"真实路径返回?"}
B -- "也报 denied" --> MASK["存在性被掩蔽 先修父目录权限"]
H -- "ERR 0xC0000022" --> CMP["同账号探测同机其他共享"]
H -- "absent" --> MISS["路径真不存在 查模板定义表"]
CMP -- "部分共享可读" --> ACL["锁定单共享ACL漏授权"]
CMP -- "全部被拒" --> ACCT["账号在该机授权不足"]
四、同账号跨共享对比：三重假设拆到只剩一个
到这里，”Access denied” 还对应三种解释：账号密码错、NTLM 协商不兼容、这个共享的 ACL 真没授权。两个动作把它们全部拆开。
第一步，证明认证成功。 用同一凭据列文件服务器上的共享清单（对 smb://192.168.x.x/ 调 listFiles）。能列出清单，说明 session setup、认证、方言协商全部通过——账号密码没错，NTLM 也没问题，前两种假设一次排除。反过来想：如果真是账号问题，连共享清单都列不出来。
第二步，同账号跨共享对比。 这台文件服务器上还挂着其他项目的共享，结构相同、同一账号访问。逐个探各自的 WorkDir：
| 共享（同机、同账号） | WorkDir 探测结果 |
|---|---|
| 本项目 MesFileShareA | 0xC0000022 拒绝 |
| 项目 B 的共享 | 可读、可列目录 |
| 项目 C 的共享 | 可读、可列目录 |
| 项目 D 的共享 | 0xC0000022 拒绝 |
同样的凭据、同一台服务器、四个共享、结果干净地二分为”可读/被拒”——问题被钉死在单个共享的 ACL 上。
这一步的逻辑骨架是控制变量：账号、协议、服务器全部固定，只有共享这一个变量在动；而服务器上恰好摆着天然的对照组和实验组。假如是账号问题，四个共享应该全拒；假如是 NTLM 问题，第一步就出不了门。三种假设，两步拆完，不需要碰任何一个配置。
五、修复：一条 icacls，以及为什么不用重启
文件服务器就是开发机本机（192.168.x.x 解到自己），共享实路径 D:\Share\MesFileShareA。查看 ACL，服务账号确实不在授权列表里——新建共享时漏配。补授权：
1 | icacls D:\Share\MesFileShareA /grant mesuser:(OI)(CI)RX /T |
(OI)(CI) 让权限继承到所有子目录和文件，RX 是读 + 列目录——模板下载只需要读，按最小权限给。
两个值得展开的点。
1. 为什么不用重启服务？ 反编译时看到 SmbUtils 有个 static 的 auth 字段，第一反应是”凭据被缓存了，改完 ACL 说不定要重启才生效”。读完方法体发现缓存边界画在别处：static 字段缓存的只是凭据对象（一个 POJO），每个下载请求都重新构造 SmbFile、重新走完整的 SMB session setup——**被缓存的是”你是谁”，不是”你能进哪”**。ACL 判定发生在服务器端每次会话建立和打开文件时，授权改完，下一个请求自然生效。实测同样如此：icacls 跑完，探针立刻从 denied 变可读，服务进程一下没动。
2. 验证必须打到与报错相同的操作层。 原始报错点在 open0——SmbFileInputStream 打开文件那一下，而 exists() 只是 stat 语义，走的根本不是同一条代码路径。修复后的验证闭环分三级：探针对目录从 denied 变成可列；再用 SmbFileInputStream 实读文件字节，读到 9221 字节、开头 PK 魔数（xlsx 本质是 zip 包）；最后浏览器重试原始接口，模板正常下载。读到和报错同一层的成功，才算修复闭环——exists 通过证明不了 open 能过。
六、方法论小结
- “Access is denied” 是个复合命题，先拆开再下手。 它同时压着认证和授权两层信息：先用”能否列出共享清单”证明认证成功，再用 absent 基线区分 denied/absent，最后同账号跨共享对比——三步把”账号错 / NTLM 不兼容 / 单点 ACL”三种假设全部拆开，每一步都有明确的证伪点，而不是改一样试一下；
- 复现必须与生产同构。 同版本 jcifs、同凭据构造方式，细到 domain 传 IP 这种写法都要一致。换
net use这类”顺手”的工具去测，不同客户端协商行为不同，轻则测不出问题，重则给出错误 67 这种把人带偏的结论； - denied 单独不可判读，必须配 absent 基线。 Windows ACL 会用 denied 掩盖存在性；探测组里放一条已知不存在的路径，才能确认服务器在对你”讲真话”，denied 才能安全地翻译成”存在但无权”；
- 修复后验证到报错发生的同一操作层。 报错在 open，验证就要读到字节（9221 字节、PK 魔数）；exists/stat 的通过证明不了 open 能过，”看起来好了”和”修好了”之间隔着一次同层复测；
- 理解缓存边界，才知道什么要重启、什么不要。 static auth 缓存的是凭据对象而不是授权结果，每个请求重走 session setup——“改 ACL 免重启”是反编译读出来的结论，不是赌运气。反过来，如果缓存的真是 session，改完 ACL 就得重启验证，这个判断只能来自读代码，不能来自试。
回头看，这场排查没有用任何冷门工具，探针 20 行、反编译一只 jar、一条 icacls。贵的从来不是工具，是纪律：每一步只动一个变量，只问一个可以被证伪的问题。