mlmslex
asked on
Mac OS X Mavericks causing problems with Windows 2012 R2 server shares
Have new Microsoft Server 2012 network with about 45 pre-existing Mac OS X Mavericks machines.
Macs are connecting via SMB 1 (we had to turn off SMB 2 on the Windows servers)
Macs are NOT bound to Active Directory
"Employees" group has Full Control access to network share "Projects" - propagated from the top level down through inheritance. Domain "administrators" group has ownership of all files / folders in the share.
When a Mac user edits/renames a file, then saves it, the following happens:
The file "thinks" it's still inheriting, yet permissions change to: user logged in from Mac gets "full control", "users" gets read-only ("users" wasn't even in the previous permissions list), "administrators" maintain full control.
Ownership of the file is changed to the user name logged in from the Mac.
Other users (obviously) are unable to make changes to the file.
We can "repair" the permissions but the very next edit breaks them again.
We've thought of just removing "Full Control" from the "Employees" group (we know it's bad practice anyway but have allowed lately in other environments due to some apps not working right without full control)
Macs are connecting via SMB 1 (we had to turn off SMB 2 on the Windows servers)
Macs are NOT bound to Active Directory
"Employees" group has Full Control access to network share "Projects" - propagated from the top level down through inheritance. Domain "administrators" group has ownership of all files / folders in the share.
When a Mac user edits/renames a file, then saves it, the following happens:
The file "thinks" it's still inheriting, yet permissions change to: user logged in from Mac gets "full control", "users" gets read-only ("users" wasn't even in the previous permissions list), "administrators" maintain full control.
Ownership of the file is changed to the user name logged in from the Mac.
Other users (obviously) are unable to make changes to the file.
We can "repair" the permissions but the very next edit breaks them again.
We've thought of just removing "Full Control" from the "Employees" group (we know it's bad practice anyway but have allowed lately in other environments due to some apps not working right without full control)
ASKER
Thanks, nappy_d. We've removed "Full Control" from the file permissions and changed the share permissions to "Change" from Full Control.
We'll see in the next couple of days whether these changes resolve the problem while still allowing them to work.
We'll see in the next couple of days whether these changes resolve the problem while still allowing them to work.
ASKER
OK - so changed file/share permissions so that these AD Users do not have rights to change permissions / ownership.
From a Windows box, these restrictions are obeyed.
From a Mac running OS X 10.9.2, connected via SMB or CIFS, it makes NO difference. Creating/modifying a file gives ownership to that AD user (logged in from the Mac).
A TEMP fix for this has been to add the Employees group to the domain ADMINISTRATORS group - allows folks to work but is obviously and unsafe fix.
From a Windows box, these restrictions are obeyed.
From a Mac running OS X 10.9.2, connected via SMB or CIFS, it makes NO difference. Creating/modifying a file gives ownership to that AD user (logged in from the Mac).
A TEMP fix for this has been to add the Employees group to the domain ADMINISTRATORS group - allows folks to work but is obviously and unsafe fix.
Can you post a screenshot of what your permissions on a directory looks like?
ASKER
I've uploaded 3 screen shots...BEFORE (Parent folder and file rights), AFTER (file rights).
As you can see, "Administrators" remains able to read/modify docs so temporarily (so they can work), I've added the entire CSIEmployees group to the Administrators group (I haven't TOLD them that)...this obviously is not a long term solution.
I've tried tools that prevent the Mac from adding the .DS_Store files - No Difference
I've turned OFF SMB1 and re-enabled SMB2/3 - No Difference
ParentFolder-BeforeAccess.JPG
FileRights-BeforeAccess.JPG
FileRights-AfterAccess.JPG
As you can see, "Administrators" remains able to read/modify docs so temporarily (so they can work), I've added the entire CSIEmployees group to the Administrators group (I haven't TOLD them that)...this obviously is not a long term solution.
I've tried tools that prevent the Mac from adding the .DS_Store files - No Difference
I've turned OFF SMB1 and re-enabled SMB2/3 - No Difference
ParentFolder-BeforeAccess.JPG
FileRights-BeforeAccess.JPG
FileRights-AfterAccess.JPG
The .DS_store files is a different issue but I will help you fix that one after.
Let's do this:
- create new share
- on the Share permissions tab give everyone full control(See Pic1)
- Now use the NTFS tab to set the permission(See Pic2)
- Do not make any of your test users have access to full control permissions on the test share, they should only have modify.
- Test and let me know if the same issue occurs
Let's do this:
- create new share
- on the Share permissions tab give everyone full control(See Pic1)
- Now use the NTFS tab to set the permission(See Pic2)
- Do not make any of your test users have access to full control permissions on the test share, they should only have modify.
- Test and let me know if the same issue occurs
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
This was tremendously frustrating and took a great deal of research to answer, specifically because our scenario was a "perfect storm" of circumstances...we could only find a few others out there with similar problems and even fewer with workable solutions.
This issue is occurring again.. regardless of subfolder permissions.. inheritance is not being preserved..
As you have experienced, giving full control gives them permission to modify NTFS security.
Also, to help your Macs with respecting the security you have set, you should have your users logon with with their AD credentials.