我们有 FreeNAS-9.2.1.3-RELEASE-x64 为 IIS 提供 Samba 共享（由 2012 R2 托管，如果相关的话）
ssasan01# smbd --version Version 4.1.6
freenas 服务器已加入 Windows 服务器提供的 AD。域为“AD”。IIS 站点以该站点独有的 Active Directory 用户身份运行。应用程序池（每个站点都有自己的应用程序池）标识和 IIS 中站点的“物理路径凭据”都配置为同一个 Active Directory 用户。
除了创建文件夹外，大多数情况下一切都正常。在 IIS 用户可以访问（写入/修改/读取/执行）（实际上是 App_Data）的文件夹中，应用程序代码尝试使用 DirectoryInfo.Create 创建文件夹。生成的文件夹在磁盘上成功创建，并且似乎从父级继承了 ACL 权限，但是创建调用返回错误。
Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.UnauthorizedAccessException: Access to the path --snip--\App_Data\packages\created\__testFolder__ is denied.
日志 samba 日志中出现以下错误（级别目前为 1，因为这是生产服务器）
Sep 8 17:28:05 ssasan01 smbd[54843]: [2014/09/08 17:28:05.026127, 0] ../source3/smbd/open.c:543(change_dir_owner_to_parent) Sep 8 17:28:05 ssasan01 smbd[54843]: change_dir_owner_to_parent: failed to change current working directory to --snip--/App_Data/packages/created/__testFolder__. Error was Permission denied
（--snip-- 替换基本路径）
文件似乎正常工作。如果我通过 SSH 查看创建的文件夹，我会看到以下内容：
d-w-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__
（AD\applicationpoolidentity 是站点的用户，组与其他文件夹相同）
如果我尝试使用 Windows 资源管理器创建文件夹，同时以有权访问共享（并有权写入相关文件夹）的用户身份登录，则会出现相同的错误/问题。至少根据 Windows，该文件夹设置为继承权限。在这种情况下，新创建的文件夹没有分配给它的任何 ACL（资源管理器对创建的文件夹没有权限），但我怀疑这很可能是由于操作顺序类型的问题，因为当 IIS/.net 在其他情况下创建文件夹时，事情发生的顺序与通过资源管理器创建文件夹时的顺序不同。
我手动检查了 smb.conf 文件以消除潜在的 GUI 问题，以下是我通过 Google 搜索此问题后发现的所有可能相关的问题。我在测试时添加了“强制创建模式”和“强制目录模式”。
unix extensions = no
acl check permissions = true
acl map full control = true
create mask = 0666
directory mask = 0777
force create mode = 0666
force directory mode = 0777
inherit owner = yes
inherit permissions = yes
inherit acls = yes
writeable = yes
browseable = yes
注意：所有文件夹和文件都是通过 samba 客户端创建的（而不是直接从 linux shell 创建的），可以通过以对该文件夹具有权限的用户身份执行的 IIS 代码创建，也可以通过以具有创建文件和文件夹权限的用户身份登录到服务器时通过 windows 资源管理器窗口创建。文件似乎可以正常工作。
我们在这里使用 freenas 是因为 ZFS 快照和冗余，它还为其他机器提供 NFS 服务，为其他机器提供 iSCSI，因此用基于 Windows 的文件服务器（或者另一个 SAN/NAS 服务器）替换该服务器，虽然这并非不可能，但不是一件容易的事。
一个可能的奇怪之处是所有者整个树的所有文件夹和文件都是管理级别的用户（不是管理员！），以允许我们能够以管理员身份访问和更改权限。
更新 1：从日志中的错误来看，文件夹似乎已成功创建，但 samba 进程无权更改到该文件夹以设置权限。父文件夹（在本例中为“created”）配置了以下掩码：
d---rwx---+。如果我chmod 777 created（我尝试在其中创建新文件夹的文件夹），则 IIS 进程（和 Windows 资源管理器）都可以在该子目录中成功创建和删除文件夹。
我们正在使用两个不同的过程进行测试：使用 Windows 资源管理器进行测试时，我以域用户的身份登录 Windows，该用户是父文件夹的“所有者”和“组”。同一用户还通过 ACL 获得了完全控制权。组通过掩码具有 rwx 权限。通过 .net/IIS 进行测试时，池以通过 ACL 授予写入/修改/读取（除完全控制之外的所有权限）的用户身份运行。此用户不是所有者或组，并且没有针对所有人的掩码权限。
如果我尝试创建的文件夹是其直接父文件夹，则错误消失，一切正常chmod 777。我认为这并不能解决问题，因为对所有文件夹进行 777 操作并不安全，尤其是考虑到我们使用了完整 ACL。
更新 2007 有效，000 失败 - 似乎这里使用了公共掩码位，无论 ACL 如何，也无论用于共享访问的用户是谁。这是因为访问共享的用户不是所有者或组吗？我们不想将所有站点用户添加到一个组中，并通过 unix 掩码授予该组写入权限，因为这将允许路径遍历安全漏洞（一个站点用户将有权访问所有其他站点文件夹，因为他们是该组的成员），不是吗？我们可以有选择地应用“所有者”'700'，并将站点根目录及其子目录更改为站点用户，但这似乎很难维护，并且绕过了 ACL 和继承的使用？或者在这种情况下，007/777 是否安全，因为使用 ACL 作为另一层？
更新 3检查了 open.c 的 samba 源代码，以查看 change_dir_owner_to_parent 实际在做什么。首先，它使用 getwd 获取文件夹（根据 getwd_cache 缓存），然后执行 cwd 进入该文件夹以“锁定”它，以便所有者更改不会处于竞争状态。这是我的测试似乎失败的地方。在之前的测试/更新中，我发现如果我将 xx7 授予任何内容，那么它就会起作用，并且即使我再次删除所有人掩码后它也会继续起作用。我认为这是权限检查的缓存，因此一旦缓存过期/失效，问题就会再次出现。我不确定哪个缓存变量适用于此。我发现一个无法正常工作的文件夹（有 070），并确认我无法正确创建新文件夹。然后我使用 chmod 将 074 授予该文件夹并确认这解决了问题。所以这比 777 更好，但仍然不确定为什么甚至需要这样做？我需要 chmod -R 074 * 整个共享吗？
更新 4发现另一个文件夹损坏了（有 070）——使用 CMS 用户界面确认损坏并创建了一个文件夹，确认创建文件夹的过程不起作用。然后通过 SSH 将 chmod 000 应用于父级。现在该过程成功创建了文件夹。发生了什么事？！我没有触碰过这些测试中的任何一个的 Windows ACL。
更新 5用完损坏的文件夹进行测试...拿一个 070 且不起作用的文件夹（在 CMS 中验证）然后对其进行 chmod 070（与当前具有的权限相同）现在我可以通过 CMS 在文件夹内创建项目（使用提供权限的 Windows ACL）所以如果我将损坏的文件夹 chmod 为任何内容 - 那么它就会开始工作吗？
答案1
这是因为
d-w-rwx---+ 2 AD\applicationpoolidentity group 2 Sep 8 17:28 __testFolder__
代表仅有的所有者。您看到位掩码末尾的“+”了吗？这意味着有一个 (windows) acl 控制访问。因此，如果您因为在具有 r/w 权限的 acl 中而有权访问某个文件，则所有者的位掩码不适用于您（除非您是所有者）。如果您没有明确地在 acl 中指定，则 007 有效，因为这意味着“除所有者用户和所有者组之外的任何人都可以访问该文件”。
在早期版本的 FreeNAS 中，可以使用“ls -v”探索 ACL。遗憾的是，这不再有效。我还没有找到现在如何从 unix 方面探索这一点。
高血压