Mailing List Archive: Netapp: toasters

Getting NFS3ERR_ACCES for NFS Share

Index | Next | Previous | View Threaded

rvandolson at esri

May 29, 2012, 10:52 AM

Post #1 of 17 (1903 views)
Permalink

Getting NFS3ERR_ACCES for NFS Share

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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

kglueck at viz

May 29, 2012, 11:07 AM

Post #2 of 17 (1832 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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

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 [at] teaparty
| http://www.teaparty.net/mailman/listinfo/toasters

--
Kevin Glueck Department of Visualization
Senior Systems Administrator Texas A&M University
kglueck [at] viz http://www.viz.tamu.edu/
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

rvandolson at esri

May 29, 2012, 12:10 PM

Post #3 of 17 (1835 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

kglueck at viz

May 29, 2012, 12:18 PM

Post #4 of 17 (1840 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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

Watch whatever your "nobody" user is doing wrt the cifs side of things
and all. We don't run cifs shares much, nor use ntfs qtrees at all, so
in my case it was an accidental setup of a volume. I'd also recommend
steering clear of "mixed" qtrees if at all possible...

--
Kevin Glueck Department of Visualization
Senior Systems Administrator Texas A&M University
kglueck [at] viz http://www.viz.tamu.edu/
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

k_f_o at yahoo

May 29, 2012, 12:30 PM

Post #5 of 17 (1832 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] esri>
To: toasters [at] teaparty
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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

scl at virginia

May 29, 2012, 12:42 PM

Post #6 of 17 (1830 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

> 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 you are using NFS with a NTFS volume/qtree then are you
mapping your Unix uids to Windows SIDs with /etc/usermap.cfg?

The NFS client includes the Unix uid of the user in each NFS
request. The filer converts the Unix uid to the corresponding
Windows domain user using /etc/usermap.cfg and then looks at the
NTFS permissions to determine the user's access.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

rvandolson at esri

May 29, 2012, 1:03 PM

Post #7 of 17 (1833 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

On Tue, May 29, 2012 at 12:42:55PM -0700, Steve Losen 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 you are using NFS with a NTFS volume/qtree then are you
> mapping your Unix uids to Windows SIDs with /etc/usermap.cfg?
>
> The NFS client includes the Unix uid of the user in each NFS
> request. The filer converts the Unix uid to the corresponding
> Windows domain user using /etc/usermap.cfg and then looks at the
> NTFS permissions to determine the user's access.

Not explicitly. My assumption was that our use of NIS covered us here
and we'd only use usermap.cfg for overrides.

This *seems* to be holding true FWIW.

Thanks,
Ray
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Gerald.Justice at nrc-cnrc

May 29, 2012, 1:22 PM

Post #8 of 17 (1833 views)
Permalink

RE: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] teaparty [mailto:toasters-bounces [at] teaparty] On Behalf Of Kyle Oliver
Sent: Tuesday, May 29, 2012 12:31 PM
To: Ray Van Dolson; toasters [at] teaparty
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 [at] esri<mailto:rvandolson [at] esri>>
To: toasters [at] teaparty<mailto:toasters [at] teaparty>
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 [at] teaparty<mailto:Toasters [at] teaparty>
http://www.teaparty.net/mailman/listinfo/toasters

scl at virginia

May 29, 2012, 1:38 PM

Post #9 of 17 (1833 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

> On Tue, May 29, 2012 at 12:42:55PM -0700, Steve Losen 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 you are using NFS with a NTFS volume/qtree then are you
> > mapping your Unix uids to Windows SIDs with /etc/usermap.cfg?
> >
> > The NFS client includes the Unix uid of the user in each NFS
> > request. The filer converts the Unix uid to the corresponding
> > Windows domain user using /etc/usermap.cfg and then looks at the
> > NTFS permissions to determine the user's access.
>
> Not explicitly. My assumption was that our use of NIS covered us here
> and we'd only use usermap.cfg for overrides.
>
> This *seems* to be holding true FWIW.
>
> Thanks,
> Ray
>

