我正在设置一个networking共享（见下面的故事），我遇到了一些奇怪的行为与NTFS权限。 “CREATOR OWNER”对象似乎只能在“安全选项卡”中列出“特殊”权限。 不pipe我做什么，系统都会回到这个设置。 有没有办法让“创build者所有者”条目在安全选项卡中列出除特殊以外的任何东西？ 这将使检查权限错误更容易，因为我不必深入到高级选项卡，看看我为这个组设置了什么权限。 这是在连接到Windows Server 2008共享的Windows 7客户端上。
奖金问题：
我也想知道为什么“创build者所有者”组不能对“此文件夹”应用权限。 这似乎是这个小组的一个奇怪的怪癖，必须有一个背后的故事为什么这样设置。
我做了一些search，find了“权限如何工作” technet文章 。 我通过浏览“OWNER”权限的信息进行浏览，只发现了有关权限的一些信息。
[背景故事]
所以我有一个networking共享，用户将创build一个文件夹来存储他们的工作在一个特定的项目。 由于项目经理给我的参数，每个用户文件夹中的文件是私人的。 在这个参数之上，这个文件夹的用户在一年中会不断的改变，有些只会持续几天。 所以为了尽可能降低pipe理开销，我设置了权限如下：
我设置了权限，点击确定，一切正常。 后来，当我回来添加内容pipe理组到安全选项卡，我注意到一些奇怪的东西。 “创build者所有者”条目已从“修改”更改为“特殊”。 我进入高级权限，我注意到“CREATOR OWNER”只适用于“子文件夹和文件”。 然后，我尝试将“应用于”下拉菜单重置为“此文件夹，子文件夹和文件”，但只要点击“应用”就会切换回来。
谢谢
CREATOR OWNER访问控制条目应该始终是仅inheritance的，因为它们对于任何实际的对象都是没有意义的。 当使用现代API的最新版本的Windows时，所有CREATOR OWNER条目都自动标记为仅inheritance。
在高级GUI中，仅inheritance标志翻译为“仅子文件夹和文件”。 将其更改为“此文件夹，子文件夹和文件”将具有清除inheritance专用标记的效果，这对CREATOR OWNER来说是无法完成的。 基本的graphics用户界面可能不应该显示这是特殊的，但我想MS没有想到这个特殊情况。
CREATOR OWNER主要用于dynamic许可，因为人们在具有常规权限的文件夹中创build东西而不是懒惰的许可。 如果你这样想，这个概念可能会更有意义。
这只是Linux和Windows ACL中可用的POSIX ACL之间映射的限制。
谈论一个文件夹，在POSIX ACL中，您可以为内部创build的项目分配默认权限。 您可以为指定的用户和组显式执行此操作，但是有两个默认值适用于要创build的文件/文件夹的将来所有者（用户和组）。
default:user::rwx default:group::rx 那些分别映射到CREATOR OWNER和CREATOR GROUP 。 它们不适用于当前目录，所以当您查看Windows用户界面时，您会看到这些Subfolders and files only适用于Subfolders and files only 。 Windows会将其视为特殊权限并显示。
对于每个目录，您也有权将权限分配给所有者和组
user::rwx group::rwx
然而，当被Windows查询时，这些被立即转换为实际的所有者和组。 即使您授予创build者所有者对此文件夹的权限，这一更改也将会丢失 – 因为Windows会将其视为对实际所有者权限的更改。
所以在UI中你可能会看到：
Unix User - Root - Full Control, This folder only Unix Group - Root - Full Control, This folder only CREATOR OWNER - Full Control, Subfolders and files only CREATOR GROUP - Read and execute, Subfolders and files only
不幸的是我不知道把它合并成更具可读性的东西。
在处理NFSv4 ACL时，它会稍微不那么棘手。
权限“创build者所有者” – “此文件夹子文件夹和文件”被系统限制为“仅子文件夹和文件”。
创build者的用户无法创build文件夹。