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-mu... < 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< http://www.teaparty.net/mailman/listinfo/toasters%3E 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