假设用户Bob在组A和组B.对组A具有对文件夹X的写入权限，但是组B具有只读。
我们应该怎么做文件夹X？ 窗户在这种情况下做什么？ 这纯粹是一个人类唯一的错误？
目前，我们无法控制的域名遇到问题。 用户无法删除或修改任何“较旧”的文件（也许在上游进行更改之前）。 任何创build的新文件都被标记为“只读”。 当这个checkbox未被选中时，它会回来。
我们有什么可以做的吗？
这听起来好像你的共享权限被设置为完全控制在NTFS卷上设置的每个人和创build者所有者权限，这将允许用户创build文件，但只有他们可以打开并阅读它们。
我build议授予组A读取权限的共享和组X更改权限。 在共享文件夹的文件系统上，给组A读，组X写权限（如果你想让这个组具有删除权限），我build议修改这个组。 还要记住将所有其他权限留给完全控制的pipe理员和两个组（删除inheritance），并将permisisosn推送到子文件夹。
鲍勃将有写（或修改）访问，虽然他也在读组。
大多数Windows权限模型是围绕显式“允许”访问控制列表（ACL）而不是“拒绝”构build的。 NTFS（和Windows的其他部分）支持设置拒绝ACL，但它们并不常用。
使用“仅允许”权限的标准方法从没有任何权限的用户开始。 然后他们被赋予某些权利，而不是被明确地赋予“有或没有”的状态。 所以“只读”是（通常）没有写权限。 如果您有两个（或更多）来自两个独立安全主体的权限集（例如来自您的用户帐户和组成员资格或两个单独的组），则您将被授予来自所有主体的所有权限的结果，因此如果其中任何一个具有即使一个或多个个人安全主pipe只有“只读”权限，“写入”权限也会获得“写入”权限。
如果使用拒绝ACLS，则同样适用 – 如果用户或任何组被拒绝，则覆盖其他所有权的特定权限。
在你的情况下，拒绝权限不太可能被使用，Bob应该能够写入文件夹。 这可能比这个复杂得多。
在特定文件\文件夹的显式权限之上，您可以从较低级别inheritance（可选），因此对特定文件或文件夹的有效权限可能取决于在某个级别下设置的显式权限（即更接近根）你关心。
Windows共享拥有完全独立的安全模式 – 共享可以设置为只读\更改或完全控制。 如果共享设置为只读，那么将覆盖文件级别的权限，只要用户使用该共享名称连接即可。 具有Change \ Full Control权限不会覆盖基础NTFS权限。
最后还有标准的文件系统“只读”标志。 这不是一个权限，但如果它被设置，那么没有人可以改变文件，除非他们首先重置标志。
在Windows服务器上共享文件夹时，需要处理两组权限：共享权限和NTFS文件权限。
确保该组在“共享”选项卡以及“安全”选项卡上具有正确的权限。
如果该组仅具有只读共享权限，则取消选中只读checkbox不会产生任何影响。
您需要在“共享”的根目录下至less授予该组的“更改”权限。
有关NTFS权限的两篇很好的文章可以在第1 部分和第2 部分中find。
一般来说，权限遵循“最严格的”规则。 如果用户有两个权限冲突的组，则限制最多的组优先。 您的域pipe理员也可以查看每个用户的有效权限。