Mac clients accessing a Windows NTFS share resetting permissions at deeper folder levels. Why

macnetwork-sharentfsserver-message-blockwindows-server-2008

Here's the setup:

  • Windows 2008 server
  • c:\share folder with the following permissions (read, read/write are not important at this point, I don't think):
    • User1
    • User2
  • c:\share\add_user3 folder with the following permissions:
    • User3 (explicitly added at this folder level)
    • User1 (inherited from c:\share)
    • User2 (inherited from c:\share)
  • Share called share for c:\share with read/write permissions for the server-local admins
  • Mixed client environment:
    • Windows XP clients
    • Windows 7 clients
    • Mac clients (OSX v10.8.4)

Windows client behavior (both XP and Windows 7):

  • User creates a file c:\share\test.txt
  • Effective permissions on that file are inherited from the folder:
    • User1
    • User2
  • User creates a file c:\share\add_user3\test.txt
  • Effective permissions on that file are inherited from the folder:
    • User1
    • User2
    • User3

Mac client behavior:

  • User creates a file c:\share\test.txt
  • Effective permissions on that file:
    • User1
    • User2
  • User creates a file c:\share\add_user3\test.txt OR User edits an existing file c:\share\add_user3\test.txt that was created on a Windows client
  • Effective permissions on that file become:
    • User1
    • User2

It's like the Mac clients are taking the NTFS permissions at the share folder level ( c:\share) and applying it directly to c:\share\add_user3\test.txt. The permissions from c:\share\add_user3 are not being honored/inherited.

The Mac client users are all local admins on the server (and therefore have full control). This is necessary from an operational standpoint as all clients (even the Mac users) need to access the server in an administrative capacity (IIS admin mostly).

I'm a Windows guy primarily, so it appears that the Macs are "wrong" but perhaps this is just differing behavior (i.e. there's no "standard" here that is being violated). Any ideas why this is happening? And, given that we want the permissions to behave like the Windows clients, any ideas on how to enforce this on the Mac side?

Follow-up answers

  • As for different editors, this was tried with XCode and also TextEdit. Same behavior in both.
  • After testing with a user who was not in local admins, it looks like the appropriate permissions were applied/retained, except for the following behavior:
    • When the user creates a file from a Windows machine, the file owner is set to the account of the user in question
    • When the user creates a file from a Mac, the file owner is set to MACHINE\Administrators

Best Answer

This is caused by something Apple calls "safe save". When a Mac saves a file on an SMB share, it actually writes the file to a hidden folder named .TemporaryItems in the root of the share, deletes the original (if it exists), then moves the file to the actual folder. Since the saved file is new, it has a new owner, with permissions that were inherited from .TemporaryItems.

The solution I'm using is simple: remove write permissions for .TemporaryItems. This seems to disable safe save.

I've read that creating com.apple.desktopservices with the "DSDontWriteNetworkStores" attribute will stop the clients from creating .TemporaryItems, but in my experience, this doesn't work on OS X 10.8 and newer.

Related Topic