I am trying to figure out how to prevent non-nfs volumes from showing up as exports. Support's answer is to disable showmount for everything. Is there a way to prevent export policies that don't have NFS in them from showing up in the nfs exports?
#showmount -e is showing non-nfs exported volumes
cosmic ermine
cobalt warren
I don't think there is a way to do that. I mean you won't be able to mount the directories anyway without a proper export policy, so it's just a false-positive
cosmic ermine
yeah, that's what I am seeing, but there is a very negative side effect of this. 1) it exposes volume information that it should not and 2) my backup software creates duplicate entries for cifs and nfs and if you have a default policy for the SVM to backup everything it fails on these volumes. It's annoying for a multi-protocol file server to not be able to understand when an export is cifs vs nfs 😉 I will be submitting an RFE. I don't want to have to move my volumes to another SVM with NFS disabled. IIRC, back in ontap 8 this didn't behave this way, but I don't remember for sure. Time to break out the simulators.
cobalt warren
do you really need showmount -e to be enabled? Most customers I know keep that off by default because it's not very useful in the first place, even if it works, because normally you know pretty well what paths each server/client has to mount
cosmic ermine
It's part of a workflow. Also, I think my backup software is dependent on this, but I am checking with my vendor to find out how they are determaning which shares are nfs vs cifs.
it's useful in the sense that ping and nmap are useful. If I can run a showmount -e server and see my export I am pretty confident I can mount it and it also tells me the path as a customer.
cobalt warren
yeah I'm also a bit disappointed that showmount hasn't been updated in cDOT to be more accurate (it worked pretty well in 7mode) but I don't think there's much to be gained by fixing it these days.
cosmic ermine
yeah, I agree. In the olden days, showmount -e would only show you what you had access to. (I miss my SunOS days) 😄
cosmic ermine
so, in my lab, turning off showmount seems to actually have convinced my backup software to switch to looking at the actual volume. I have opened a ticket with them to understand their workflow. I didn't expect this to actually work, so I am scratching my head a little.
rustic scarab
Take a look at https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-Issues/CONTAP-82609 which should change this behavior for some scenarios
cosmic ermine
Thanks Michael, I was just reviewing that document already as support just provided it to me. My issue seems to have been a two factor problem. 1) we had our original volumes on the default which had both NFS and CIFS rules. So all those volumes had NFS attached. We moved them to a new cifsonly export policy with just cifs/smb any/any/any.
- in doing number 1, someone also change the _root volume to be cifs only, breaking NFS, which also broke the rescan of the backup software. Once we fixed this, everything seems to have worked as expected. Only NFS volumes show as NFS in the backup software.
BUT, the reason I was given this document was the showmount -e. I am unsure how you have an export policy with no rules and still serve data? Is the document alluding to not needing a cifs rule to serve cifs/smb? If so, if we put in a rule that denies an IP, do all volumes using that rule suddenly show up with showmount -e?
cosmic ermine
I just tested this, and it does appear if you have a rule that is empty, it is not part of showmount -e and cifs mounting still seems to have worked. Adding a rule back in (no matter what I try to use for perms causes is to show up in showmount).
So it appears that you are required to use access values (even though it's cifs only) and that triggers the NFS perms.
So it makes no why there is even a CIFS/SMB checkbox in the export policy.
well, I just found this: https://kb.netapp.com/on-prem/ontap/da/NAS/NAS-KBs/Are_export_policy_rules_necessary_for_CIFS_access So that explains why it's being ignored. So that answers my question. New question is why is it even an option if CIFS is not enforced by export policies? Is this just legacy?
cobalt warren
of course CIFS can use export policies, it just doesn't do so by default. This is very useful if you want to allow/restrict CIFS access based in the IP range, for example
cosmic ermine
the fact you are required to add NFS access values seems to be the root cause here. There is no way to create a cifs only export policy with out also triggering an NFS access rule/value, which then causes the volume to show up in the exports. We are in a production freeze, so when we are out of it, we will remove the rule in our cifsonly policy. I have already tested this in my lab and it solves my problem.
cobalt warren
you can certainly create a CIFS-only export policy rule
cosmic ermine
When I try, it tells me I have to add at least one nfs access value. It seems the screen is tied to the NFS values. I have asked support to submit this as a bug.
cobalt warren
ah you're using System Manager? Yeah, that might require it. no idea, I rarely use that myself
cosmic ermine
I never thought of trying from CLI, I will test that another day.
cosmic ermine
clil fails as well without the rorule:
export-policy rule create -policyname empty -vserver test -ruleindex 1 -protocol cifs -clientmatch 0.0.0.0/0
Error: command failed: "rorule" is a required field
cobalt warren
umm yeah of course it fails, rorule and rwrule are required, you need to tell it if the clients should be allowed to read or write the data
weak imp
To be clear you should specify rorule and rwrule.
cosmic ermine
correct, but by doing that, it then adds an entry into the exports file for NFS. I have a call tomorrow with support (4th person on this ticket). The goal is to properly generate an RFE 😄
cobalt warren
correct, but by doing that, it then adds an entry into the exports file for NFS....
if you specify "cifs" as the protocol (i.e. -protocol cifs) it will not add a rule for NFS. There is no "exports" file anymore since 7-mode 🙂
but good luck with that RFE, I will also be quite happy if that is finally getting fixed 👍
cosmic ermine
So my convesation with support was very fruitful. I will summerize once I have all my documentation written up. I have 4 RFE's I am planning to submit and one change to the online documentation.
Short summary, I have a way to solve the showmount -e issue, but doesn't solve my security block problem without exposing the information.
cobalt warren
You can submit changes to the documentation via GitHub. The process works very well, just open an issue and it will be resolved