OK Ray, I assume you have a usermap.cfg entry similar to this, right?

domain\* == *

(Perhaps this is a default rule, not sure)

This only works if the domain usernames are the same as the
corresponding Unix loginids. Otherwise if Windows user "FredSmith"
has Unix loginid "fws" then you would need this:

domain\FredSmith == fws

And are all of your NFS clients using the same NIS map as the filer?
NFS requests include the Unix UID of the user on the NFS client.
The filer uses NIS to look up the UID to obtain the Unix loginid.
Then it uses /etc/usermap.cfg to convert the loginid to a Windows
domain username and then looks up the username on the Windows domain
controller.

Steve Losen scl [at] virginia phone: 434-924-0640

University of Virginia ITC Unix Support

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

k_f_o at yahoo

May 29, 2012, 1:44 PM

Post #10 of 17 (1833 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] nrc-cnrc>
To: "toasters [at] teaparty" <toasters [at] teaparty>
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 [at] teaparty [mailto:toasters-bounces [at] teaparty] On Behalf Of Kyle Oliver
Sent: Tuesday, May 29, 2012 12:31 PM
To: Ray Van Dolson; toasters [at] teaparty
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 [at] esri>
To: toasters [at] teaparty
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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Gerald.Justice at nrc-cnrc

May 29, 2012, 1:50 PM

Post #11 of 17 (1843 views)
Permalink

RE: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] yahoo]
Sent: Tuesday, May 29, 2012 1:44 PM
To: Justice, Gerald; toasters [at] teaparty
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 [at] nrc-cnrc<mailto:Gerald.Justice [at] nrc-cnrc>>
To: "toasters [at] teaparty<mailto:toasters [at] teaparty>" <toasters [at] teaparty<mailto:toasters [at] teaparty>>
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 [at] teaparty<mailto:toasters-bounces [at] teaparty> [mailto:toasters-bounces [at] teaparty]<mailto:[mailto:toasters-bounces [at] teaparty]> On Behalf Of Kyle Oliver
Sent: Tuesday, May 29, 2012 12:31 PM
To: Ray Van Dolson; toasters [at] teaparty<mailto:toasters [at] teaparty>
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 [at] esri<mailto:rvandolson [at] esri>>
To: toasters [at] teaparty<mailto:toasters [at] teaparty>
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 [at] teaparty<mailto:Toasters [at] teaparty>
http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty<mailto:Toasters [at] teaparty>
http://www.teaparty.net/mailman/listinfo/toasters

rvandolson at esri

May 29, 2012, 2:21 PM

Post #12 of 17 (1833 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

On Tue, May 29, 2012 at 01:38:57PM -0700, Steve Losen wrote:
>
> > On Tue, May 29, 2012 at 12:42:55PM -0700, Steve Losen 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 you are using NFS with a NTFS volume/qtree then are you
> > > mapping your Unix uids to Windows SIDs with /etc/usermap.cfg?
> > >
> > > The NFS client includes the Unix uid of the user in each NFS
> > > request. The filer converts the Unix uid to the corresponding
> > > Windows domain user using /etc/usermap.cfg and then looks at the
> > > NTFS permissions to determine the user's access.
> >
> > Not explicitly. My assumption was that our use of NIS covered us here
> > and we'd only use usermap.cfg for overrides.
> >
> > This *seems* to be holding true FWIW.
> >
> > Thanks,
> > Ray
> >
>
> OK Ray, I assume you have a usermap.cfg entry similar to this, right?
>
> domain\* == *
>
> (Perhaps this is a default rule, not sure)
>
> This only works if the domain usernames are the same as the
> corresponding Unix loginids. Otherwise if Windows user "FredSmith"
> has Unix loginid "fws" then you would need this:
>
> domain\FredSmith == fws
>
> And are all of your NFS clients using the same NIS map as the filer?
> NFS requests include the Unix UID of the user on the NFS client.
> The filer uses NIS to look up the UID to obtain the Unix loginid.
> Then it uses /etc/usermap.cfg to convert the loginid to a Windows
> domain username and then looks up the username on the Windows domain
> controller.

