访问Windows NTFS共享的Mac客户端在更深的文件夹级别重置权限。 为什么?

这是设置:

  • Windows 2008服务器
  • c:\share文件夹具有以下权限(读取,读/写在这一点上并不重要,我不认为):
    • 用户1
    • 用户2
  • c:\share\add_user3文件夹具有以下权限:
    • User3(显式添加在此文件夹级别)
    • User1(从c:\shareinheritance)
    • User2(从c:\shareinheritance)
  • 为服务器本地pipe理员c:\share具有读/写权限的c:\share
  • 混合客户端环境:
    • Windows XP客户端
    • Windows 7客户端
    • Mac客户端(OSX v10.8.4)

Windows客户端行为(XP和Windows 7):

  • 用户创build一个文件c:\share\test.txt
  • 该文件的有效权限从该文件夹inheritance:
    • 用户1
    • 用户2
  • 用户创build一个文件c:\share\add_user3\test.txt
  • 该文件的有效权限从该文件夹inheritance:
    • 用户1
    • 用户2
    • 用户3

Mac客户端行为:

  • 用户创build一个文件c:\share\test.txt
  • 该文件的有效权限:
    • 用户1
    • 用户2
  • 用户创build文件c:\share\add_user3\test.txt或用户编辑在Windows客户端上创build的现有文件c:\share\add_user3\test.txt
  • 该文件的有效权限变为:
    • 用户1
    • 用户2

这就像Mac客户端在共享文件夹级别( c:\share )获取NTFS权限并直接将其应用于c:\share\add_user3\test.txt 。 来自c:\share\add_user3的权限c:\share\add_user3 /inheritance。

Mac客户端用户都是服务器上的本地pipe理员(因此具有完全控制权)。 从操作angular度来看,这是必要的,因为所有的客户端(甚至Mac用户)都需要以pipe理能力访问服务器(主要是IISpipe理员)。

我主要是一个Windows的家伙,所以看起来Mac是“错误的”,但也许这只是不同的行为(即这里没有被违反的“标准”)。 任何想法为什么发生这种情况? 而且,鉴于我们希望权限的行为像Windows客户端,有关如何在Mac端强制执行的任何想法?

后续答案

  • 至于不同的编辑器,这是用XCode和TextEdit尝试的。 两者都是相同的行为。
  • 在与不在本地pipe理员的用户进行testing之后,看起来应用/保留了适当的权限, 除了以下行为:
    • 当用户从Windows机器创build文件时,文件所有者被设置为所述用户的账户
    • 当用户从Mac创build文件时,文件所有者被设置为MACHINE\Administrators

这是由苹果公司称之为“安全保存 ”的事情引起的。 当Mac在SMB共享上保存文件时,它实际上将该文件写入到共享根目录中名为.TemporaryItems的隐藏文件夹中,删除原始文件(如果存在),然后将文件移动到实际文件夹中。 由于保存的文件是新的,它有一个新的所有者,具有从.TemporaryItemsinheritance的权限。

我使用的解决scheme很简单: 删除.TemporaryItems的写入权限 。 这似乎禁用安全保存。

我读过创buildcom.apple.desktopservices与“DSDontWriteNetworkStores”属性将停止客户端创build.TemporaryItems ,但根据我的经验,这不适用于OS X 10.8和更新。