很多人一提共享服务器就想到 Linux 或者成品 NAS，其实在最常见的内部几十人场景里，Windows 系统作共享服务器反而是上线最快、维护门槛最低的方案。它不挑硬件，装好系统就能开文件共享，真正容易翻车的，是多级权限设置。这里要管的不是“文件夹谁能看”这么简单，而是当同一个用户同时属于多个组、多个目录还要互相嵌套授权时，Windows 那套“共享权限 + NTFS 权限叠加”的规则很容易把新手绕晕。这篇文章就把我这些年实际配置 Windows 共享服务器的完整流程写出来，从权限原理、账号规划、目录设计，到一步一步设置多级权限、排查常见故障，尽量做到可以直接照着抄。
1. 先搞清楚：共享权限和 NTFS 权限到底怎么叠加
1.1 两套权限的关系
Windows 共享有两个完全独立的安全模型：共享权限（Share Permissions）和 NTFS 权限（Security / ACL）。只要用户通过网络访问共享文件夹，就必须同时过这两道关卡。
可以这样理解：共享权限是小区门口的保安，NTFS 权限是每栋楼里的门锁。保安让你进了小区，不代表你一定能进某栋楼；就算某栋楼的门锁给你开了，保安不放你进小区，你照样到不了楼下。最终能不能打开一个文件，取决于这两道关卡里更严格的那一个，按 Windows 的说法叫作取交集。
举个例子。某共享文件夹的共享权限只给了 Everyone“读取”，但 NTFS 权限里给了某用户“修改”。用户通过网络访问时，共享权限卡在“读取”，所以 NTFS 就算允许修改也没有用，最终有效权限还是只能读取。反过来，如果共享权限是“完全控制”，NTFS 只给了“读取”，最终权限仍然是“读取”。
还有一条规则容易被忽略：如果同一个用户同时属于多个组，这些组的“允许”权限是合并计算的。比如 A 组允许“读取”，B 组允许“写入”，那么最终 NTFS 有效权限就是“读取 + 写入”，等于是“修改”。但一旦出现“拒绝”权限，情况就变了，拒绝会直接覆盖允许，这个后面专门讲。
1.2 推荐思路：共享权限放粗，NTFS 权限放细
既然最终权限是两套取交集，那么最省心的配置思路就是：把共享权限全部放开，把真正的访问控制全部放在 NTFS 权限里。
新建共享时，默认的共享权限往往是 Everyone 读取，或者只有本地管理员有权限。我建议在共享权限里把 Everyone 设为“完全控制”，后续所有部门和人员的差异化授权，都在文件夹的“安全”选项卡里去改 NTFS ACL。这样做的好处是，以后新来一个用户，基本只需要把用户加进对应的 Windows 组，然后确认目录里的 NTFS 权限有没有包含这个组，不用同时维护共享权限和 NTFS 权限两套规则。
共享权限也不是完全没有用。如果某个共享目录需要临时停用，但你又不想动下面一大堆子目录的 NTFS 权限，可以直接把共享权限里的 Everyone 删掉，这样所有网络访问都会立刻被拒绝。另外，如果你要开放匿名访问或者给特定 IP 段开放，共享权限仍然是第一道快速开关。大多数企业内部共享场景，并不需要把共享权限做得很细，“粗共享权限 + 细 NTFS 权限”是性价比最高的组合。
2. 动手前先把账号、用户组和目录结构想清楚
2.1 用户组是权限管理的最小单位
我最开始给共享设权限时犯过一个错：直接在文件夹权限里一个个添加真实用户。以前公司只有 5 个人，还能应付，后来加到 30 人，新员工入职要加权限，离职要删权限，光是想起来谁在哪个目录有权限就够头疼了。
正确做法是建组。先建本地用户，再建若干本地组，然后把用户加进组，最后给组授权。这个流程不需要域环境，Windows 专业版和服务器版都支持本地用户和本地组。对应到域环境，就是经常听到的“AGDLP”思路：用户账户 A -> 全局组 G -> 本地组 DL -> 给资源权限 P。工作组环境可以把中间环节简化为“用户 -> 本地组 -> NTFS 权限”。
举个例子，某公司有销售部和财务部，我建议这样规划：
- 本地用户：user01、user02、user03
- 本地组：SalesUsers、FinanceUsers、SalesManagers、FinanceManagers
- 用户与组关系：user01 进 SalesUsers，user02 进 FinanceUsers，user03 进 SalesUsers 和 SalesManagers
以后某个销售要离职，直接把他的用户从 SalesUsers 组里移除，不需要去翻每一个共享目录的权限列表。如果销售部来新人，创建账号后加进 SalesUsers，所有销售共享目录的权限一次到位。
2.2 一套可直接抄的多级目录与权限矩阵
在做多级权限之前，一定要先画目录结构和权限矩阵。不让用户直接看到一堆杂乱的目录名，也不要在根目录上把所有组一股脑堆上去。我常用的目录结构长这样：
D:\Shares ├── Public 全员可读 │ ├── TeamPublish 编辑组可写，其他人只读 ├── Sales 销售部目录 │ ├── Leads 销售组读写 │ └── Reports 销售经理完全控制，销售组读写 ├── Finance 财务部目录 │ ├── Ledgers 财务组完全控制 └── ProjectHouse 项目共享目录 ├── ProjectX 项目组成员修改 └── Archive 项目组成员只读对应的权限矩阵可以整理成一张表：
| 目录 | 用户/组 | NTFS 权限 | 继承设置 |
|---|---|---|---|
| D:\Shares | Authenticated Users | 读取和执行 | 默认继承 |
| D:\Shares | Administrators | 完全控制 | 默认继承 |
| D:\Shares\Public\TeamPublish | TeamEditors | 修改 | 禁用继承 |
| D:\Shares\Sales | SalesUsers | 修改 | 禁用继承 |
| D:\Shares\Sales | SalesManagers | 完全控制 | 禁用继承 |
| D:\Shares\Finance | FinanceUsers | 完全控制 | 禁用继承 |
| D:\Shares\ProjectHouse\ProjectX | ProjectXUsers | 修改 | 禁用继承 |
注意一个细节：根目录 D:\Shares 本身不要给所有用户“写入”，只给“读取和执行”，否则普通用户在根目录一右键就能新建文件夹，没过几天整个共享盘就乱套了。子目录需要写权限，就在子目录上单独开，和根目录权限不冲突。
2.3 共享根目录的布局原则
共享根目录不要放在系统盘的用户目录下，最好放在一块独立的数据盘或专门分区。比如 D:\Shares 或 E:\SharedData。这样系统重装、备份、磁盘空间清理都方便。如果把共享目录放在 C 盘，一旦用户不停往里写文件，系统盘很快被撑满，Windows 可能出现各种奇怪故障。
目录命名也建议用英文或拼音，比如 Sales、Finance、Public，而不是直接用“销售部”“财务部”做路径。共享名可以是中文，但实际物理路径尽量用英文字符。很多老软件对 UNC 路径里的中文兼容性不好，英文路径可以从源头避免乱码和访问失败。
还有一条经验：共享根目录上显式保留本地 Administrators 组“完全控制”权限。哪怕财务目录这类敏感区域，也不要轻易把 Administrators 组完全删掉，否则后期需要维护时会很麻烦。管理员通过“取得所有权”依然可以重新获得权限，但那是最后手段，不是常规操作。
3. 保姆级实操：从零把共享和多级权限配出来
3.1 创建本地用户和组
先按快捷键 Win + R，输入 compmgmt.msc 打开“计算机管理”，左边选择“系统工具 -> 本地用户和组”。在“用户”上右键新建用户，输入用户名、全名和密码。如果这些账号是专门给共享访问用的，建议勾选“用户不能更改密码”和“密码永不过期”，同时取消“用户下次登录时须更改密码”。
然后右键“组 -> 新建组”，输入组名，把刚才建的用户点进去。比如创建 SalesUsers，添加 user01、user03。
不想点鼠标的话，用命令也可以。在管理员权限的命令提示符或 PowerShell 里执行：
net user user01 P@ssw0rd /add /fullname:"Sales Account" /passwordchg:no /expires:never net localgroup SalesUsers /add net localgroup SalesUsers user01 /add如果是 PowerShell，也可以用专门的本地用户模块：
New-LocalUser -Name "user01" -FullName "Sales Account" -PasswordNeverExpires New-LocalGroup -Name "SalesUsers" Add-LocalGroupMember -Group "SalesUsers" -Member "user01"要注意，用户名最好不要只写 user01 这种毫无业务含义的名字，至少要在全名里标注是哪个部门、哪个人用的。时间一长，靠猜是猜不出来的。
3.2 共享文件夹和放行防火墙
创建好目录结构后，右键 D:\Shares，选择“属性 -> 共享 -> 高级共享”。勾选“共享此文件夹”，共享名可以取 ShareCenter 或直接叫 Shared。点击“权限”，把 Everyone 添加进来，并勾选“完全控制”。
这一步很多人心里会打鼓：给 Everyone 完全控制是不是太危险了？先别急，共享权限这里只是给了“网络上能访问这个共享入口”的人最高网络访问权，真正能不能读、能不能写，由后面 NTFS 权限来卡。只要 NTFS 权限只给了某些用户或组读取，即使共享权限是 Everyone 完全控制，其他用户通过网络也只能读到 NTFS 允许的内容。
建议把“文件共享”相关端口放行。如果是同一局域网，Windows 防火墙默认会为“专用网络”放行“文件和打印机共享”，但如果你自定义过防火墙规则，还是需要确认。也可以在管理员 PowerShell 里手动创建一条安全规则，只允许专用网络访问 445 端口：
New-NetFirewallRule -DisplayName "Allow SMB 445 Private" -Direction Inbound -Protocol TCP -LocalPort 445 -Action Allow -Profile Private不要贸然把这条规则作用到“公用网络”。公共 Wi-Fi 环境里开放 445，等于把自己的共享盘暴露给同一网络里的所有人。
最后确认 Server 服务正常运行：
Get-Service LanmanServer Set-Service LanmanServer -StartupType Automatic Start-Service LanmanServer3.3 用 NTFS 权限实现多级控制
共享建立后，重点来到 NTFS 权限。右键 D:\Shares，进入“安全 -> 高级”。你会看到该文件夹可能继承了 D 盘根目录的权限。如果不想让所有能登录这台机器的用户都看到共享，我们需要在共享根目录这里先做一次“切断继承”。
点击“禁用继承”，在弹窗里选择“将继承的权限转换为显式权限”。之所以选转换而不是直接删除，是因为转换后还能保留原本来自磁盘根目录的 Administrator、SYSTEM 等关键权限，后面只需要在此基础上删减和添加即可。
在共享根目录 D:\Shares 上，我一般保留这些权限：
- Authenticated Users：读取和执行、列出文件夹内容、读取
- Administrators：完全控制
- SYSTEM：完全控制
然后删除 Users 组等其他多余条目。这里用“Authenticated Users”比 Everyone 更安全一点，因为 Authenticated Users 只包含通过身份验证的账户，不包含匿名账户。
接下来进入子目录。以 Sales 目录为例，右键 Sales -> 属性 -> 安全 -> 高级，同样先“禁用继承”，然后删掉根目录继承下来的 Authenticated Users 权限，再添加：
- SalesUsers：修改
- SalesManagers：完全控制
- Administrators：完全控制
之后，Sales 下面的 Leads、Reports 可以保持继承，这样它们的权限会和 Sales 一致。但如果Reports目录要求只有经理能看，那就在 Reports 上再次禁用继承，只保留 SalesManagers 完全控制和 Administrators 完全控制。
如果习惯用命令行快速设置，可以这样执行。以 Sales 目录为例：
icacls D:\Shares\Sales /inheritance:r /grant "SalesUsers:(OI)(CI)M" /grant "SalesManagers:(OI)(CI)F" /grant "Administrators:(OI)(CI)F"这里的参数含义：
- /inheritance:r 表示禁用继承并移除继承来的权限
- (OI) 表示文件会继承该权限
- (CI) 表示子文件夹会继承该权限
- M 表示修改
- F 表示完全控制
- RX 表示读取和执行
如果你希望把这个权限递归应用到目录下所有现有文件，在命令末尾加 /T /C。不加 /T 时，只有当前目录被改，子目录如果没有继承关系，旧权限可能还在。
多级权限设置的本质，就是“一层层复制、一层层切断”。根目录只读，子目录部分人修改，孙目录再有人只读或完全控制，每一步都是先禁用继承再明确授权。
3.4 客户端访问和映射网络驱动器
服务器端配置完成后，客户端访问很简单。按 Win + R，输入 UNC 路径：
\\192.168.1.10\ShareCenter工作组环境里，如果当前登录的用户不是共享服务器上的用户，Windows 通常会弹出凭据输入框。此时要注意用户名要写成“服务器名\用户名”，例如：
PC-SERVER\user01不是写你本机的用户名。如果勾选了“记住我的凭据”，之后会一直用这个账号访问，这个设置也会带来一个小坑，后面排错部分会说。
经常需要访问的目录，建议映射成网络驱动器。在命令行执行：
net use Z: \\192.168.1.10\ShareCenter\Sales /persistent:yes如果连不上，可以先删掉旧映射再试：
net use Z: /delete4. 继承、拒绝和有效权限：多级权限的真正难点
4.1 继承机制
多级权限设置绕不开“继承”这个词。Windows 默认情况下，子目录会自动继承父目录的权限条目。所以如果你在根目录给所有用户“读取”，那所有子目录天然都有“读取”。这在前期省事，但在做多级权限时是最大的坑：你改了子目录权限，但子目录的“继承”开关还开着，从父级来的旧权限仍然会继续生效。
看一个典型场景。D:\Shares 根目录给了 Authenticated Users 读取，Public 等子目录都正常继承，用户在根目录能看到所有子目录名称，也能打开有读取权限的目录。假设 Sales 目录禁用了继承，并且只给了 SalesUsers 修改，那么就算用户是 Authenticated Users，如果他不属于 SalesUsers，他在访问 Sales 时依然会被拒绝。因为 Sales 不再继承根目录的 Authenticated Users 权限，根目录的读取权限到不了 Sales 里。
反过来，如果子目录没有禁用继承，你只给子目录添加了一个新组，而没有删除父级继承来的大范围权限，那么父级继承来的“所有人读取”仍然会保留。最典型的情况是：你在公共根目录建了一个“财务”文件夹，里面只想给财务组读写，随手加了个 FinanceUsers 权限，却忘记把根目录继承下来的 Authenticated Users 读取权限删掉，结果全公司都能打开财务目录里的文件。
判断一个权限是不是继承来的，最直接的方法就是打开“高级安全设置”，看“继承自”这一列。如果是来自父目录的权限，会明确显示来源；如果是手动添加的，来源就是“无”或显示为直接权限。多级权限配置中遇到“我明明改了怎么没生效”，八成是继承关系没有理清。
在某些共享投递场景里，还需要用到“创建者所有者”特殊权限。例如希望每个人都能往某个文件夹扔文件，但不能看到别人扔的文件，普通 NTFS 权限做不到，需要进高级权限设置，只给“创建文件夹/追加数据”之类的特殊权限，同时给“创建者所有者”赋予完全控制。这个配置不常用，但理解了继承和特殊权限后，可以在共享服务器上做很灵活的协作目录。
4.2 拒绝权限为什么是双刃剑
NTFS 权限里有一个“拒绝”类型。它的优先级高于“允许”，而且在实际生效判断时基本是一票否决。比如用户 A 属于 SalesUsers，SalesUsers 有修改权限，但你又在 Sales 目录上单独给用户 A 设置了一条“拒绝读取”，那么用户 A 最终会被拒绝读取，哪怕他所在的组有修改权限。
这条规则看起来好用，实际上非常容易被误用。举个例子，公共目录写了“Authenticated Users 允许读取”，但某个人犯了错，领导要求不让他看公共目录。有人会偷懒直接在公共目录上给这个用户加一条“拒绝读取”。这样做的隐患是：如果公共目录下面有子目录，子目录又给这个用户所在的组一些自己权限，拒绝条目可能会通过继承扩散到很多子目录，之后排查时完全想不起来是哪一层加了拒绝。
我的建议是，默认不用“拒绝”，而是靠组关系来控制。某个用户不该有某个权限，就不把他加进有权限的组；如果他被一个大的组包含了，那就想想能不能拆组，或者针对他单独建一个“无权限”的排除流程。除非遇到极端情况，比如系统里有 Everyone 或 Domain Users 这类没法拆的组，才考虑用拒绝。而且在添加拒绝之前，一定要在测试目录里模拟验证。
共享权限层同样不建议使用拒绝。共享权限和 NTFS 权限已经存在取交集关系，再叠一层拒绝，排查难度会成倍上升。
4.3 用“有效访问”和命令查真实权限
Windows 的“有效访问”功能可以直接算出某个用户对当前目标文件夹能做什么。右键目录 -> 属性 -> 安全 -> 高级 -> 有效访问，然后点击“选择用户”，输入要查看的账户。这里会列出读取、写入、删除、列出文件夹内容等具体权限。
需要注意，“有效访问”只能计算 NTFS 权限，不会把共享权限一起算进去。要查询共享权限，可以用 PowerShell：
Get-SmbShareAccess -Name ShareCenter | Format-Table AccountName,AccessControlType,AccessRight如果要看某个目录的 NTFS ACL，可以用 Get-Acl：
(Get-Acl "D:\Shares\Sales").Access | Select-Object IdentityReference,FileSystemRights,AccessControlType,IsInherited | Format-Table这样能快速看到一条权限是允许还是拒绝，是继承来的还是直接设置的。排查的时候可以先看共享权限，再看 NTFS 权限，最后用“有效访问”确认，基本就不会漏。
5. 企业环境里最常见的坑和排查实录
5.1 共享权限和 NTFS 权限打架
很多时候，用户说“我能打开共享目录，但打不开某个子文件夹”，原因就是共享权限给了网络入口，但 NTFS 权限没给这个子目录。这是设计多级权限时最正常的情况，不一定是故障。
另一种更隐蔽的问题是，共享权限只给了 Everyone“读取”，但 NTFS 权限把某个部门根目录设成了“完全控制”。结果部门里的人想新建文件，却一直提示“访问被拒绝”，改 NTFS 权限也没用。用前面说的Get-SmbShareAccess查一下，发现共享权限卡在读取，就会恍然大悟。
所以排查“无法写入”类问题，顺序应该是：
- 查共享权限：是否有允许写或完全控制的条目
- 查 NTFS 权限：用户所属组是否有修改或写入
- 查是否被“拒绝”条目拦截
- 查用户是否同时拥有多个组身份，某些组之间权限冲突
5.2 Guest、凭据和 SMB 版本问题
Windows 工作组环境里，最常见的共享访问失败原因不是权限本身，而是身份验证模型出问题。打开本地安全策略 secpol.msc，找到“本地策略 -> 安全选项 -> 网络访问: 本地账户的共享和安全模型”，默认值可能是“仅来宾 - 对本地用户进行身份验证，其身份为来宾”。这种情况下，共享服务器上的本地用户不会按自己的身份来验证，而是被当成来宾处理。
如果是公司内部共享，建议把它改成“经典 - 对本地用户进行身份验证，其身份为他们自己”。改完后，客户端连接共享时输入的服务器本地账号，才能真正对应到共享服务器上的那个用户。
还有一个常见问题是凭据管理器里的旧凭据。客户端曾经用 user01 连接过共享，后来 user01 密码改了，或者这个账号被删除了，但客户端还缓存着旧凭据。这时候每次连接都报错，输入框也不弹出来。处理方法是在客户端命令行里执行：
cmdkey /list如果看到旧的目标地址，用下面的命令删掉：
cmdkey /delete:旧目标名然后重新连接共享，重新输入账号密码。
关于 SMB 版本，不要为了兼容老机器去开启 SMB1。Windows 默认使用 SMB 2/3 就足够安全可靠，SMB1 漏洞多、性能差，在现代网络里没有任何必要开启。如果老设备非要连，建议先升级设备系统，而不是降低服务器安全标准。
5.3 复制移动文件后权限失效
文件在移动和复制时，权限变化规律经常被忽略。同一磁盘分区内移动文件夹，一般会保留原有权限；跨分区移动或复制，本质上是“创建新文件”，新文件会继承目标父目录的权限。所以很多人把财务目录从一个盘剪切到另一个盘，或者用资源管理器复制到新目录后，发现权限全变了。
处理办法很简单：迁移共享目录时，不要用鼠标拖拽剪切，用 Windows 自带的 robocopy，并且带上 COPYALL 参数，可以保留 ACL、所有者、时间戳等属性：
robocopy D:\Shares \\目标机器\ShareCenter\Shares /E /COPYALL /DCOPY:DAT /R:3 /W:5如果已经发生了复制移动，权限丢了，那就只能重新设置 NTFS 权限。这也是为什么建议在改动之前先用 icacls 导出一份 ACL 备份，后面会专门讲。
5.4 常见问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 网络邻居里看不到共享 | 网络发现未开或防火墙阻止 | 启用网络发现，放行文件打印机共享 |
| 能看到共享名称但进不去 | 共享权限或 NTFS 权限没有该用户的条目 | 检查共享权限和 NTFS 安全选项卡 |
| 能打开文件夹但无法新建文件 | 共享权限没有写入，或 NTFS 没有修改/写入 | 检查两套权限，取交集后确认 |
| 用户刚加入组仍然没权限 | 登录会话中权限令牌未刷新 | 注销重新登录，或断开共享重连 |
| 始终提示用户名或密码错误 | 凭据管理器存了旧凭据 | cmdkey /list 并用 cmdkey /delete |
| 复制到新盘后权限全变了 | 跨卷复制继承目标父目录权限 | 使用 robocopy /COPYALL 迁移 |
| 明明有允许权限却被拒绝 | 存在拒绝权限条目，拒绝优先 | 检查 ACL 中的拒绝条目 |
| 所有本地账号都变成 Guest | 本地安全策略用了“仅来宾”模型 | 修改为“经典”模型 |
6. 权限备份、恢复和日常维护
6.1 用 icacls 做 ACL 快照
多级权限配完之后，最重要的事就是备份。Windows 自带的 icacls 可以把目录下所有文件和子目录的 ACL 导出到一个文本文件。以管理员身份运行：
icacls D:\Shares /save D:\acl_backup_2025.txt /t /c其中 /t 表示递归所有子目录，/c 表示遇到错误继续执行。保存下来的文件记录了每个对象对应的权限条目，之后如果需要回滚，执行恢复命令：
icacls D:\Shares /restore D:\acl_backup_2025.txt恢复前最好先在一两个测试目录上验证，不要一上来就恢复整个大目录，否则万一备份文件路径不匹配，反而会把权限搞得更乱。
6.2 共享配置的导出与重建
NTFS ACL 备份解决了目录权限，但共享本身的配置也需要留底。可以用 PowerShell 导出当前共享信息：
Get-SmbShare | Select-Object Name,Path,Description,FolderEnumerationMode | Export-Clixml D:\smb_share_config.xml Get-SmbShareAccess -Name ShareCenter | Export-Clixml D:\smb_share_access.xml以后如果系统重装或换服务器，可以先按照导出的 XML 查看共享名、路径、描述，再用 New-SmbShare 把共享重新建起来，然后恢复 NTFS ACL。导出的 XML 不能直接一键恢复，但至少能让你不用靠记忆。
6.3 日常巡检建议
共享服务器平时不用天天盯，但建议定期做一次权限巡检。我习惯每个季度跑一次命令，把存在“拒绝”权限的特殊条目找出来，再确认关键目录的所有者没有异常。
导出当前所有 ACL 到文件：
icacls D:\Shares /save D:\share_acl_quaterly.txt /t /c再用 PowerShell 列出所有共享访问规则：
Get-SmbShare | ForEach-Object { Get-SmbShareAccess -Name $_.Name } | Format-Table -AutoSize如果有同事离职，优先处理两件事：一是把该用户的共享访问账号禁用或删除，二是检查这个账号是不是属于多个本地组，避免遗留后门。用户账号被禁用后，即使本地组里还留着名字，也无法通过身份验证。
6.4 几条实际项目中沉淀下来的经验
最后说几句这几年配置 Windows 共享服务器的一些个人体会。多级权限设置不是越复杂越好，我曾经见过一个共享目录嵌套了六七层，每一层都有不同的组和权限，最后连配置的人自己都说不清楚谁能访问哪里。后来我给自己定了一个习惯：目录层级超过四层就重新设计，每个子目录尽量只保留明确要授权的两三个组。
实际操作上，先把根目录权限固定成“全员只读 + 管理员完全控制”，再逐层向下禁用继承并添加部门组，顺序一定不要反。先改子目录权限，再回头动根目录，很容易把已经设置好的继承关系覆盖掉。
“拒绝”权限尽量不用。如果需要限制某个人的访问，我会通过调整组关系来实现，而不是在目录上加一条拒绝。组关系确实要花精力维护，但它比拒绝权限稳定、可解释、可审计。
如果你现在维护着一个已经跑了好几年的共享盘，建议先做一次 ACL 快照，然后把每个目录的权限导出来对照一下。Windows 作共享服务器本身不难，真正难的是权限长期不乱。只要一开始把结构想清楚，后面日常维护其实非常轻松。
