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
  • 4
    What editor is being used on the Mac clients? Some programs do silly things like storing the new version as a temp file in a different folder, then deleting the original and moving the formerly-temp file into its place; this can result in the new file inheriting permissions from the temp location, not its "real" location. Also, can you test with a Mac client that isn't a server admin, and at least find out if that's part of the problem? Sep 4, 2013 at 16:37
  • @GordonDavisson, thanks for the response. First question answered in an edit above. I'll get back to you on the second question. Sep 4, 2013 at 19:09
  • @GordonDavisson, second question answered above Sep 4, 2013 at 19:43
  • I tried this on Mavericks and the problem still exists. I also tried Thursby Software's DAVE, which is an SMB replacement for OS X, and it still has the same problem!
    – Jason
    Oct 10, 2013 at 22:14

1 Answer 1


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.