ONTAP Discussions

Urgently need "exportfs -c" equivalent for cDOT`

SCOTT_LINDLEY
8,034 Views

I've been all over the NOW site, and I can't find an equivalent for the 7-mode "exportfs -c" command. Please advise. We urgently need this to validate export changes.

1 ACCEPTED SOLUTION

Gippy
6,226 Views

Better late than never.. 
I hope you weren't waiting for 3 years to get this answer:


export-policy check-access -vserver name01 -client-ip IP.adress.here -protocol nfs -access-type read -volume volname01 -qtree qtree01

cDOT has come a long way since.

View solution in original post

7 REPLIES 7

dcornely1
8,034 Views

I believe the vserver export-policy rule show command will give you what you need.  There are several parameters but If you add the -clientmatch one it appears to be similar to exportfs -c.  See the man page for this command here on page 1426 for what I believe may help:

https://library.netapp.com/ecm/ecm_download_file/ECMP1196817

SCOTT_LINDLEY
8,034 Views

First of all, I want to thank you for your prompt reply. I really thought that you were onto something, but unfortunately the listed command is not really like "exportfs -c". Let me set up a scenario to describe our need. We use netgroups heavily to configure rw, ro and root access to filesystems. Let's say I have these simple netgroups.

readonly (host1,,)

readwrite (host2,,) (host3,,)

root (host2,,)

IPs are:

host1 9.9.9.1

host2 9.9.9.2

host3 9.9.9.3

If I configure a policy that is the equivalent of:

/vol/VOL/QT -sys=sec,ro=@readonly,rw=@readwrite:@root,root=@root

In 7-mode if I run these commands I get:

# exportfs -c 9.9.9.2 /vol/VOL/QT rw

exportfs: 9.9.9.2 has rw access to /vol/VOL/QT

# exportfs -c 9.9.9.1 /vol/VOL/QT rw

exportfs: 9.9.9.1 does not have rw access to /vol/VOL/QT (Access denied)

In cDOT if I run what appears to be the equivalent command I get:

# vserver export-policy rule show -vserver MyVs -policyname MyPolicy -rwrule sys -clientmatch 9.9.9.2

There are no entries matching your query.

I also ran it without the "-rwrule sys" hoping that it would show me all matching rules, but I got the same result. The only success I can get is if I specify "-clientmatch @readwrite", but that's not helpful.

We have rare situations where, using the above hosts as an example, the forward and reverse lookups for a host don't match.

# host hosts

host2 has address 9.9.9.2

# host 9.9.9.2

2.9.9.9.in-addr.arpa domain name pointer otherhost

I need to be able to run the equivalent of "exportfs -c" against hosts that are in netgroups to ensure that the access is what I believe it to be. "exportfs -c" will correctly report that host2 (9.9.9.2) does not have access, but the "vserver export policy rule show..." command won't find that host or IP even if it resolves correctly, under these circumstances. Apparently "-clientmatch" is limited to matching only entries that are explicitly called out in a rule, and will not handle the situation where a host is part of a netgroup. I need a command that is the equivalent of "exportfs -c" in order to validate netgroup changes per our procedures. Please advise.

dcornely1
8,034 Views

Sorry this didn't work out.  I don't have any experience with netgroups at all and am still learning CDOT myself so I'm not sure where to look from here.  Hopefully you'll get someone from NetApp to reply to this issue...

SCOTT_LINDLEY
8,034 Views

We have opened a case. It looks like this is yet another command/functionality that was present in 7-Mode and is missing in cDOT. Seems like we're finding more of these almost every day. As cool as cDOT is in many ways, I'm beginning to wonder if it's really ready for prime time. I'm glad that NetApp seems to be focusing hard on stability, but functionality is very important too. While not having "exportfs -c" may seem like no big deal to a lot of people, to us it's a very big deal. It's the only real way to validate an export rule and/or netgroup change is really doing what you think it is.

FYI the BURT for this is 414977.

     Scott

Message was edited by: Scott Lindley

CCOLEMAN_
8,034 Views

Hey Scott,

I'm sure you already checked this, but just wanted to throw it out there,

[-clientmatch <text>] - Client Match Hostname, IP Address, Netgroup, or Domain

If  you specify this parameter, the command displays information only about  the export rules that have the specified client match. You can specify  the match in any of the following formats:
  • As a hostname; for instance, host1
  • As an IPv4 address; for instance, 10.1.12.24
  • As an IPv6 address; for instance, fd20:8b1e:b255:4071::100:1
  • As an IPv4 address with a subnet mask expressed as a number of bits; for instance, 10.1.12.10/4
  • As an IPv6 address with a subnet mask expressed as a number of bits; for instance, fd20:8b1e:b255:4071::/64
  • As an IPv4 address with a network mask; for instance, 10.1.16.0/255.255.255.0
  • As a netgroup, with the netgroup name preceded by the @ character; for instance, @eng
  • As a domain name preceded by the . character; for instance, .example.com

SCOTT_LINDLEY
8,034 Views

Thank you for responding. Unfortunately, -clientmatch is extremely limited limited in what it will match, and it will not descend into netgroup membership in any way, and does not test the actual access rights of the host(s) in question in any event. Please see my post from

Gippy
6,227 Views

Better late than never.. 
I hope you weren't waiting for 3 years to get this answer:


export-policy check-access -vserver name01 -client-ip IP.adress.here -protocol nfs -access-type read -volume volname01 -qtree qtree01

cDOT has come a long way since.

Public