看来，Windows 2008 R2 中共享和 NTFS 权限交互的方式发生了微妙的变化。在我们的应用程序中，我们需要将“写入属性”权限设置为“打开”，以便写入 OLE/DB 文档中的自定义属性。在 Windows 2003 下，将共享权限设置为Modify不会与此 NTFS 设置冲突，但在 Windows 2008 R2 下，我们必须将共享权限设置为 ，Full Control否则写入自定义属性将失败。
请注意，如果我能做到，那就没问题了。我认为共享权限设计得不好，如果有需要的话，还有其他更好的方法可以区别对待网络用户和本地用户。但我们的一些客户有严格的安全政策。
答案1
我不确定你在这里说什么。Windows ModifyServer 2003 和 Windows Server 2008 R2 中没有共享权限：
共享权限和 NTFS 权限之间的交互可能很复杂。共享权限采用更简单的视角。共享权限的粒度仅限于和Full Control。没有共享所有者的概念，也没有“共享权限继承”。为了让事情更加复杂，您可以多次共享同一个文件夹，每个共享都有独立的权限。如果您有“嵌套”共享，您将获得您映射的任何共享的共享权限。ChangeRead
NTFS 权限是总是强制执行，即使用户或进程是远程的。Windows 将考虑共享权限和 NTFS 权限并“计算”它们的有效权限。
大致流程是这样的：
- 收集所有共享权限并将它们组合在一起。A
Deny将覆盖任何Allowed。 - 收集用户对文件的所有 NTFS 权限。确保同时考虑显式和继承的 NTFS 权限。与共享权限一样，将
Deny覆盖任何Allowed权限。请记住，未继承或未明确分配的 NTFS 权限隐含地设置Deny。 - 合并共享权限和 NTFS 权限。如果存在重叠，则限制性更强的权限集为有效权限。
您可能在 Windows Server 2008 R2 中看到了更严格的解释Modify（或Change？），然后根据您限制较少的 NTFS 权限进行计算。我和 @Helge Klein 一样，找不到任何关于Modify共享“元权限”的实际原子权限的文档。
正如您所发现的，这个过程很复杂，而且容易出错。让生活变得简单，只使用 NTFS 权限进行访问控制。设置您的共享权限，使其完全开放（DOMAIN\Authenticated Users- Full Control），然后设置 NTFS 权限以提供所需的访问控制 - 类似以下内容是典型的：
DOMAIN\Authenticated Users-ReadDOMAIN\Accounting-Users-ModifyDOMAIN\IT-Admins-Full Control
这访问令牌用户或进程最终会包含更严格的 ACL，而不仅仅是它们的联合。这是唯一明智的做法，否则您必须在两个不同的位置使用两套不同的工具来维护和排除 ACL 故障。这种方式只会让人陷入疯狂。