How to set permissions from NTFS-style qtree mounted via NFS

[bsnyder27]

In our recent transition from 7-mode to CDOT, we uncovered an issue that affected us in the past covered in KB3011858.  Problem is, the KB doesn't note the workaround for CDOT.

I'll share the command and you can determine the level to apply it if I've described it correctly.

Two things to note first:

1. The mount should be NFSv3 if mounted at the qtree level as qtree exports are available for NFSv3 exports only.
2. If you're accessing data under a qtree using NFSv4 mounted at the volume level, then this issue doesn't apply

The specific symptoms we saw were:

• "operation no permitted" when trying to copy or move a file from local unix filesystem to NTFS qtree mounted NFS.  It would copy the filename and the file would be 0 bytes at the destination
• editing a file on NTFS qtree mounted NFS resulted in "Found a swap file by the name xxxx.xxx....." and files .xxxx.xxx.swo and xxxx.xxx.swp were created as a result

Appears there are two approaches in CDOT

1. set 'ntfs-unix-security-ops' field to 'ignore' for the entire vserver (default is 'use_export_policy')
   
   vserver nfs modify -vserver <vserver> -ntfs-unix-security-ops ignore
   
   
2. Keep the vserver setting default and change the same field for a specific export-policy rule
   
   export-policy rule show -vserver <vserver> -policyname <policy> -ruleindex <index #> -ntfs-unix-security-ops ignore

Description of this setting from OnTap command reference.  Note that it must be set w/ privilege advanced:

[-ntfs-unix-security-ops {ignore|fail}] - NTFS Unix Security Options (privilege: advanced)

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.

[parisi]

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.

[bsnyder27]

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?

[parisi]

No real disadvantage I can think of, unless you want to ensure people know their attempt to modify permissions failed. Otherwise, it's a silent failure.

[BillFleury]

Thank you bsnyder, this saved me alot of work.