1. 这事儿得从“删不掉的文件”说起
你是不是也遇到过这种情况：明明自己是管理员，删一个文件夹却弹出“你需要来自Administrators的权限才能对此文件夹进行更改”，点“继续”没用，右键改安全权限改不动，属性里“安全”标签页全是灰色，连“高级”按钮都点不进去。最后只能上网搜命令，照着一堆乱七八糟的指令瞎试，运气好删掉了，运气不好直接蓝屏心态爆炸。
我当年刚接触Windows运维时，第一次被这个弹窗拦住，整整折腾了一下午，最后才发现搞懂NTFS权限的原理之后，根本不用那么费劲。这篇文章不打算把微软文档抄一遍，而是把NTFS权限里最核心的几个概念讲透，再把平时最容易踩的坑一个个拆开来说清楚。看完你会明白，权限报错的本质就三类：所有者不对、ACE策略冲突、继承链断了。这三件事搞明白，Windows下百分之九十九的权限问题都能自己解决。
先提醒一句：这篇文章涉及大量需要动手验证的操作，建议你先开一台虚拟机或者找一台不重要的机器试，别拿生产服务器练手。
2. 先搞懂NTFS权限的几个基础概念
2.1 ACL、ACE和权限判定顺序
NTFS权限的控制核心是ACL（访问控制列表），每个文件或文件夹都带着一串ACL。ACL里的每一行，就是一个ACE（访问控制项），它描述的是“某个主体对某个对象有哪些操作的允许或拒绝”。你可以把ACL理解成一份门禁名单，ACE就是名单上的每一条规矩，比如“张三可以刷卡进A门”“李四禁止进B门”。
这里有个关键点：ACE是分类型的，主要分“允许”和“拒绝”两类。当系统判定用户有没有权限时，不是从上往下碰到第一个匹配就结束的，而是有固定的逻辑顺序：
- 先检查“显式拒绝”的ACE，如果命中，直接拒绝，后面的都不看了。
- 再检查“显式允许”的ACE，命中就允许。
- 接着检查“继承拒绝”，命中就拒绝。
- 最后检查“继承允许”，命中就允许。
- 如果全都查完没有命中，默认就是拒绝。
这个顺序大大出乎很多人的意料。很多人以为“拒绝优先于允许”就够了，但实际上“显式高于继承”才是更底层的规则。什么叫显式？就是直接在某个文件或文件夹的ACL里手工加的ACE。什么是继承？就是从父文件夹继承下来的ACE。显式的拒绝大于显式的允许，显式的允许大于继承的拒绝，继承的拒绝大于继承的允许。
知道这个顺序后，很多奇怪的现象就能解释了。比如你用管理员账号登录，却无法打开某个文件夹，一看ACL里有一条“Administrators 拒绝”的ACE，这就是显式拒绝把管理员也挡在外面了。所以别看到“拒绝”就觉得是系统BUG，先打开安全选项卡看一眼ACL是不是被人动过手脚。
2.2 所有权（Owner）——你没有它，连改权限的资格都没有
NTFS里有个底层机制叫“所有权”，它跟ACL是两套体系。微软的设计思路是这样的：文件的真正的老板是所有者，不是管理员。默认情况下，创建文件或文件夹的用户自动成为所有者，Administrators组的成员可以把任何文件的所有权夺过来，这一点可以通过右键属性-安全-高级-更改所有者来实现。
但坑就坑在这里：如果你不是文件的所有者，没有“更改权限”的权限，你想夺所有权？不好意思，你还是没有权限改。那怎么办？Windows的规则是：取回所有权不需要对方授权，因为管理员组默认有这个特权。右键高级里直接点“更改”，输入Administrators组，确定，所有权就到手了，然后再重新分配权限。
这就是很多人第一步操作就卡住的原因：他们以为拥有管理员权限就等于可以做一切，但在NTFS的世界里，所有权和普通权限是两码事。有一个很经典的场景：从旧电脑上拆下来的移动硬盘插到新电脑上，文件夹的Owner还是旧电脑上的那个账户SID，新电脑的Administrators组虽然可以强取所有权，但如果你用的是普通用户小孩那就不行，因为“更改所有者”这个操作需要SeTakeOwnershipPrivilege特权，普通用户没有。
你每次看到“你需要来自TrustedInstaller的权限才能对此文件夹进行更改”的时候，本质就是这个文件夹的所有者是TrustedInstaller（一个隐藏的系统服务账户），不是你的登录账户，也不是Administrators组。要改这种文件夹，正确的顺序就是先拿所有权，再改ACL，最后再改回TrustedInstaller（或者不改）。网上那些教你“直接删掉TrustedInstaller权限”的做法，虽然能删，但可能会让系统更新组件失效，属于饮鸩止渴。
2.3 继承机制——子文件为什么比你想象的“不听话”
NTFS继承是指子对象会从父对象那里自动获得一份相同的权限。新建一个文件夹再在里面建子文件夹，默认子文件夹的权限就是继承来的。你修改父文件夹的权限，如果勾选了“将父容器的继承权传播到子对象”，子对象会跟着更新。这个机制本身很好用，但坑在于它和“断链”配合时特别容易出混乱。
所谓断链，就是在子对象的安全属性里把“从父项继承的权限”这一项勾掉。一旦你断链，子对象就跟父对象剥离开来，父对象怎么改权限都不影响子对象。这本身也是一个正常功能，但实际操作中有很多人不知道自己在什么时候不小心把链断了，导致后面父文件夹权限改了半天，子文件夹一点都不动，最后以为是电脑出了问题。
解开这个问题的通用操作：右键子文件-属性-安全-高级-启用继承。或者，更粗暴的，在父文件夹上勾选“替换所有子对象的权限项”——这会强制把父级的ACL推送下去，把断链全部打断重连。如果没有权限，就得先交替解决所有者。
2.4 特殊权限“完全控制”里还藏着东西
“完全控制”看着好像是最高权限了，其实它下面还拆了好几个子项：读取、写入、读取与执行、列出文件夹目录、修改、完全控制。注意，这几个不是平级的，而是“完全控制”包含“修改”，“修改”包含“读取与执行”。如果你给用户勾了“修改”，他其实也能读和执行，反过来你勾了“读取”他改不了任何东西。
但真正能坑死人的是“删除子文件夹和文件”这一项，以及“删除”这一项。它们不是同一个东西。删除权限说的是删除当前文件/文件夹本身，“删除子文件夹和文件”是文件夹的专项权限，允许你删掉下面的子目录和文件，但不一定允许你删父目录本身。这两个权限经常被人忽略，导致一种诡异局面：用户能删文件夹里的所有文件，却删不掉这个空文件夹的口袋。
另一个容易忽略的是“更改权限”和“取得所有权”这两个特殊权限。它们平时被折叠在“完全控制-显示高级权限”里。如果你给用户授权时只给了“读取和执行”，用户是不能修改这个文件的ACL的；但如果给了“完全控制”，用户就有权修改ACL，甚至把你自己踢出去。这个在共享目录里是一个巨大的安全隐患，我在实际项目里就遇过：某人把共享盘里一个目录设置了“完全控制”，然后手滑把Administrator组从ACL里删掉了，管理员再也进不去这个目录，最后还得靠本机登录去夺所有权。
3. 经典的几个“坑”到底怎么回事
3.1 “需要来自Administrators的权限”——但你明明就是管理员
这个弹窗是最常见、也最让人血压升高的。你右键一个旧系统盘里的文件夹，想删除，弹窗说需要来自Administrators的权限，可你自己的账号明明在管理员组里。
这事的核心是：你登录的账号虽然在Administrators组，但Windows系统的UAC（用户账户控制）把你的令牌分成了“完整版”和“过滤版”。正常情况下，你的进程运行在标准用户令牌下，不是完整管理员令牌。当你触发权限需求时，UAC会弹窗让你确认提升。而NTFS权限判定时，用的是你当前进程的有效令牌——如果没有提升，那你就是“普通用户”，不是“Administrators组”。
解决办法也比想象中简单：
- 把文件所有者改成Administrators或当前账号；
- 给当前账号分配完全控制权限；
- 如果上面两步被拒绝，就用管理员身份的cmd运行
takeown /f 路径 /r /d y和icacls 路径 /grant 用户名:F /t /c。
这里有个细节值得注意：takeown必须用“以管理员身份运行”的CMD或PowerShell，不要在普通窗口里试。我见过很多人卡在这里，其实是自己开窗口的方式不对而不是命令不对。
3.2 “需要来自SYSTEM的权限”——这个背后是内核和系统服务
“你需要来自SYSTEM的权限才能对此文件夹进行更改”是另一个高频经典弹窗。SYSTEM是Windows里权限最高的内置账户之一，它的SID是S-1-5-18，系统服务、驱动、核心进程基本都跑在它名下。普通管理员跟SYSTEM比，连它的零头都算不上。
为什么会报这个？通常是你想删或改一个系统守护目录，比如C:\Windows\System32里的某些子目录，或者Windows.old回滚目录。Windows故意把系统关键目录的Owner设成SYSTEM，不给Admin组权限，防止普通程序误删系统文件。但如果你想清的其实只是垃圾文件，为了清理去强行拿SYSTEM的权限又有点危险了。
正确姿势：先看目录是否在系统保护范围内，比如C:\Windows\WinSxS，这种永远是系统在管，不建议动。如果是Windows.old这种可迁移目录，直接右键属性-安全-高级-更改所有者，把Owner改成Administrators，然后给Administrators完全控制，再打开“替换所有子对象的权限项”，最后再删。如果你已经格错盘了或目录被占用了，用takeown无济于事，要从PE盘启动删，不要在系统里硬钢。
3.3 “需要来自TrustedInstaller的权限”——好像永远没法删
微软在Vista时代开始引入TrustedInstaller作为系统组件的一个“新老板”。这是一个Windows Modules Installer服务专属账户，全名叫NT SERVICE\TrustedInstaller，它的SID是S-1-5-80-...一串。几乎所有系统文件都被它“保护”了，Admin组默认对这类文件可能只拥有读权限，没有完全控制。
这就是为什么你想改C:\Windows\System32\drivers\etc\hosts文件时，记事本保存时提示“你需要来自TrustedInstaller的权限”。
网上不少教程教你怎么把TrustedInstaller这个ACE删掉，或者直接把Owner改成Admin。可以对，但这里提醒一点：改系统文件之前，最好先备份原ACL，用完再恢复。我在给客户做系统优化时，见过太多人为了改一个文件顺手把整个目录的Owner都改成Admin，后来系统更新失败、组件存储损坏，一道重装。
正确的操作路径是：
- 右键文件-属性-安全-高级；
- 把所有者从TrustedInstaller改成你的管理员账号或Administrators组；
- 给管理员账号添加“完全控制”权限；
- 修改文件内容；
- 改完后，把权限恢复到默认状态（把所有者改回TrustedInstaller，删除多出来的ACE，恢复为继承的默认ACL）。
第五步很多人嫌麻烦，但我建议还是做。因为Windows组件存储（WinSxS）和系统更新修复机制，对TrustedInstaller的Owner有硬性依赖。你把Owner改成Admin，不一定立刻出事，但下次系统更新大概率会出幺蛾子。
3.4 共享权限和NTFS权限叠加——你以为的“无权限”可能是共享层在拦
企业网盘、共享文件夹场景里有个常见的误区：在共享属性里给用户分配了“完全控制”，但在NTFS安全标签页里只给了“读取”，那用户实际能做的还是只有“读取”。Windows处理这种双权限时，遵循的是“最严原则”——两个权限取交集，不是取并集。
换句话说，共享权限设置得再宽，NTFS权限如果更严，那以NTFS为准；反之，NTFS权限给得再宽，共享层开了“只读”，那大家还是只能读。我在一个客户那里排过一个问题：他给的共享权限明明是“更改”，但技术人员和文员都反馈只能查看不能删除文件。我一看NTFS权限，里面给域用户的ACE是默认的“读取与执行”，当然删不掉。
排查思路很简单：右键共享文件夹-属性-共享-高级共享-权限，再对一下右键-属性-安全里的NTFS权限，看哪个更严，按最严的那个为准。
3.5 默认不该有的“Everyone”和“Authenticated Users”
新的Windows NTFS分区通常没有Everyone权限，但如果是从旧系统、U盘、移动硬盘搬过来的分区，ACL里可能带着各种莫名其妙的条目，比如Everyone（完全控制）。这种情况下，任何账号包括来宾账户都能随意读取和删除，这不是权限设置目标，这属于安全漏洞。
反过来的情况也有：Authenticated Users被赋予了修改权限，导致所有域登录用户都能改某个目录内容。这在文件服务器上属于权限过度授权。所以拿到一个别人移交的文件服务器后，第一件事不是复制文件，而是先审计ACL里到底有哪些主体。
可以用PowerShell跑一下：
Get-Acl "D:\共享目录" | Format-List或者用命令行icacls "D:\共享目录"查看。看到不是你预期的那些组，就要考虑清理。
4. 常用命令与实操：一次把权限问题砸穿
4.1 icacls——修改ACL的主力命令
icacls是从Windows Server 2008开始内置在Windows里的ACL管理命令，功能比图形界面强很多，最适合批量调整权限。
常用场景和写法：
:: 查看权限 icacls C:\Test :: 给用户zhangsan授予完全控制权限（递归） icacls C:\Test /grant zhangsan:F /t /c :: 给用户zhangsan授予修改权限，但不递归子目录（只当前目录） icacls C:\Test /grant zhangsan:M :: 移除用户的权限 icacls C:\Test /remove zhangsan :: 将ACL重置为默认继承权限，并清除所有显式条目 icacls C:\Test /reset /t /c :: 把权限继承显式复制一份到子对象，并替换子对象上的继承权限 icacls C:\Test /inheritance:r /t注意/c代表“继续，遇到错误不停止”。批量跑的时候建议加上，不然一条失败整段停掉。/t是递归所有子目录和文件，/l是处理符号链接本身而不是目标，这个细节很多人不知道，修改带链接的目录时容易踩坑。
icacls /grant有个容易忽略的点：它默认添加的是“允许”ACE，如果你要加“拒绝”ACE，要用/deny。但如前面所说，拒绝ACE优先级很高，滥用会导致各种莫名其妙的问题，特别是在共享文件夹上，尽量不要动不拒绝策略。
4.2 takeown——抢所有权的快速武器
takeown负责的是所有权层面，不碰ACL。它不会帮你打开文件的权限，它只把Owner改掉。有些情况下你会发现，Owner改完之后依然无权访问——因为ACL还在，对应的用户没有可用的ACE。所以takeown和icacls组合使用才完整。
实际清理系统文件的常见顺序：
takeown /f "C:\目标文件夹" /r /d y icacls "C:\目标文件夹" /grant 管理员用户名:F /t /c这里的/d y表示对“是否允许对目录及其子文件夹进行更改”的默认回答选“是”。如果你不加，每遇到一个目录都会询问，半小时都跑不完。
其实到了这一步，权限基本已经拿到手了，再继续做删除或移动操作就顺了。
4.3 图形界面操作步骤详解
命令虽然快，但很多人还是习惯图形界面。这里把图形界面完整步骤写一遍，顺序别反了：
- 右键目标文件夹，选择“属性”。
- 切到“安全”标签页，点“高级”。
- 看“所有者”后面写的是谁，如果不是你的账号或Administrators，点右侧“更改”。
- 在“输入要选择的对象名称”里输入
Administrators，点“检查名称”，然后确定。 - 勾选“替换子容器和对象的所有者”——这个勾很重要，否则只有顶层目录改变所有者，下面的子文件夹还是老Owner。
- 等它跑完，再回到“安全”标签页，点击“编辑”。
- 在“组或用户名”列表里找到你要授权的账号，如果没有就点“添加”，输入账号，确定。
- 在下方权限列表勾选“完全控制”（或你需要的权限）。
- 确定退出，再次尝试删除或修改。
注意第5步：不勾选“替换子容器和对象的所有者”情况下，只会改顶层目录的Owner，子目录里的文件可能还是别人拥有，删除时依然报错。这个细节是出现“把Owner改了但还是删不掉”的根源。我见过无数帖子在问“我已经成为所有者了，为什么子文件夹里还是无权删除”，十有八九就是没勾这个选项。
4.4 PowerShell也能做，但尽量别忘管道
PowerShell的Get-Acl和Set-Acl也能改ACL，但出来对新手极不友好的一点是它内部用访问权限规则对象（FileSystemAccessRule），操作逻辑比icacls更繁琐。如果只是临时改一两个路径，用icacls比PowerShell简单。但如果你要审计大量目录的ACL，PowerShell是首选。
Get-ChildItem D:\共享 -Directory | ForEach-Object { $acl = Get-Acl $_.FullName [PSCustomObject]@{ 路径 = $_.FullName 所有者 = $acl.Owner ACE数 = $acl.Access.Count } } | Format-Table -AutoSize这个命令可以快速扫描几百个目录的所有者和ACE数量，用来找那些Owner异常（例如显示为未知SID）的目录非常方便。
5. 排查权限问题的思路模型
遇到权限问题，我的排查顺序固定分五步，按这个顺序走下来基本都能缩小问题范围到具体原因：
第一步：看Owner是谁。右键属性-安全-高级，第一行就是。如果显示一串数字SID（像S-1-5-21-...），说明Owner在系统中已经不存在了，要走先取回所有权的路。
第二步：看你当前账号到底申请了什么权限。点安全标签页里你的账号，看下方权限列表，注意“完全控制”有没有被勾上。如果账号不在列表里，就说明这个对象连你的一条ACE都没有，默认拒绝。
第三步：看ACE是否来自继承。高级窗口里，看ACE旁边的“继承自”列。如果写着“无”，说明这条是显式加的；如果写着父级路径，说明是从上面继承的。父级改权限时，这一类会跟着变，但如果子级断链了就没用。
第四步：看有没有拒绝权限。安全标签页下方的列表里，“拒绝”列的勾选状态很重要。任何“拒绝”项一旦出现，按前面说的判定顺序，它都会优先阻断同类型的允许权限，哪怕是管理员也逃不掉。
第五步：别忘了UAC提升。如果上面的ACL检查全部通过但还是提示“需要管理员权限”，问题可能根本不在NTFS层，而是当前窗口没有以管理员身份运行。这是最容易被忽略的一步，尤其是使用takeown、icacls、注册表编辑器时，没提升权限一切白搭。
把这个模型记住，基本所有权限问题都能在几十秒内定位到“是Owner问题还是ACE策略问题”还是“继承链问题还是UAC问题”。比对着错误弹窗瞎猜要高效得多。
6. 几个真实事故案例分享
6.1 删掉“Everyone”之后，整个部门的软件都用不了了
之前某公司做权限整改，我用一个脚本把所有共享目录里带Everyone的ACE全清掉了。清理完当天没事，第二天IT部门就炸了锅——某个业务系统安装在共享盘上，客户端连接后无法写入配置，因为客户端连接用的用户是IUSER_机器名这种匿名账户，之前就依赖对Everyone的写入权限，这个ACE被清理以后，所有客户端全部报错。
补救办法是把ANONYMOUS LOGON和Authenticated Users重新加回来，给最小必要权限，再改应用配置里连接用的账号。这事的教训是：Everyone权限虽然危险，但它是很多老旧系统的兜底权限。清理前先确认到底有哪些进程在依赖这个兜底，别用“一刀切”的方式做权限收敛。
6.2 拿到所有权的“别人家的移动硬盘”
同事拿了一个从竞争对手公司离职员工那继承来的移动硬盘，上面数据是加密的（EFS），分区上Owner是旧的用户SID。他们尝试把整个盘Owner改成Administrators，发现文件的加密标志还在，读出来全是一堆乱码。
这个案例提醒了一个概念：NTFS的EFS加密和数据权限是两码事。就算你改了Owner、加了完全控制权限，如果文件是用EFS加密的，字节流就是你读不到的密文。要恢复只能找到原账号的私钥，或者用第三方工具尝试密钥恢复，否则想“绕过”是绕不过去的。以后接手旧硬盘前，先确认是否有EFS加密标记，不然白折腾半天。
6.3 域环境下的SID迁移——旧管理员账号不在了怎么办
迁移服务器时，旧域里创建的文件夹Owner往往显示为S-1-5-21-...长长的SID，新域里根本没有对应账号。这种情况下，除非你用了域迁移工具做了SID History映射，否则Owner就是“未知账户”。时不时的，你明明添加了“Everyone”权限进去，系统还是提示无权限，这个坑在于“未知账户”依然持有ACE或Owner身份。
做法是用之前的POSIX ID工具或者直接在本地找一个Administrator强取所有权。注意：域环境里Administrators组的SID是固定的S-1-5-32-544，但域账号的SID是变化的。如果还有域控制器在线，可以直接用域管理员账号做域内权限变更；如果旧域已经不存在，就只能一个一个文件做“取回所有者”。
6.4 权限继承链断了以后共享文件夹的奇怪表现
生产环境里最迷惑人的问题就是：共享文件夹权限明明没改，但某个子目录里的所有新文件都没有权限。查了很多次ACL，子目录本身权限是对的，但新文件进来后直接变成“无权限”。
这个事的根源经常是子目录的ACL继承了共享级权限，但它本身没有显式权限，而父目录的继承链在某个环节断了。新文件生成时，是沿着文件创建者的默认配置去继承的，如果继承链断了，它继承到的可能不是父级的高权限，而是子目录里断链后的空ACL。所以遇到新文件无权限、旧文件正常的情况，优先排查子目录的“启用继承”状态，别瞎找别的。
7. 权限修复的进阶技巧与经验总结
7.1 把“ntuser.dat”这类隐藏地雷提前排查清楚
用户配置文件文件夹C:\Users\用户名里有个ntuser.dat，这是注册表配置单元文件。如果你在清理旧用户文件时强行删除它，可能把那个用户的所有注册表设置全干没，甚至导致用户配置加载失败。
做批量清理时，先用takeown和icacls改权限，但如果目标是ntuser.dat，我会额外检查有没有ntuser.dat.LOG1、ntuser.dat.LOG2这类日志文件，一起处理掉，才不至于删残留。
7.2 reset权限不等于删ACL完全重排
icacls /reset的神奇之处在于它会从父目录重新继承ACL，把所有显式条目清空。这个命令可以用来把被改烂的目录恢复到与父目录一致的状态。但如果父目录本身的ACL就不标准，reset之后依然是垃圾权限。
所以reset之前先看父目录，父目录ACL不对，先修父目录再说。另外，reset命令不要滥用，特别是系统分区根目录，C:\下面一旦reset错误，整个系统都会进入一种“路径全通、服务全坏”的诡异状态。
7.3 匿名共享和“Everyone”的折衷处理
如果业务系统确实需要匿名访问，那就不要给Everyone完全控制，给一个单独的账号或组限定最小权限，比如只给读取、不给写；或者建立专用匿名账号，只给这一个账号授权，不开Everyone。权限管理越细，后续排查越容易。
另外记得，共享级权限有“读取”“更改”“完全控制”三档，加上NTFS层再细算，最终生效的是两者交集。如果你必须在两者间取舍，共享级给“更改”，NTFS级别再精细控制，是最常见的组合。
7.4 权限审计与合规——不只是技术的“洁癖”
做企业文件服务器的人都会明白，权限这玩意儿跟审计绑定在一起。谁对什么目录有读取权、谁对工资表目录有修改权、谁把某个共享目录改成“完全控制”了，这些如果说不清楚，合规审计过不去。初始部署时花点时间理清组策略与ACL的关系，后面能省很多事。
顺序是：先建好安全组（比如“财务写组”“技术读组”），再把账号放进组里，最后在目录上给组授权。这样权限关系一目了然，后续换人离职也只用调整组内存，不用一个个目录去改ACE。
我也见过直接把账号添加到ACL里、没用组管理的场景，人员一变动，管理员就得跑几十个目录去改权限，累死累活还容易漏。
7.5 AI工具和权限交互的一点联想
最近经常看到AI工具运行起来后报权限错误，比如ChatGPT桌面版在Windows上创建文件时提示“需要一次性权限”之类。其实它底层也是普通的NTFS权限判定，只是安装器没把当前用户设为目录Owner，或者安装路径是Program Files导致写入受限。遇到这类问题，别慌，按上面的排查模型走：先看Owner、再看ACE、再看UAC，基本都能解。
不过提醒一句：给AI工具目录放开完全控制前，先想想这个工具会存什么数据、会不会被其他进程读取，别为了方便把所有目录权限都改成Everyone可读写，那等于给木马开后门。
8. 最后再分享一个小技巧
到了收尾的时候，我特别想提一个几乎所有NTFS教程都不会讲、但我实际用下来非常管用的小技巧：在修改一个目录的权限之前，先用icacls把当前ACL导出备份一份。
icacls "D:\共享目录" /save "D:\备份\共享目录.acl" /t以后万一改坏了想回滚，用这个命令恢复：
icacls "D:\共享目录" /restore "D:\备份\共享目录.acl"这条命令相当于给权限上了保险，操作前花几秒钟备份，能省下后面好几个小时的恢复工作。而且它能把整个目录树的权限一次性备份到一个小文件里，迁移服务器时也可以用。
我在实际工作中处理过太多权限改坏、Owner丢失、继承链断裂的问题，很多都是因为操作前没有任何备份和规划。NTFS权限这个东西本质不复杂，复杂的是权限叠加交互。如果你能记住两句话，这篇文章就没白看：第一，Owner是你动权限的入场券，先把所有权拿稳；第二，ACE的判定顺序和继承链是整个系统的灵魂，永远不要凭感觉去配权限。
按这两条走，Windows下的权限问题基本就没什么能难住你的了。
