What version of ontap?

On Wed, May 9, 2018 at 3:20 PM Parisi, Justin Justin.Parisi@netapp.com wrote:

I wouldn't change the permissions to mixed.

I'd try to track down ways to unzip without needing to modify permissions. Is there perhaps a cli flag for the unzip command?

-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Wednesday, May 9, 2018 12:28 PM To: toasters@teaparty.net Subject: Mac OS X, SMB NTFS, and chmod/chown

Hello I have users on Mac OS X that are unable to uncompress zip files in SMB shares which sit on top of NTFS security style volumes. I hadn't heard of this problem until I started migrating my users to new shares, previously they were all on UNIX security style volumes.

If I am understanding my users correctly, they can reliably reproduce this problem this way: - In Finder, right click on a folder on a share, select Compress - Zip file is created successfully on share - Double click on Zip file that was created - Mac OS X archiver utility pops up an error box, "Unable to expand (zip name) into (target dir). (Error 13 - Permission denied).

Examining the Zip file from the command line shows that it is a fully formed file, no corruption, etc. When I attempt to uncompress the Zip file using the command line on the same machine that created it, I can see that unzip is attempting to chmod the files and directories and getting a Permission Denied error back from the svm. Output:

UserMachine:z TheUser$ unzip 3:14:18.zip Archive: 3:14:18.zip creating: 3:14:18/ chmod (directory attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied creating: __MACOSX/ chmod (directory attributes) error: Permission denied creating: __MACOSX/3:14:18/ chmod (directory attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied

warning: cannot set permissions for __MACOSX/3:14:18/ Permission denied warning: set times/attribs failed for __MACOSX/3:14:18/ warning: cannot set permissions for __MACOSX/ Permission denied warning: set times/attribs failed for __MACOSX/ warning: cannot set permissions for 3:14:18/ Permission denied warning: set times/attribs failed for 3:14:18/ UserMachine:z TheUser$

This does make sense, since SMB/CIFS doesn't really understand UNIX ownership and attributes. Is the solution setting the security style of the volume to Mixed? Reading in detail about it at https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-mu... makes it seem like that's the right path to follow, but before I start down that trail I wanted to see what other people have done in this situation.

Thanks for your help.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

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.

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

We’ve seen this in other environments on other non-netapp solutions with NTFS permissions. Our solution was to have the design group use stuffit, which was at least gui based, to extract. They also were able to take the pre-press files and extract them locally before copying to the CIFS share as an alternate workaround, after setting OS X not to create the .DS_Store files on network mounts.

On May 9, 2018, at 2:31 PM, Ehrenwald, Ian Ian.Ehrenwald@hbgusa.com wrote:

8.3.2 P12 currently, with 9.1 P12 coming in a month or so. Yeah, we're on the slow/conservative code train I guess.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

---

From: Basil basilberntsen@gmail.com Sent: Wednesday, May 9, 2018 3:22 PM To: Parisi, Justin Cc: Ehrenwald, Ian; toasters@teaparty.net Subject: Re: Mac OS X, SMB NTFS, and chmod/chown

What version of ontap? 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.

---

Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters

...

...

...

...

"Ian" == Ian Ehrenwald Ian.Ehrenwald@hbgusa.com writes:

Ian> 8.3.2 P12 currently, with 9.1 P12 coming in a month or so. Yeah, Ian> we're on the slow/conservative code train I guess.

Same here... the jump to 8.3 was easy enough from 8.2, but the non-disruptive updates to 9.x tickle my fancy. Care to share your experience when you make the leap?

Thanks, John

Hey Justin These users are artists/graphic designers, I can't ask them to drop to a shell and run /usr/bin/unzip, unfortunately :)

I'll see if there's some option to set with the OS X 'defaults' command to ignore permissions when running the built in GUI zip/unzip, but I'm not very hopeful.

I'll let you all know what I find, if anything.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

________________________________________ From: Parisi, Justin Justin.Parisi@netapp.com Sent: Wednesday, May 9, 2018 3:16:37 PM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: Mac OS X, SMB NTFS, and chmod/chown

I wouldn't change the permissions to mixed.

I'd try to track down ways to unzip without needing to modify permissions. Is there perhaps a cli flag for the unzip command?

-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Wednesday, May 9, 2018 12:28 PM To: toasters@teaparty.net Subject: Mac OS X, SMB NTFS, and chmod/chown

Hello I have users on Mac OS X that are unable to uncompress zip files in SMB shares which sit on top of NTFS security style volumes. I hadn't heard of this problem until I started migrating my users to new shares, previously they were all on UNIX security style volumes.

If I am understanding my users correctly, they can reliably reproduce this problem this way: - In Finder, right click on a folder on a share, select Compress - Zip file is created successfully on share - Double click on Zip file that was created - Mac OS X archiver utility pops up an error box, "Unable to expand (zip name) into (target dir). (Error 13 - Permission denied).

Examining the Zip file from the command line shows that it is a fully formed file, no corruption, etc. When I attempt to uncompress the Zip file using the command line on the same machine that created it, I can see that unzip is attempting to chmod the files and directories and getting a Permission Denied error back from the svm. Output:

UserMachine:z TheUser$ unzip 3:14:18.zip Archive: 3:14:18.zip creating: 3:14:18/ chmod (directory attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied creating: __MACOSX/ chmod (directory attributes) error: Permission denied creating: __MACOSX/3:14:18/ chmod (directory attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied

warning: cannot set permissions for __MACOSX/3:14:18/ Permission denied warning: set times/attribs failed for __MACOSX/3:14:18/ warning: cannot set permissions for __MACOSX/ Permission denied warning: set times/attribs failed for __MACOSX/ warning: cannot set permissions for 3:14:18/ Permission denied warning: set times/attribs failed for 3:14:18/ UserMachine:z TheUser$

This does make sense, since SMB/CIFS doesn't really understand UNIX ownership and attributes. Is the solution setting the security style of the volume to Mixed? Reading in detail about it at https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-mu...https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-multiprotocol-nas makes it seem like that's the right path to follow, but before I start down that trail I wanted to see what other people have done in this situation.

Thanks for your help.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

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.

_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters 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.

Oh, I had completely forgotten about that flag and also did not know it could be applied on a per-rule basis!

I ran a test: - Created test volume with NTFS security - Put a SMB share definition on top of it - Created test export policy - Applied test policy to test volume - Copied one of the production Zip files to the test share - Mounted test share on test Mac - Attempted to uncompress prod Zip in test share on test Mac - it failed as expected - Updated rule in test policy (in advanced mode) to set ntfs-unix-security-ops-ignore to true - Re-ran the Unzip test - It succeeded - Turned ntfs-unix-security-ops-ignore back to false, attempted test again - it failed as expected

We can conclude that you are correct, enabling the ntfs-unix-security-ops-ignore option allows unzip to believe it is chown'ing and chmod'ing successfully while writing to a NTFS-style SMB share.

I will ask an end user to do some testing of their own on this volume by copying a few troublesome Zip files there and attempting to uncompress. If all goes well I will update the production export policy assigned to the production volume. I will then relay the results to this list.

Thank for the suggestions, everyone.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

________________________________________ From: andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com Sent: Thursday, May 10, 2018 2:41:49 AM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: Mac OS X, SMB NTFS, and chmod/chown

Does setting "-ntfs-unix-security-ops ignore" on export rule help?

--- Sent from my Fujitsu LIFEBOOK S937 With best regards Andrei Borzenkov Senior System Engineer FJ EMEIA PR FOCP RU SM FSO

FUJITSU Zemlyanoy val 9, 105064 Moscow, Russia Tel.: +7 (495) 730 6220 ext. 2247 Mob.: +7 (916) 678 7208 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ts.fujitsu.com Company details: OOO Fujitsu Technology Solutions / ts.fujitsu.com/imprinthttp://ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.

-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Wednesday, May 9, 2018 7:28 PM To: toasters@teaparty.net Subject: Mac OS X, SMB NTFS, and chmod/chown

Hello I have users on Mac OS X that are unable to uncompress zip files in SMB shares which sit on top of NTFS security style volumes. I hadn't heard of this problem until I started migrating my users to new shares, previously they were all on UNIX security style volumes.

If I am understanding my users correctly, they can reliably reproduce this problem this way: - In Finder, right click on a folder on a share, select Compress - Zip file is created successfully on share - Double click on Zip file that was created - Mac OS X archiver utility pops up an error box, "Unable to expand (zip name) into (target dir). (Error 13 - Permission denied).

Examining the Zip file from the command line shows that it is a fully formed file, no corruption, etc. When I attempt to uncompress the Zip file using the command line on the same machine that created it, I can see that unzip is attempting to chmod the files and directories and getting a Permission Denied error back from the svm. Output:

UserMachine:z TheUser$ unzip 3:14:18.zip Archive: 3:14:18.zip creating: 3:14:18/ chmod (directory attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied creating: __MACOSX/ chmod (directory attributes) error: Permission denied creating: __MACOSX/3:14:18/ chmod (directory attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied

warning: cannot set permissions for __MACOSX/3:14:18/ Permission denied warning: set times/attribs failed for __MACOSX/3:14:18/ warning: cannot set permissions for __MACOSX/ Permission denied warning: set times/attribs failed for __MACOSX/ warning: cannot set permissions for 3:14:18/ Permission denied warning: set times/attribs failed for 3:14:18/ UserMachine:z TheUser$

This does make sense, since SMB/CIFS doesn't really understand UNIX ownership and attributes. Is the solution setting the security style of the volume to Mixed? Reading in detail about it at https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-mu...https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-multiprotocol-nas makes it seem like that's the right path to follow, but before I start down that trail I wanted to see what other people have done in this situation.

Thanks for your help.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

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.

_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters 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.

Reporting back with not so great news. My test case on my test Mac didn't seem to have this problem after setting ntfs-unix-security-ops-ignore on the CIFS protocol rule in the policy assigned to the volume. However, the end user still is getting Permission Denied (Error 13) when uncompressing to the share from the Mac GUI. When I try from the end user machine using the command line, I can uncompress but still get a bunch of fchown() errors. Need to do some more hunting around, I guess.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

________________________________________ From: Ehrenwald, Ian Sent: Saturday, May 12, 2018 1:55:18 PM To: andrei.borzenkov@ts.fujitsu.com; toasters@teaparty.net Subject: Re: Mac OS X, SMB NTFS, and chmod/chown

Oh, I had completely forgotten about that flag and also did not know it could be applied on a per-rule basis!

I ran a test: - Created test volume with NTFS security - Put a SMB share definition on top of it - Created test export policy - Applied test policy to test volume - Copied one of the production Zip files to the test share - Mounted test share on test Mac - Attempted to uncompress prod Zip in test share on test Mac - it failed as expected - Updated rule in test policy (in advanced mode) to set ntfs-unix-security-ops-ignore to true - Re-ran the Unzip test - It succeeded - Turned ntfs-unix-security-ops-ignore back to false, attempted test again - it failed as expected

We can conclude that you are correct, enabling the ntfs-unix-security-ops-ignore option allows unzip to believe it is chown'ing and chmod'ing successfully while writing to a NTFS-style SMB share.

I will ask an end user to do some testing of their own on this volume by copying a few troublesome Zip files there and attempting to uncompress. If all goes well I will update the production export policy assigned to the production volume. I will then relay the results to this list.

Thank for the suggestions, everyone.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

________________________________________ From: andrei.borzenkov@ts.fujitsu.com andrei.borzenkov@ts.fujitsu.com Sent: Thursday, May 10, 2018 2:41:49 AM To: Ehrenwald, Ian; toasters@teaparty.net Subject: RE: Mac OS X, SMB NTFS, and chmod/chown

Does setting "-ntfs-unix-security-ops ignore" on export rule help?

--- Sent from my Fujitsu LIFEBOOK S937 With best regards Andrei Borzenkov Senior System Engineer FJ EMEIA PR FOCP RU SM FSO

FUJITSU Zemlyanoy val 9, 105064 Moscow, Russia Tel.: +7 (495) 730 6220 ext. 2247 Mob.: +7 (916) 678 7208 E-mail: Andrei.Borzenkov@ts.fujitsu.com Web: ts.fujitsu.com Company details: OOO Fujitsu Technology Solutions / ts.fujitsu.com/imprinthttp://ts.fujitsu.com/imprint This communication contains information that is confidential, proprietary in nature and/or privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) or the person responsible for delivering it to the intended recipient(s), please note that any form of dissemination, distribution or copying of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender and delete the original communication. Thank you for your cooperation. Please be advised that neither Fujitsu, its affiliates, its employees or agents accept liability for any errors, omissions or damages caused by delays of receipt or by any virus infection in this message or its attachments, or which may otherwise arise as a result of this e-mail transmission.

-----Original Message----- From: toasters-bounces@teaparty.net toasters-bounces@teaparty.net On Behalf Of Ehrenwald, Ian Sent: Wednesday, May 9, 2018 7:28 PM To: toasters@teaparty.net Subject: Mac OS X, SMB NTFS, and chmod/chown

Hello I have users on Mac OS X that are unable to uncompress zip files in SMB shares which sit on top of NTFS security style volumes. I hadn't heard of this problem until I started migrating my users to new shares, previously they were all on UNIX security style volumes.

If I am understanding my users correctly, they can reliably reproduce this problem this way: - In Finder, right click on a folder on a share, select Compress - Zip file is created successfully on share - Double click on Zip file that was created - Mac OS X archiver utility pops up an error box, "Unable to expand (zip name) into (target dir). (Error 13 - Permission denied).

Examining the Zip file from the command line shows that it is a fully formed file, no corruption, etc. When I attempt to uncompress the Zip file using the command line on the same machine that created it, I can see that unzip is attempting to chmod the files and directories and getting a Permission Denied error back from the svm. Output:

UserMachine:z TheUser$ unzip 3:14:18.zip Archive: 3:14:18.zip creating: 3:14:18/ chmod (directory attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied creating: __MACOSX/ chmod (directory attributes) error: Permission denied creating: __MACOSX/3:14:18/ chmod (directory attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.idml fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameABC.ai fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameLMN.png fchmod (file attributes) error: Permission denied inflating: 3:14:18/FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied inflating: __MACOSX/3:14:18/._FileNameXYZ.FC3.indd fchmod (file attributes) error: Permission denied

warning: cannot set permissions for __MACOSX/3:14:18/ Permission denied warning: set times/attribs failed for __MACOSX/3:14:18/ warning: cannot set permissions for __MACOSX/ Permission denied warning: set times/attribs failed for __MACOSX/ warning: cannot set permissions for 3:14:18/ Permission denied warning: set times/attribs failed for 3:14:18/ UserMachine:z TheUser$

This does make sense, since SMB/CIFS doesn't really understand UNIX ownership and attributes. Is the solution setting the security style of the volume to Mixed? Reading in detail about it at https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-mu...https://whyistheinternetbroken.wordpress.com/2017/01/24/mixed-perceptions-multiprotocol-nas makes it seem like that's the right path to follow, but before I start down that trail I wanted to see what other people have done in this situation.

Thanks for your help.

Ian Ehrenwald Senior Infrastructure Engineer Hachette Book Group, Inc. 1.617.263.1948 / ian.ehrenwald@hbgusa.com

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.

_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toastershttp://www.teaparty.net/mailman/listinfo/toasters 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.

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.