Based on the TOC, that TR is for WIndows/AD only not a mixed environment with NFS + CIFS so that TR does not apply to my situation. My apologies if I misread the original post as being a mixed environment.
But if you have a mixed environment, mixed mode qtrees work and solve problems.
Gerald Justice
From: Kyle Oliver [mailto:k_f_o@yahoo.com]
Sent: Tuesday, May 29, 2012 1:44 PM
To: Justice, Gerald; toasters@teaparty.net
Subject: Re: Getting NFS3ERR_ACCES for NFS Share
To quote NetApp themselves (from http://media.netapp.com/documents/tr-3771.pdf)
"NetApp recommends that you limit or restrict the use of mixed security style qtrees,
volumes, and FlexVol volumes. Very few situations require the mixed security style, and use of this style
can cause additional administrative overhead in dealing with the management of two sets of permissions
styles in one qtree."
-Kyle
From: "Justice, Gerald" <Gerald.Justice@nrc-cnrc.gc.ca>
To: "toasters@teaparty.net" <toasters@teaparty.net>
Sent: Tuesday, May 29, 2012 4:22 PM
Subject: RE: Getting NFS3ERR_ACCES for NFS Share
I’m not sure where this “don’t use mixed” is coming from. We use it here without problems.
We have both NFS exports to Linux boxes and CIFS shares to Macs and Windows systems.
All our qtrees are mixed mode except for a couple that are only accessed via NFS.
We have AD and NIS authentications and use usermap.cfg only where AD and NIS don’t map automatically, but we make the effort to make them map automatically (by making them the same string) so we have only one entry in usermap.cfg for root/Administrator.
We do NOT have user problems with this setup. Users who do not switch between NFS and CIFS never have problems. It also works as expected for people that switch back and forth from an NFS to a CIFS client. Those few problems we have had always had to do with non-sensical/bizarre permissions.
So, as far as I’m concerned the advice to avoid mixed qtrees is obsolete, perhaps from issues with the earliest versions of ontap? It works fine here!
We are running 7.3.6.
Thanks,
Gerald Justice
Network/Unix Systems Manager
Shared Services Canada
c/o Dominion Astrophysical Observatory
5071 W. Saanich Rd
Victoria, BC
CANADA V9E 2E7
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Kyle Oliver
Sent: Tuesday, May 29, 2012 12:31 PM
To: Ray Van Dolson; toasters@teaparty.net
Subject: Re: Getting NFS3ERR_ACCES for NFS Share
You don't want to use mixed, probably for all the reasons you already read.... Stick with NTFS or UNIX.
-Kyle
From: Ray Van Dolson <rvandolson@esri.com>
To: toasters@teaparty.net
Sent: Tuesday, May 29, 2012 3:10 PM
Subject: Re: Getting NFS3ERR_ACCES for NFS Share
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
>
> 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
_______________________________________________
Toasters mailing list
Toasters@teaparty.net
http://www.teaparty.net/mailman/listinfo/toasters