问题背景
公司使用一台群晖 DS1821+ NAS 作为部门共享文件服务器,通过 SMB 协议提供网络驱动器映射。每个部门有一个独立共享文件夹,权限通过 Windows ACL 精细化控制。市场部共享文件夹路径为 \\NAS\Market,设有三个安全组:Market-RW(读写)、Market-RO(只读)、Market-Mgmt(管理)。
故障现象
周三下午 3:15,市场部多名同事反馈:映射的网络驱动器 Z 盘无法打开,双击后提示"你没有权限访问此文件夹。请与网络管理员联系。“与此同时,其他部门(如财务部 \\NAS\Finance)访问正常。
检查 NAS DSM 控制面板——共享文件夹 Market 状态正常,磁盘正常,SMB 服务运行中。但市场部 25 名同事中有 18 名报告无法访问,7 名可以正常访问。
排查过程
第一步:对比能访问和不能访问的用户
能访问的用户:zhangsan、lisi、wangwu 等 7 人
不能访问的用户:zhaoliu、sunqi 等 18 人
两组用户都属于 Market-RW 安全组。排除组权限问题。
第二步:逐级检查 ACL
在 NAS 上用 getfacl 检查路径权限:
|
|
共享文件夹本身的权限正确。当检查子目录时发现问题:
|
|
Q4-Planning 目录下只有 3 个显式 ACE,没有继承父级的 Market-RW 安全组权限!这意味着不在显式 ACE 中的人无法访问该目录及其子内容。
第三步:追溯权限变更历史
查看 NAS 的 SMB 操作日志:
|
|
原来 zhangsan 昨天下午将 Q4-Planning 文件夹从一个位置移动到了另一个位置。在 SMB/NTFS 中,同卷移动文件夹时,文件夹会保留原始 ACL。但 Q4-Planning 原始位置就在 Market 共享中,为何会丢失继承?
进一步检查发现:原始路径 Projects\Q4-Planning 开启了"显式权限"模式(关闭了继承),即该文件夹的 “Include inheritable permissions from this object’s parent” 未被勾选。当它被移动到 Campaigns 下时,由于已关闭继承,不会自动获取目标位置的权限继承。
而 18 名不能访问的用户正是因为不在 Q4-Planning 的显式 ACE 列表中,他们访问 Market 根目录正常,但一进入 2024Q3\Campaigns\Q4-Planning 就被拒绝。
解决方案
- 紧急修复:在
Q4-Planning上重新启用继承:
|
|
-
补全安全组权限:确保
Market-RW组对所有子目录有完全访问权限。 -
验证恢复:
|
|
根因分析
直接原因:Q4-Planning 文件夹被设置为"关闭权限继承”,移动后未能自动获取目标父目录的安全组 ACL,导致只保留了 3 个显式 ACE——18 名通过安全组获得权限的用户被拒绝访问。
深层原因:
- 缺乏 NAS 共享文件夹的权限管理规范,用户可在本地修改 ACL
- 文件夹移动操作时用户不了解 NTFS ACL 继承机制
- 没有对关键共享文件夹的 ACL 变化做审计监控
预防措施
- 锁定权限管理:在 NAS 上禁用 “允许用户修改文件夹权限”,权限变更统一由 IT 通过管理界面操作
- 强制权限继承:对所有部门共享文件夹的根目录启用"强制子对象继承",禁止关闭继承
- ACL 变更审计:开启 NAS 的 ACL 变更日志,权限变动时发送通知给 IT
- 知识培训:向各部门文档管理员培训 NTFS 权限机制,特别是"移动 vs 复制"、“继承开关"的含义
- 定期审计脚本:
|
|
总结
Windows/NTFS ACL 的权限继承是一个"沉默的陷阱”——看起来像一个简单的文件移动操作,实际上可能悄悄改变了整个权限结构。问题在根源上是一个管理问题而非技术问题:谁有权限变更文件夹的 ACL?谁应该负责?如果没有明确的权限边界和审计机制,这种"我今天还能访问,明天就报权限不足"的情况会反复出现。