Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
share|improve this question
3  
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? –  Gordon Davisson Sep 4 '13 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. –  Chris Simmons Sep 4 '13 at 19:09
    
@GordonDavisson, second question answered above –  Chris Simmons Sep 4 '13 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 '13 at 22:14
add comment

2 Answers

I have this exact same problem and I've figured out a couple of (ugly) workarounds.

1) Whenever a Mac user needs to modify a file, save it with a new file name (e.g. add a number to the end), and then delete the original.

or

2) Create shares for every folder with non-inherited permissions. Then on the Mac, connect to those shares instead of their parent. Using your example, if you need to modify c:\share\add_user3\test.txt, instead of connecting to smb://server/share, connect to smb://server/add_user3.

I really hope there's a better solution out there...

share|improve this answer
add comment

When a Mac saves a file on an SMB share, it actually writes the file to the root in a hidden folder named .TemporaryItems, then moves the file to the actual folder and overwrites the previous version. Since the saved file is new, it has a new owner, with permissions that were inherited from .TemporaryItems (which was inherited from the root).

The solution I'm using is simple: remove write permissions for .TemporaryItems.

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 Mountain Lion.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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