Preface- this email is written with the --verbose option. Skip if you don't want your eyes to glaze over ;)
Played with this some more, there has to be some puzzle piece missing - this must work for other people? I am able to reproduce the users' error even after making the changes of a couple months ago (enabling option ntfs-unix-security-ops-ignore on an export policy rule). The difference is I had forgotten that the test account I was playing with was in an AD group with Full_Control permissions on the share level, while the end user just had Modify, so that's why I didn't initially see the same error as they did. I've since turned this test account into a normal unprivileged user.
The production volume that this data lives on is an NTFS security style volume with Everyone:Full_Control NTFS permissions at the root of the volume, inheritance enabled recursively. Yeah I know that sucks. The volume is available via CIFS, and the CIFS permissions have an AD group for R/W, one for R/O, and one for Full_Control (IT admins).
I have verified that the rule in the export policy being applied to this production volume has the ntfs-security-ops-ignore option set to true, the rorule is krb5,ntlm, the rwrule is krb5,ntlm, the superuser rule is krb5,ntlm, protocol is cifs, and clientmatch is 10.0.0.0/8.
As my unprivileged test user connected to this production share on an OS X 10.11 laptop: - Created a test directory, it inherited the Everyone:Full_Control NTFS perms - Copied a zip file to the test directory, it inherits the Everyone:Full_Control NTFS perms - Double clicked the zip file to uncompress using the built in Finder Archive Utility, results in "Error 13 - Permission denied" - Unzipping the same file from Terminal.app succeeds but after every file there is an error "chmod (file attributes) error: Permission denied".
I cloned the underlying volume and created a share on top of the clone. This cloned volume/share has the same NTFS level and CIFS level permissions as the production volume/share. As an admin user on a Windows machine, I connected to this cloned share and navigated to a directory a couple levels up from the one that contained my test directory. I then: - Properties > Security and observed Everyone:Full_Control - Clicked Advanced - Ticked the "Replace all child object permissions with inheritable permission entries from this object" box - Clicked "Disable inheritance", selected "Convert inherited permissions into explicit permissions on this object" - Add > Select a principal > MyFullControlAdminGroup > [X] Full Control under Basic Permissions, OK - Add > Select a principal > MyReadWriteGroup > [X] Modify under Basic Permissions, OK - Add > Select a principal > MyReadOnlyGroup > (no additional Basic Permissions), OK - Everyone > Remove - Apply > Yes - OK > OK
Now this directory and below should have NTFS permissions similar to the CIFS permissions.
Again as my unprivileged test user, I connected to the cloned share on an OS X 10.11 laptop: - Navigated to the directory containing the zip file I am using to test (which has inherited the permissions set above) - Double clicked the zip file to uncompress using the built in Finder Archive Utility, results in "Error 13 - Permission denied" - Created a test directory, was successful. - Examined this test directory from a Windows machine, the NTFS permissions are correct (inherited from parent as defined above) - Unzipping the same file from Terminal.app succeeds but after every file there is an error "chmod (file attributes) error: Permission denied".
And now as a user in the MyFullControlAdminGroup on the OS X 10.11 laptop: - Connected to the cloned share - Navigated to the directory containing the zip file I am using to test (which has inherited the permissions set above) - Double clicked the zip file to uncompress using the built in Finder Archive Utility. It uncompressed successfully! HOWEVER the NTFS permissions on the directory containing the uncompressed files and the files themselves get weird/bad and on the OS X machine, Finder is unable to get into the directory at all. The permissions of the directory when viewed from a Windows machine: - MyFullControlAdminGroup: Full Control - MyReadWriteGroup: Modify - MyReadOnlyGroup: Read - MyUserInTheMyFullControlAdminGroup: Special>Write <-- new permission, wha?? - Unresolved SID S-1-5-88-3-448: DENY <-- new permission, wha??
What is the Mac trying to do by adding those two new permissions, now that it has a user logged in that has Full_Control at both the NTFS and share level, and why is one of them a blanket deny?
Doing a web search for that SID digs up https://discussions.apple.com/thread/3679272 but no resolution found.
So... ideas? Anyone have access to NetApp internal KB articles and can do a quick search for that SID? I'm stumped for now.
Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com
________________________________________ From: tmac tmacmd@gmail.com Sent: Thursday, May 31, 2018 12:26 PM To: Ehrenwald, Ian Cc: Borzenkov, Andrei; Toasters Subject: Re: Mac OS X, SMB NTFS, and chmod/chown
Any chance this might be becuase 1. the client system has not been rebooted since making the change on the NetApp storage 2. the client has not unmount/unmapped and then remounted/remapped the drive since the change?
Is it possible the client/server is still caching the old value and maybe a reboot might make a difference?
--tmac
Tim McCarthy, Principal Consultant This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.