我在 Google 或 Technet 上找不到答案的问题......
授予SYSTEM用户对 DFS 共享文件和文件夹的权限是否会对 DFS 复制产生影响？（既然我们讨论这个问题，有什么好的理由吗？不是让其SYSTEM拥有对DFS共享文件的权限？）
出现此问题的原因是，我拥有一组 DFS 命名空间和文件夹，无法将其作为其他人的问题，并且在解决一个 DFS 副本由于没有明显原因而无法与另一个副本复制的问题时，我发现该SYSTEM帐户没有授予该文件夹中任何文件或文件夹的任何权限。
因此我设置SYSTEM为完全控制并将其传播下去，我们的 DFS 健康诊断报告从显示积压约 80 个文件增加到积压约 100,000 个文件...并且事情开始复制，包括一台或另一台服务器上丢失的许多文件（因此不仅仅是权限更改开始复制）。
自然，这让我很好奇，DFS 是否需要该SYSTEM帐户具有权限才能执行其工作，或者也许只是对相关文件夹树的任何更改促使 DFS 采取行动。如果这很重要，我们的 DFS 命名空间是在 2000/2003 下设置的，我最近刚刚将所有服务器升级到 2008 R2 或 2012（启用了 UAC，呸），但还没有开始将 DFS 命名空间功能级别提升到 Server 2008。
SYSTEM（如果有人有关于 NTFS 文件权限以及与 DFS 或网络文件相关的账户的官方 Microsoft 文章，则可以获得加分。）
答案1
technet 上的这个帖子说 SYSTEM 需要完全控制。然而，这不是一个非常官方的消息来源，进一步的测试证明这是错误的。
DFS 复制服务
我使用 Process Explorer 查看了 Server 2008R2 计算机上的 DFS 服务。分布式文件系统复制服务 dfsrs.exe 以“NT Authority\SYSTEM”身份运行。但是，它备份权限和恢复特权：
备份权限- 执行备份操作所需。此权限使系统授予对任何文件的所有读取访问控制权，而不管为文件指定的访问控制列表 (ACL) 如何。除读取之外的任何访问请求仍将使用 ACL 进行评估。3
恢复特权- 执行恢复操作所需。此权限使系统授予对任何文件的所有写入访问控制权，而不管为文件指定的 ACL 如何。除写入之外的任何访问请求仍将使用 ACL 进行评估。此外，此权限使您可以将任何有效的用户或组 SID 设置为文件的所有者。
有了这些权限，DFS 复制服务可以忽略任何文件权限 - 它被授予读取、写入和设置任何它想要的文件的权限。
测试
我在我的一个 DFS 共享中创建了一个文件夹，其中包含一些文件，将我的帐户设置为所有者，并删除了除我的帐户之外的所有权限。
DFS 将其毫无问题地复制到所有其他服务器，并且所有副本都具有相同的权限。
因此，DFS 不依赖于任何文件系统权限来复制。
我怀疑，就你的情况而言，只要对文件进行任何更改，DFS 就会被唤醒，并发现它们需要复制。不过，我并不知道是什么导致了这种情况。
答案2
根据微软的这篇文章http://support.microsoft.com/kb/120929 “系统账户与管理员账户（Administrators组）拥有同样的文件权限，但是功能有所不同。”
这意味着系统帐户与本地管理员相同，其存在的目的是以管理员权限运行系统服务而无需密码。DFS-R 中的复制过程使用此帐户执行。
系统用户在文件系统或 DFS 设置中与普通管理员没有任何特殊意义。但是，这可能会造成混淆，因为 Windows 管理员并不总是以管理员权限进行操作，具体取决于程序或 shell 的调用方式，而系统帐户可能始终以升级/管理员令牌进行操作。我猜你的 DFS 设置只是存在错误，修改 ACL 可能会导致进行一些系统调用，或者打开/刷新文件句柄，从而摆脱众所周知的蜘蛛网。