"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