NFS Export Policy

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

NFS Export Policy

Daniel Taylor

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
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NFS Export Policy

Scott M Gelb
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 <[hidden email]>
To: "[hidden email]" <[hidden email]>
Sent: Wednesday, April 5, 2017 6:20 AM
Subject: 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
_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters



_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: NFS Export Policy

Tim McCarthy
In reply to this post by Daniel Taylor
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.




On Wed, Apr 5, 2017 at 6:12 AM -0400, "Daniel Taylor" <[hidden email]> 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


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: NFS Export Policy

Daniel Taylor

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:[hidden email]]
Sent: 05 April 2017 11:30
To: [hidden email]; 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.

 



On Wed, Apr 5, 2017 at 6:12 AM -0400, "Daniel Taylor" <[hidden email]> 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


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

AW: NFS Export Policy

Alexander Griesser-2
In reply to this post by Daniel Taylor

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: [hidden email]

Web: http://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: [hidden email] [mailto:[hidden email]] Im Auftrag von Daniel Taylor
Gesendet: Mittwoch, 5. April 2017 12:08
An: [hidden email]
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


_______________________________________________
Toasters mailing list
[hidden email]
http://www.teaparty.net/mailman/listinfo/toasters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: NFS Export Policy

Parisi, Justin

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: [hidden email] [mailto:[hidden email]] On Behalf Of Alexander Griesser
Sent: Wednesday, April 5, 2017 7:32 AM
To: Daniel Taylor <[hidden email]>; [hidden email]
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: [hidden email]

Web: http://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: [hidden email] [[hidden email]] Im Auftrag von Daniel Taylor
Gesendet: Mittwoch, 5. April 2017 12:08
An: [hidden email]
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


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