Urgently need "exportfs -c" equivalent for cDOT`

[SCOTT_LINDLEY]

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.

[Gippy · Accepted solution]

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.

[dcornely1]

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]

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]

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]

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_]

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]

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 Jul 17, 2013 8:43 AM for examples that describe why -clientmatch doesn't begin to cover the functionality of "exportfs -c". Even for situations where it will match specified objects, it doesn't test that the object actually has the specified rights. It baffles me how a critical command like this could have been left out of cDOT.

Sorry about venting. It's been frustrating migrating from 7-mode to cDOT and finding missing critical functionality such as no equivalent for "exportfs -c" and "exportfs -f". Makes it impossible to troubleshoot and fix issues related to netgroup membership changes. Sigh. We've been told that "maybe" these commands (among others) will be present in 8.3. Unfortunately, that will be sometime in the future, and in the meantime we're stuck.

There I go venting again. Thank you once again for your reply, I truly appreciate the time and effort required.

Scott