This parameter specifies whether UNIX-type permissions changes on NTFS (Windows) volumes are prohibited (fail) or allowed (ignore) when the request originates from an NFS client. The default setting is fail.
If you are accessing a NTFS security style volume from NFS, there is no way to modify permissions from NFS. Setting the ntfs-unix-security-ops to ignore simply bypasses the error; it does not allow you to change access.
The reason setting this option to ignore allows NFSv3 to function on file copies is that it ignores the SETATTR attribute that takes place during the copy.
The only way to truly modify permissions on NTFS security style volumes is from a Windows client or via vserver security file-directory apply commands.
Understood. I just wanted to note the workaround for others who might experience the same pain as I did.
The ignore actually works well for us. Doing a file copy simply inherits the ACLs of the parent directory and the owner information is accurate based off of the user mapping of the user performing the copy.
Any disadvantage or other reason to not set this option for the entire vserver versus making exceptions as-needed in individual export policy rules?