Hi Steve...

The usermap.cfg file is actually just at defaults right now. All
comments and nothing explicitly set. So perhaps DOMAIN\* == * is
indeed a default?

All of our NFS clients are using the same NIS mapping and usernames in
NIS are the same as in Active Directory.

Ray
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

rvandolson at esri

May 29, 2012, 2:47 PM

Post #13 of 17 (1848 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

dburklan at NMDP

May 29, 2012, 9:29 PM

Post #14 of 17 (1839 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

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 [at] esri> 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 [at] teaparty
> http://www.teaparty.net/mailman/listinfo/toasters

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

pascal.dukers at asml

May 29, 2012, 10:42 PM

Post #15 of 17 (1837 views)
Permalink

RE: Getting NFS3ERR_ACCES for NFS Share [In reply to]

Anyone tried setting the hidden option "cifs.ntfs_ignore_unix_security_ops" to "ON" yet? See also https://kb.netapp.com/support/index?page=content&id=3011859

I have needed this option a few times in the past to surpress NFS client errors while working on NTFS qtrees.

--
With kind regards,

Pascal Dukers
ASML IT ARC Infra & Enterprise Architecture
Phone +31(0)402684341

>-----Original Message-----
>From: toasters-bounces [at] teaparty [mailto:toasters-
>bounces [at] teaparty] On Behalf Of Ray Van Dolson
>Sent: Tuesday, May 29, 2012 11:47 PM
>To: toasters [at] teaparty
>Subject: Re: Getting NFS3ERR_ACCES for NFS Share
>
>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 [at] teaparty
>http://www.teaparty.net/mailman/listinfo/toasters

--
The information contained in this communication and any attachments is confidential and may be privileged, and is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. Unless explicitly stated otherwise in the body of this communication or the attachment thereto (if any), the information is provided on an AS-IS basis without any express or implied warranties or liabilities. To the extent you are relying on this information, you are doing so at your own risk. If you are not the intended recipient, please notify the sender immediately by replying to this message and destroy all copies of this message and any attachments. ASML is neither liable for the proper and complete transmission of the information contained in this communication, nor for any delay in its receipt.

_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

james_ at catbus

May 30, 2012, 6:14 AM

Post #16 of 17 (1815 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

On 30 May 2012, at 06:42, Pascal Dukers wrote:

> Anyone tried setting the hidden option "cifs.ntfs_ignore_unix_security_ops" to "ON" yet? See also https://kb.netapp.com/support/index?page=content&id=3011859
>
> I have needed this option a few times in the past to surpress NFS client errors while working on NTFS qtrees.

We have this set on our filers....

See the post on this list " Subject: strange behaviour, Linux and NFS on NTFS qtree, Date: 11 June 2008 14:56:10 GMT+01:00"

I would not use mixed ever myself, the first question I would ask of anyone considering it is how would you support that data on non netapp filer ( without loosing the access meta data ), do you really want to tie yourself to a single vendor ?

Additionally users get confused by why their carefully crafted acls disappear when the file is edited in unix
_______________________________________________
Toasters mailing list
Toasters [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

rvandolson at esri

May 30, 2012, 3:23 PM

Post #17 of 17 (1821 views)
Permalink

Re: Getting NFS3ERR_ACCES for NFS Share [In reply to]

On Tue, May 29, 2012 at 02:47:03PM -0700, Ray Van Dolson 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

Thanks, all for the suggestions and replies.

Setting "cifs.ntfs_ignore_unix_security_ops on" resolves my issue. I
did consider mixed mode again, but didn't feel it would be a good fit
for our environment at this time.

Thanks again,
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 [at] teaparty
http://www.teaparty.net/mailman/listinfo/toasters

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads