如果它被移动/复制到同一个卷中的另一个目录，则从父文件夹inheritance

任何处理文件服务器权限的人都知道，NTFS有一个有趣的devise特性/缺陷，称为移动/复制问题。

正如本MS KB文章所述，如果移动文件夹并且源和目标位于同一个NTFS卷上，则文件夹或文件的权限不会自动从父项inheritance。如果复制文件夹或源和目标位于不同的卷上，权限将被inheritance。

这里是一个简单的例子：

在同一个NTFS卷上有两个名为“技术人员”和“经理”的共享文件夹。技术人员组可以通过RW访问技术人员文件夹，pipe理员组可以通过RW访问“pipe理人员”文件夹。如果某人有权访问这两个文件夹，并将子文件夹从“pipe理员”文件夹移动到“技术人员”文件夹，则移动的文件夹仍然只能由“pipe理员”组中的用户访问。 “技术人员”组即使位于“技术人员”文件夹下，也不能访问该子文件夹，并且应该从顶层inheritance权限。

正如你可以想象的，这会导致支持电话，票证和浪费周期解决这些最终用户问题，更不用说老鼠的权限巢，如果用户经常移动文件夹之间不同的安全文件夹/区域相同的音量。

问题是：

什么是解决这个NTFSdevise缺陷的最佳方法，以及如何在您的环境中处理它？

我知道链接的知识库文章谈到了一些registry键来改变Windows资源pipe理器的默认行为，但他们是客户端，并要求用户有能力更改权限，我认为在大多数环境中是一个非启动器，如果你想要保持对文件服务器权限的控制权（以及系统pipe理员的理智）。

我的做法是不使用文件/目录级文件的权限; 使用文件共享级别权限，并将整个服务器文件系统数据驱动器设置为“每个人完全控制”（这将成为模拟）。

多年来（10+），我发现NTFS权限更复杂，导致更多的错误。如果权限设置错误，或者inheritance被破坏，那么您将暴露数据，并且很难find并查看它。另外，你说的是暴露于移动/复制的问题。

您必须使用目录/文件级ACL的地方; 我知道没有其他的解决办法，而不是定期检查事情。

那么这不是一个真正的缺陷。这个移动文件的权限处理规则至less在NT3.1 beta2（尽pipe显然不是inheritance，因为只是在Windows 2000中增加了）而已经到位。这是众所周知的任何function的Windows可以。我对你们的观点非常同情，因为在这个阶段，我们中很less有人没有被烧掉。但这是系统pipe理员快速学习的东西。

自NT 3.51以来，我们一直在使用NTFS，尽pipe我们已经看到了这个“问题”（几乎每个人都有这个问题），但并没有给我们带来什么麻烦：

如果需要将文件从一个共享目录移动到另一个共享目录，我们总是告诉人们复制文件。 “拖动时按住CTRL键，确保小键盘正在显示”是一个常用的词组。
我们的共享文件夹结构相当简单，而且我们创build的共享文件夹不经常在组间交叉，所以人们更希望首先复制文件。
我们看到问题主要出现在我们的“共同”空间 – 每个人都可以读/写的文件夹中，但是这些目录大多是短命的，所以在清除问题时问题就消失了。

我可以想到的解决方法：

find一些使不同权限的文件夹位于不同的NTFS卷上的方法
根据支持请求的频率执行计划任务（每天一次或每天一次），并将所有权限重置为与顶级相同。这并不理想，如果这些文件夹中有许多文件，更是如此，但如果没有好的解决scheme（如服务器端registry修补程序），可以解决问题。您将要查看的命令称为“cacls”，然后您可以将其添加到batch file中。

免责声明 – 我来自unix背景（并已实施了最后一个修复不同的权限缺陷 – 它感觉icky，但没有工作），所以可能有一个更好的解决办法。

当作为pipe理员移动时，我使用xcopy / s / e / c / h / r / k / y – 除了文件所有权和ACL之外的任何东西，这意味着ACLinheritance自动启动。从来不需要处理用户感动的东西虽然。

我使用组策略/安全策略/文件系统来跟踪复杂的权限。（切勿使用策略中的“replace权限”）。

安排一个CACLS在晚上重置所有权限，然后在gpupdate / force之后重新应用来自策略的权限。奇迹般有效。

从Windows 7（或者Windows Vista）开始，如果文件夹被移动并且源和目标位于相同的NTFS卷上 – 如果正在通过资源pipe理器复制文件或文件夹，则文件夹或文件DO的权限将从父项inheritance。在早期的操作系统中，您可以使用远程pipe理器 – 它允许从目的地启用权限inheritance（以及大量的其他function）。尽pipe对于一般用户来说远可能看起来不友善。

一个非常简单的解决方法是只压缩文件并将其解压到目标目录。