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
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@teaparty.net | http://www.teaparty.net/mailman/listinfo/toasters
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
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...
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
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.commailto:rvandolson@esri.com> To: toasters@teaparty.netmailto: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.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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
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.camailto:Gerald.Justice@nrc-cnrc.gc.ca> To: "toasters@teaparty.netmailto:toasters@teaparty.net" <toasters@teaparty.netmailto: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.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net]mailto:[mailto:toasters-bounces@teaparty.net] On Behalf Of Kyle Oliver Sent: Tuesday, May 29, 2012 12:31 PM To: Ray Van Dolson; toasters@teaparty.netmailto: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.commailto:rvandolson@esri.com> To: toasters@teaparty.netmailto: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.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
_______________________________________________ Toasters mailing list Toasters@teaparty.netmailto:Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
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
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@virginia.edu phone: 434-924-0640
University of Virginia ITC Unix Support
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
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
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
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@teaparty.net [mailto:toasters- bounces@teaparty.net] On Behalf Of Ray Van Dolson Sent: Tuesday, May 29, 2012 11:47 PM To: toasters@teaparty.net 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@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
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
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
-
Dan Burkland -
James Beal -
Justice, Gerald -
Kevin Glueck -
Kyle Oliver -
Pascal Dukers -
Ray Van Dolson -
Steve Losen