Mailing List Archive

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-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/toasters
RE: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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-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/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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-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/toasters
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> http://www.teaparty.net/mailman/listinfo/toasters
>
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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-multiprotocol-nas<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/toasters<http://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.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
Interesting. I'll ask the artist I've been working with to try Stuffit instead of the built-in unarchiver utility and I'll let you all know what happens. Thanks for the idea.


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


________________________________________
From: Mike Gossett <cmgossett@gmail.com>
Sent: Wednesday, May 9, 2018 7:01:44 PM
To: Ehrenwald, Ian
Cc: Basil; toasters@teaparty.net
Subject: Re: Mac OS X, SMB NTFS, and chmod/chown

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<http://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.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
RE: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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/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-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/toasters

_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
>>>>> "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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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/imprint<http://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-multiprotocol-nas<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/toasters<http://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.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
Hi John
Absolutely, will share how it goes. Our autosupports are generally pretty clean and upgrade advisor doesn't point out anything I'm too concerned about, so I'm not anticipating anything exciting. Famous last words ;)


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


________________________________________
From: John Stoffel <john@stoffel.org>
Sent: Saturday, May 12, 2018 12:45 PM
To: Ehrenwald, Ian
Cc: Basil; toasters@teaparty.net
Subject: Re: Mac OS X, SMB NTFS, and chmod/chown

>>>>> "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

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
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
>>>>> "Ian" == Ian Ehrenwald <Ian.Ehrenwald@hbgusa.com> writes:

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

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

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

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

So what will happen if you need to over-write those files from the
Unix side? We recently ran into a problem where we have a process in
place for end users to upload/download files from a share to be
processed by an SAP tool. The users are windows, the SAP is Unix, and
god help you when someone on the windows side screws up the
permissions (somehow) and it all stops writing.

To me, it sounds like *this* flag might be a way to make sure problems
don't happen, but I'd almost be happier if I could make it so that the
Windows people can't screw things up.

It's too early on a Sunday morning for me to remember the full details
though. But sharing files back and forth is still not perfect.

John
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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/imprint<http://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-multiprotocol-nas<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/toasters<http://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.


_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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*

*Proud Member of the #NetAppATeam <https://twitter.com/NetAppATeam>*

*I Blog at TMACsRack <https://tmacsrack.wordpress.com/>*



On Thu, May 31, 2018 at 12:03 PM Ehrenwald, Ian <Ian.Ehrenwald@hbgusa.com>
wrote:

> 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/imprint
> <http://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-multiprotocol-nas
> <
> 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/toasters<
> http://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.
>
>
> _______________________________________________
> Toasters mailing list
> Toasters@teaparty.net
> http://www.teaparty.net/mailman/listinfo/toasters
>
Re: Mac OS X, SMB NTFS, and chmod/chown [ In reply to ]
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.


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