这一直在困扰着我。 我正在将未join我们的域的独立文件服务器转换为使用AD Groups \ Users作为文件共享的过程。 此文件服务器用于使用本地计算机帐户的共享权限。 我已经将文件服务器join了域，所以现在我想用正确的共享权限replace共享权限。
也许我需要这个解释给我，但由于某种原因，我不能得到它的工作。 例如，我有一个共享文件夹：
\\fileserver\jsmith 在此文件夹上设置共享权限，以便AD用户John Smith具有完全控制。 NTFS权限（这就是安全选项卡中的权利？）设置为：
FILESERVER \ Adminstrators – 完全控制
创build者所有者 – 特殊权限被检查和灰色
SYSTEM – 完全控制，虽然它是灰色的（以及Allow列中的其他checkbox）
FILESERVER \ Users – 读取和执行，列出文件夹内容和读取（全部变灰）
从我的理解（也许我错了），用户John Smith应该能够访问\\filserver\jsmith并能够打开任何文件和文件夹，以及创build文件和文件夹。
然而，这种情况并非如此。 尝试访问此共享时，John Smith会收到“拒绝访问”消息。
编辑 ：澄清，当约翰·史密斯在共享（ \\fileserver\jsmith ）的UNCpath中键入到Windows资源pipe理器中，并击中回车他得到访问拒绝消息。
也许我不了解这一切。 那么，什么是“正确”的方式来实现我想要的：一个AD用户或组具有读取和写入访问共享文件夹。
尝试访问共享时，“DOMAIN \ JSmith”用户不应该得到“访问被拒绝”，而应该在尝试创build或修改托pipe在那里的文件时获得“访问被拒绝”。 你能澄清你的意思吗？“当John Smith试图访问这个共享时，得到一个拒绝访问的信息。 与我先前的声明？
一般来说，“共享权限”应该始终设置为“每个人/完全控制”。 从人们可能共享非NTFS卷上托pipe的文件夹的时代来看，这是一个大脑受损的错误特征。 （有人想争论呢？嘿嘿…）
“共享权限”由“服务器”服务强制执行。 如果用户能够通过其他方法访问文件（文件系统中“共享”不同的“共享权限”，使用其他协议通过IIS导出的文件等），则“共享权限”将不适用。 在NTFS权限中指定您的权限，然后无论用户如何访问这些文件，NTFS驱动程序都将执行所需的权限。
为了学术目的，我将解释“共享权限”是如何工作的（但是我仍然鼓励你总是把它们设置为“Everyone / Full Control”）：“服务器”服务（处理通过SMB协议）validation底层NTFS允许用户尝试访问（读取，写入等），然后检查用户对“共享权限”的企图访问。 如果任一权限不允许所需的访问，则访问尝试失败。 在“共享权限”中使用“完全控制”权限设置“DOMAIN \ JSmith”不会更改未授权的NTFS权限。 在文件系统级别，“DOMAIN \ Domain Users”组的成员“DOMAIN \ JSmith”具有读取，执行和列出文件夹内容权限，方法是将“DOMAIN \ Domain Users”默认嵌套到“FILESERVER \ Users“组，当您join域。
除了专门为该用户专门创build的文件夹（例如漫游用户configuration文件文件夹或主目录）之外，您不应该为每个用户指定权限。 由于这个份额被命名为“JSmith”，我会猜测这是一个主目录。 添加“DOMAIN \ JSmith”与“修改”或“完全控制”（取决于你是否希望JSMITH能够修改文件夹和子文件夹的权限或不 – “完全控制”将给他的权利）该文件夹的ACL，你应该很好去。
如果共享文件夹用于其他目的（例如，用于“工作angular色”或用户之间的共享） ，则应用权限的正确方式（tm）是创build描述与访问相关联的angular色的组（例如“采购部门“），授予NTFS文件夹资源的权限（比如”修改“），并将相应的用户放入该组。
当一个工作angular色改变或更替发生时，您只需要把“新人”放入适当的组，并确保他们获得资源。 如果您为个人用户授予权限，那么确保访问新用户的唯一方法是访问每个资源并添加新权限（如果工作angular色发生更改，可能会删除旧权限）。 如果你没有保存好你对各个用户应用各种权限的地方的文档，那么你将永远无法创build一个新的用户，使其拥有与现有用户相同的权限，而无需对你的资源进行大量的调查。
即使一个小组要有一个成员，也要创build一个小组。 稍后当你不得不指派其他人join时，你会感谢你。
编辑：
访问控制列表（ACL）是应用于资源的访问控制条目（ACE）的列表。 ACL是您在“属性”页面的“安全”选项卡上以及在“高级”对话框中看到的内容。 ACL的每一行都是一个ACE。 （我想我会带“ACE”，以防万一你在文档中看到它，并想知道它是什么意思…）
您在“安全”选项卡和“高级”对话框中看到相同的内容，只是呈现方式不同（在“高级”对话框中有更多详细信息）。
我遇到麻烦了，为什么您在访问共享时可能会看到“拒绝访问”（Access Denied）。 随着JSmithlogin到他的客户端计算机与他的域帐户，和FILESERVER计算机join到域，你不应该得到一个“访问被拒绝”。 你确定JSmith是用他的域帐户在客户端计算机上login？
实际上，您遇到的问题是最严格的安全政策。 因此，如果您拥有对读写文件夹具有只读权限的共享，则您将获得只读权限。 同样，如果你有一个读写权限的共享，但该文件夹是只读的，你会得到只读。
我并不是说这是正确的做事方式，但是我经常看到Everyone RW的共享，并且共享文件夹的NTFS权限。
如果共享不在驱动器的根目录下，必要的用户帐号至less具有遍历目录吗？
例如：如果您有一个名为D：\ Users的文件夹，然后是其中的文件夹，那么这些帐户需要能够遍历D：\和D：\ Users，否则它们将接收到拒绝访问。
更新：从Evan的反馈中删除不正确的陈述。
当您使用共享文件夹时，您需要考虑两组权限：
首先，共享本身的权限。 这就像夜总会门口的保镖。 如果连接用户在这个级别上没有权限，那么无论文件夹本身有什么权限，他都将被拒绝访问。
其次，您对该文件夹有权限。 如果用户有足够的权限访问共享但不能访问该文件夹，他将被拒绝。 文件夹不以任何方式从共享中inheritance权限。
在这两个级别上，您都可以使用本地或域级帐户。 在一个典型的文件服务器上，除了Windows所需的帐户以外，不会有任何本地帐户。
如果您为多个用户设置此共享，则需要为包含所有需要访问的用户的安全组授予权限。 然后，您在底层文件系统上使用NTFS级别的权限，以便对谁可以做什么进行细粒度的控制。
你需要做的，而不是为每个用户设置一个单独的共享，而是build立一个名为“用户”的单个顶级共享。 在“共享”级别为此添加足够的权限，以便所有域用户都可以访问它。 然后在这个共享下，为每个用户创build一个子目录。 不要共享这个，只需在其上设置所需的NTFS权限即可。 用户将通过\\ servername \ users \ username访问它。