Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply 'policy1' to the root volume in the associated SVM we are able to mount 'volA' on the ESXi hosts.
Doesn't this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks
This is one of the more common issues we see when troubleshooting NFS access. The SVM root volume needs read access to the host for traverse. I would create a root policy with read any and none for read/write and none for superuser as part of your SVM creation. You could allow read to 0.0.0.0/0 for all hosts since only specific hosts will have access to volumes mounted to root, or allow specific hosts or a subnet...whatever makes sense for security. Also, if using LS mirrors for SVM root protection (I prefer using DP if there is a snapmirror license) then make sure to update the LS mirrors so clients get the updated permission.
From: Daniel Taylor Daniel_Taylor@ajg.com To: "toasters@teaparty.net" toasters@teaparty.net Sent: Wednesday, April 5, 2017 6:20 AM Subject: NFS Export Policy
<!--#yiv2244031595 _filtered #yiv2244031595 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv2244031595 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv2244031595 #yiv2244031595 p.yiv2244031595MsoNormal, #yiv2244031595 li.yiv2244031595MsoNormal, #yiv2244031595 div.yiv2244031595MsoNormal {margin:0cm;margin-bottom:.0001pt;font-size:11.0pt;font-family:"Calibri", "sans-serif";}#yiv2244031595 a:link, #yiv2244031595 span.yiv2244031595MsoHyperlink {color:blue;text-decoration:underline;}#yiv2244031595 a:visited, #yiv2244031595 span.yiv2244031595MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv2244031595 p.yiv2244031595MsoAcetate, #yiv2244031595 li.yiv2244031595MsoAcetate, #yiv2244031595 div.yiv2244031595MsoAcetate {margin:0cm;margin-bottom:.0001pt;font-size:8.0pt;font-family:"Tahoma", "sans-serif";}#yiv2244031595 span.yiv2244031595EmailStyle17 {font-family:"Calibri", "sans-serif";color:windowtext;}#yiv2244031595 span.yiv2244031595BalloonTextChar {font-family:"Tahoma", "sans-serif";}#yiv2244031595 .yiv2244031595MsoChpDefault {font-family:"Calibri", "sans-serif";} _filtered #yiv2244031595 {margin:72.0pt 72.0pt 72.0pt 72.0pt;}#yiv2244031595 div.yiv2244031595WordSection1 {}-->Hello, We have an volume with an export policy applied: volA = policy1 The policy has client match rules for the ESXi hosts. However when we try and add this volume to an ESXi host we get an error saying mount request denied. If we add a rule to the default export policy within the same SVM the volume is then added without issue. Similarly if we apply ‘policy1’ to the root volume in the associated SVM we are able to mount ‘volA’ on the ESXi hosts. Doesn’t this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug? We are running 9.1P1. Thanks _______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters
You should add a rule that allows all hosts (client match=0.0.0.0/0) ro access to the root volume and its policy. Then add the explicit host rules to the policy for the esxi volumes. The hosts need to be able to access all volumes and junctions down the entire path including the root.
Get Outlook for iOS
On Wed, Apr 5, 2017 at 6:12 AM -0400, "Daniel Taylor" Daniel_Taylor@ajg.com wrote:
Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply ‘policy1’ to the root volume in the associated SVM we are able to mount ‘volA’ on the ESXi hosts.
Doesn’t this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks
Thanks, makes sense to be able to traverse down the entire path.
New client rule added to the default policy now which is only associated with the root volume, leaving the other policy assigned to the volume to control access and surprise surprise it’s all good.
From: Tim McCarthy [mailto:tmacmd@gmail.com] Sent: 05 April 2017 11:30 To: toasters@teaparty.net; Daniel Taylor Subject: Re: NFS Export Policy
You should add a rule that allows all hosts (client match=0.0.0.0/0) ro access to the root volume and its policy.
Then add the explicit host rules to the policy for the esxi volumes.
The hosts need to be able to access all volumes and junctions down the entire path including the root.
Get Outlook for iOShttps://aka.ms/o0ukef
On Wed, Apr 5, 2017 at 6:12 AM -0400, "Daniel Taylor" <Daniel_Taylor@ajg.commailto:Daniel_Taylor@ajg.com> wrote: Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply ‘policy1’ to the root volume in the associated SVM we are able to mount ‘volA’ on the ESXi hosts.
Doesn’t this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks
Hey,
here's what I always do for new SVMs:
Add this rule to the default policy and only have this rule in it:
vserver export-policy rule create -vserver SVMNAME -policyname default -clientmatch 0/0 -rorule none -rwrule never -protocol nfs -anon 65535 -allow-suid true -superuser none -allow-dev true
Add a new policy for the volume in question:
vserver export-policy create -vserver SVMNAME -policyname POLICYNAME
Add rules for each client which should have access to this volume:
vserver export-policy rule create -vserver SVMNAME -policyname POLICYNAME -protocol nfs -rorule any -rwrule any -superuser any -anon 0 -clientmatch CLIENTIPMASK
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Daniel Taylor Gesendet: Mittwoch, 5. April 2017 12:08 An: toasters@teaparty.net Betreff: NFS Export Policy
Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply 'policy1' to the root volume in the associated SVM we are able to mount 'volA' on the ESXi hosts.
Doesn't this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks
For the record, TR-4067 covers export policies on page 27, if you're interested.
http://www.netapp.com/us/media/tr-4067.pdf
From: toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] On Behalf Of Alexander Griesser Sent: Wednesday, April 5, 2017 7:32 AM To: Daniel Taylor Daniel_Taylor@ajg.com; toasters@teaparty.net Subject: AW: NFS Export Policy
Hey,
here's what I always do for new SVMs:
Add this rule to the default policy and only have this rule in it:
vserver export-policy rule create -vserver SVMNAME -policyname default -clientmatch 0/0 -rorule none -rwrule never -protocol nfs -anon 65535 -allow-suid true -superuser none -allow-dev true
Add a new policy for the volume in question:
vserver export-policy create -vserver SVMNAME -policyname POLICYNAME
Add rules for each client which should have access to this volume:
vserver export-policy rule create -vserver SVMNAME -policyname POLICYNAME -protocol nfs -rorule any -rwrule any -superuser any -anon 0 -clientmatch CLIENTIPMASK
Best,
Alexander Griesser Head of Systems Operations
ANEXIA Internetdienstleistungs GmbH
E-Mail: AGriesser@anexia-it.commailto:AGriesser@anexia-it.com Web: http://www.anexia-it.comhttp://www.anexia-it.com/
Anschrift Hauptsitz Klagenfurt: Feldkirchnerstraße 140, 9020 Klagenfurt Geschäftsführer: Alexander Windbichler Firmenbuch: FN 289918a | Gerichtsstand: Klagenfurt | UID-Nummer: AT U63216601
Von: toasters-bounces@teaparty.netmailto:toasters-bounces@teaparty.net [mailto:toasters-bounces@teaparty.net] Im Auftrag von Daniel Taylor Gesendet: Mittwoch, 5. April 2017 12:08 An: toasters@teaparty.netmailto:toasters@teaparty.net Betreff: NFS Export Policy
Hello,
We have an volume with an export policy applied:
volA = policy1
The policy has client match rules for the ESXi hosts.
However when we try and add this volume to an ESXi host we get an error saying mount request denied.
If we add a rule to the default export policy within the same SVM the volume is then added without issue.
Similarly if we apply 'policy1' to the root volume in the associated SVM we are able to mount 'volA' on the ESXi hosts.
Doesn't this kind of defeat the object of having an export policy associated with the volume if the underlying root volume controls the export access? Or is this a bug?
We are running 9.1P1.
Thanks
-
Alexander Griesser -
Daniel Taylor -
Parisi, Justin -
Scott M Gelb -
Tim McCarthy