I ran into this exact same issue a month ago and opened up cases with both our NetApp SE & Red Hat. Red Hat pointed me towards the following KB article: https://access.redhat.com/knowledge/solutions/36737 which goes into detail on why the issue occurs. The article points to a blog post which explains how to resolve the issue from the filer-side by enabling the "cifs.ntfs_ignore_unix_security_ops" option. This option tricks the NFS clients into thinking that all SETATTR requests worked even though they did not. Our NetApp SE on the other hand recommended that we use UNIX security permissions instead and then share the volume/qtree out via CIFS/NFS. This to me sounds like the better approach but the choice is up to you.
Cheers,
Dan
Sent from my iPad, please excuse typos.
On May 29, 2012, at 4:59 PM, "Ray Van Dolson" rvandolson@esri.com wrote:
On Tue, May 29, 2012 at 12:10:31PM -0700, Ray Van Dolson wrote:
On Tue, May 29, 2012 at 11:07:57AM -0700, Kevin Glueck wrote:
which qtree security model are you using? unix? ntfs? what's the actual permissions on the file/dir you're trying to write to? (acls?)
I've seen an error similar to this when writing over nfs to a share that using ntfs qtrees and the permissions were too restrictive to allow the user to write... I didn't do a packet trace, so not positive it's actually 100% alike, but anecdotally, it sounds alike.
Kevin
Yes, I believe it's NTFS. We shied away from using "mixed" based on reading here and in some TR documents. Perhaps we should revisit.
Will review the NTFS permissions to look for any issues. You don't happen to recall any specific bits you had to adjust? Ours are fairly permissive by default...
Thanks, Ray
I came across this blurb in TR-3490 on page 16:
"NFS is not allowed to change permissions on a file in an NTFS-style security volume."
A closer look at the packet capture I took shows the following:
Activity: Copy file from client file system (Fedora 14) to NetApp file system using cp command. NFSv3 and NTFS style security volume on target.
Results:
NFS CREATE call succeeds. NFS SETATTR fails: mode has values set - 0644 Fails with NFS3RR_ACCES Other attributes are blank or "no value" (uid, gid, size, etc.)
Second run of cp immediately after above failure:
NFS SETATTR succeeds this time: All attributes are set to "no value" (mode, uid, gid, size, etc.) -- in other words, we don't attempt to change permissions. NFS3_OK returned.
I'm theorizing that because we're using the NTFS security model and Unix permissions are really only handled internally on the NetApp (not reflected via GETATTR requests[1]) and per the TR mentioned above can't even be manipulated that this is why I get the access denied error when copying a file to the NetApp from an NFS client. It sees permissions are different and tries to update them which fails. This failure prevents NFS WRITE from occurring and so we end up with a size 0 file.
Subsequent cp requets work fine because no SETATTR with populated ownership values are requested (though I'm not quite sure why this is -- perhaps because the file already exists my NFS client doesn't feel the need).
I've tried the following to test my theory:
chmod 777 <src> cp --no-preserve=all <src> <dst> This failed, presumably because of umask settings. Empty file created.
chmod 777 <src> umask 0000 cp --no-preserve=all <src> <dst> This succeeds. cp <src> <dst> This also succeeds
chmod 644 <src> umask 0000 cp --no-preserve=all <src> <dst> This fails (empty file created). cp <src> <dst> This fails (empty file created).
So unless I can change my NFS client's default behavior (which seems to be to attempt to set permission bits to match regardless of the flags I pass to cp -- Linux NFS client bug?), modify the umask on all NFS clients (impractical) or switch to a mixed mode model, I don't see how I can correct this.
It would be interesting if ONTAP could just "absorb" the SETATTR requests and return NFS3_OK regardless. Perhaps this could cause other issues however.
Ray
[1] "Because some NFS clients actually use the display permissions to prescreen certain kinds of file access, the returned display permissions show the maximum access allowed to any user in the ACL. This often results in a displayed UNIX permission that appears to be granting read, write, and execute access to all. However, this representation is for display purposes only. Regardless of the display permissions, file access is still granted based on the ACL." -TR-3490 p10
On Tue, May 29, 2012 at 10:52:46AM -0700, Ray Van Dolson wrote: | IBM N6240 running ONTAP 8.0.2P3. Have a number of NFS shares set up | with pretty straightforward permissions: | | /vol/napc2_p2_Data6 -sec=sys,rw,nosuid | | Filer is connected both to NIS and AD and most shares are shared out | via both NFS and CIFS. | | When attempting to copy file content to the share above (all shares | really, but using this one as an example), I get a Permission denied | error (packet capture shows this to be an NFS3ERR_ACCES message). The | file itself is successfully created, but is size zero. | | Once the file is created (with error message) I can then run the exact | same copy command again and this time the data is populated. | | Packet capture seems to show the CREATE call succeeding, while the | subsequent SETATTR call failing with the aforementioned error. | | Anyone run into something like this before? | | NFS client(s) in this case are Linux (RHEL, Fedora). NFSv3 is in use | with NFSv4 explicitly disabled. | | Ray
Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters