Effektive Methode: So fügst du Export-Policy-Regeln in einem Vserver hinzu

Voraussetzungen für das Anlegen einer Export-Policy-Regel prüfen

Prüfe zuerst, ob die gewünschte Export-Policy auf der Daten-SVM vorhanden ist. Eine neue Regel lässt sich nur in einer bestehenden Policy anlegen. Nutze dafür die ONTAP-CLI und kontrolliere den Namen exakt:

vserver export-policy show -vserver svm

Für die Änderung brauchst du eine passende Admin-Berechtigung. Das gilt für Cluster-Administratoren und für Vserver-Administratoren mit ausreichenden Rechten. Fehlt diese Berechtigung, schlägt der Befehl bereits vor der eigentlichen Regelprüfung fehl.

Lege vor dem Erstellen außerdem die fachlichen Werte fest. Dazu gehören das Zugriffsprotokoll, der gewünschte Lese- oder Schreibzugriff, der Sicherheitstyp, die anonyme Benutzer-ID und ein freier Regelindex. Entscheide auch, ob du eine neue Regel brauchst oder eine bestehende Regel erweitert werden soll. Eine zusätzliche Regel kann unnötig sein, wenn eine vorhandene Regel den Client bereits passend abdeckt.

Bei Hostnamen und Domain-Matches muss die Namensauflösung funktionieren. Prüfe deshalb die DNS-Konfiguration der Daten-SVM sowie die Einträge für die NFS-Clients. Bei Kerberos muss zudem der verwendete Sicherheitstyp feststehen: krb5, krb5i oder krb5p. Kleine Unklarheiten an dieser Stelle führen später gern zu schwer sichtbaren Zugriffsfehlern.

Existiert die Export-Policy auf der richtigen Daten-SVM?
Verfügst du über die erforderliche Admin-Berechtigung?
Sind Protokoll, Regelindex, Zugriffsart und Sicherheitstyp festgelegt?
Ist der gewählte Client-Match technisch erreichbar und korrekt auflösbar?
Wird wirklich eine neue Regel benötigt?

Erst wenn diese Punkte geklärt sind, solltest du vserver export-policy rule create ausführen.

Vorhandene Exportregeln und den richtigen Regelindex anzeigen

Zeige die Regeln der Ziel-Policy zunächst ohne -clientmatch an. So erkennst du den gespeicherten Regelindex und vermeidest, dass ein zu enger Filter die gesuchte Zeile ausblendet:

vserver export-policy rule show -vserver svm -policyname default

Ersetze svm und default durch die Namen deiner Umgebung. Achte in der Ausgabe besonders auf ruleindex. Dieser Wert identifiziert die Regel eindeutig innerhalb der angegebenen Export-Policy. Er beschreibt keine laufende Zeilennummer und muss nicht bei 1 beginnen.

Für eine gezielte Prüfung kannst du den gefundenen Index direkt verwenden:

vserver export-policy rule show -vserver svm -policyname default -ruleindex 3

Nutze anschließend die ausführliche Darstellung, wenn mehrere Felder geprüft werden sollen:

vserver export-policy rule show -vserver svm -policyname default -ruleindex 3 -instance

Damit kontrollierst du unter anderem die gespeicherten Client-Matches, das Protokoll und die Zugriffswerte. Wichtig: -ruleindex und -clientmatch wirken gemeinsam. Ein korrekter Client-Match liefert trotzdem kein Ergebnis, wenn der angegebene Index zu einer anderen Regel gehört.

Policy-Name und SVM exakt übernehmen
Den Wert von ruleindex direkt aus der Ausgabe verwenden
Bei Unsicherheit zuerst ohne -clientmatch suchen
Für Details die Option -instance ergänzen

Bei der späteren Filterung muss der Suchwert dem gespeicherten Client-Match entsprechen. Ein kurzer Hostname findet nicht automatisch einen FQDN, eine IP-Adresse oder ein Netz. Das ist kein Volltextfilter, sondern eine gezielte Abfrage nach dem hinterlegten Wert.

Client-Matches im zulässigen Format festlegen

Der Parameter clientmatch legt fest, welche NFS-Clients eine Regel erreicht. Verwende dabei genau ein zulässiges Format pro Eintrag. Mehrere Einträge trennst du durch Kommas:

host1,10.1.12.24,@eng,.example.com

Für einzelne IPv4-Clients eignet sich eine Adresse wie 10.1.12.24. Ein Netz lässt sich mit einer Präfixlänge oder einer IPv4-Netzmaske angeben:

10.1.12.0/24
10.1.16.0/255.255.255.0

Auch IPv6 ist möglich. Nutze dafür eine vollständige Adresse oder ein Präfix:

fd20:8b1e:b255:4071::100:1
fd20:8b1e:b255:4071::/64

Für Netgroups steht ein @ vor dem Namen. Eine Domain beginnt mit einem Punkt. So gilt @eng für die Netgroup und .example.com für die Domain. Diese Schreibweise steuert die Auswertung des Eintrags.

Vermeide IP-Bereiche mit Bindestrich. Der Ausdruck 10.1.12.10-10.1.12.70 beschreibt in ONTAP kein gültiges Netz. Er wird als Hostname behandelt und erfüllt daher nicht den gewünschten Zweck. Für zusammenhängende Adressen verwendest du stattdessen ein passendes CIDR-Präfix.

Hostnamen, IP-Adressen, Netgroups und Domains können kombiniert werden.
Trenne mehrere Werte ohne Leerzeichen durch Kommas.
Verwende keine doppelten Einträge.
Beachte die Obergrenze von 4096 Client-Match-Strings.
Wähle eine Schreibweise, die exakt zum gewünschten Client oder Netz passt.

Beim Erstellen einer neuen Regel übergibst du die Liste mit -clientmatch. Der gespeicherte Eintrag muss später in derselben Form abgefragt werden. Ein kurzer Hostname ist daher nicht automatisch gleichbedeutend mit seinem FQDN.

Neue NFS-Regel mit `vserver export-policy rule create` anlegen

Mit vserver export-policy rule create legst du eine vollständige NFS-Regel in der vorhandenen Export-Policy an. Anders als beim späteren Ergänzen einer Regel werden dabei alle wesentlichen Eigenschaften in einem Schritt gespeichert.

Ein typischer Befehl für Lese- und Schreibzugriff sieht so aus:

vserver export-policy rule create -vserver svm -policyname default -ruleindex 10 -protocol nfs -clientmatch 10.1.12.0/24 -rorule sys -rwrule sys -superuser sys -anon 65534

Der Regelindex 10 dient hier als frei gewählter Platz. Eine gestaffelte Nummerierung wie 10, 20 und 30 lässt später Raum für weitere Regeln. Entscheidend ist nicht die Höhe der Zahl, sondern dass sie innerhalb der Policy eindeutig ist.

Die Option -protocol nfs bindet die Regel an NFS. Mit -rorule definierst du die Sicherheitstypen für Lesezugriff, während -rwrule die Typen für Schreibzugriff festlegt. -superuser steuert, welche authentifizierten Clients Root-Rechte behalten dürfen. Der Wert -anon 65534 ordnet nicht authentifizierte Zugriffe der anonymen UID 65534 zu.

Beschränke Root-Rechte möglichst stark. Für viele Umgebungen ist -superuser none die vorsichtigere Wahl. Prüfe außerdem, ob die verwendeten Sicherheitstypen tatsächlich zur NFS-Authentifizierung deiner Clients passen. Schreibzugriff ohne passenden Lesezugriff ist keine funktionierende Freigabe.

Bei mehreren Protokollen erstellst du entweder eine gemeinsame Regel mit einer passenden Protokollliste oder getrennte Regeln. Eine getrennte Struktur ist oft klarer, wenn NFSv3 und NFSv4 unterschiedliche Sicherheitsvorgaben erhalten sollen.

-vserver bestimmt die Daten-SVM.
-policyname nennt die Ziel-Policy.
-ruleindex identifiziert die neue Regel.
-protocol legt das Zugriffsprotokoll fest.
-anon bestimmt die Zuordnung anonymer Benutzer.

Nach dem Erstellen liest du die vollständige Regel mit der ausführlichen Anzeige aus. So erkennst du, ob ONTAP die Werte wie geplant übernommen hat.

Zugriff, Sicherheitstypen und Protokoll korrekt definieren

Lege die drei Zugriffsebenen getrennt fest: -rorule steuert das Lesen, -rwrule das Lesen und Schreiben, -superuser den Root-Zugriff. Die Werte müssen fachlich zusammenpassen. Ein Sicherheitstyp, der schreiben darf, muss auch lesen dürfen.

Für klassische UNIX-Authentifizierung kann eine Regel zum Beispiel so aussehen:

-rorule sys -rwrule sys -superuser none

Damit erhalten Clients mit UNIX-Sicherheitstyp Lese- sowie Schreibzugriff. Root-Zugriff bleibt jedoch ausgeschlossen. Wird Root-Zugriff benötigt, beschränke ihn auf den erforderlichen Sicherheitstyp und nicht pauschal auf alle Clients.

Bei Kerberos stehen drei Varianten zur Verfügung: krb5 authentifiziert, krb5i schützt zusätzlich die Integrität und krb5p bietet darüber hinaus Datenschutz. Verwende für Lese- und Schreibzugriff nur die Stufen, die deine Clients tatsächlich einsetzen. Ein höherer Schutztyp ersetzt keine korrekte Kerberos-Konfiguration.

any und never sind Sonderwerte. Sie dürfen nicht mit weiteren Sicherheitstypen in derselben Option kombiniert werden. Eine ungültige Mischung führt zu einem Fehler bei der Eingabe.

Wähle das Protokoll passend zur Bereitstellung. Für eine reine NFS-Regel verwendest du nfs. Wenn mehrere Protokolle erlaubt sind, muss die Syntax zur jeweiligen ONTAP-Version passen. Prüfe besonders, ob die Regel nur NFSv3, nur NFSv4 oder mehrere NFS-Varianten abdecken soll. Unterschiedliche Anforderungen lassen sich oft sauberer mit getrennten Regeln abbilden.

Lesezugriff vor Schreibzugriff prüfen.
Root-Zugriff nur bei echtem Bedarf freigeben.
Kerberos-Stufen exakt an die Client-Konfiguration anpassen.
any und never nicht mit anderen Typen mischen.
Das Protokoll auf den geplanten NFS-Zugriff begrenzen.

Die anonyme UID bestimmt, welchem UNIX-Benutzer ONTAP einen nicht zugeordneten Zugriff zuweist. Nutze dafür die UID des vorgesehenen Gastkontos.

Zusätzliche Client-Matches mit `vserver export-policy rule add-clientmatches` ergänzen

Mit vserver export-policy rule add-clientmatches ergänzt du eine bereits vorhandene Regel, ohne ihre Zugriffsrechte, Sicherheitstypen oder Protokolle zu verändern. Der Befehl arbeitet ausschließlich am Feld clientmatch. Für andere Eigenschaften ist vserver export-policy rule modify vorgesehen.

Verwende diese Syntax:

vserver export-policy rule add-clientmatches -vserver svm -policyname default -ruleindex 3 -clientmatches "2.2.2.2,3.3.3.3"

Die beiden IP-Adressen werden der Regel mit dem Index 3 hinzugefügt. Bereits gespeicherte Werte legt ONTAP nicht erneut an. Auch doppelte Angaben in derselben Liste führen nicht zu zusätzlichen Duplikaten.

Für die Ausführung brauchst du eine Admin-Berechtigung. Der Befehl steht Cluster-Administratoren und Vserver-Administratoren zur Verfügung. Die maximale Anzahl liegt bei 4096 Client-Match-Strings pro Regel. Plane bei großen Listen deshalb etwas Reserve ein.

Nutze den Parameter -clientmatches mit einer kommaseparierten Liste. Zulässig sind unter anderem einzelne IPv4- oder IPv6-Adressen, Präfixe, IPv4-Netzmasken, Hostnamen, Netgroups und Domainnamen. Ein Bereich mit Bindestrich, etwa 2.2.2.10-2.2.2.70, ist dagegen kein gültiger IP-Bereich. ONTAP behandelt ihn als Text und damit als Hostnamen.

-vserver: Ziel-SVM der Export-Policy
-policyname: Policy mit der bestehenden Regel
-ruleindex: Index der zu erweiternden Regel
-clientmatches: neue, kommaseparierte Client-Matches

Eine nachträgliche Abfrage mit einem verkürzten Namen kann trotz sichtbarem Hostnamen erfolglos bleiben. Übernimm für die Prüfung den gespeicherten Wert exakt, einschließlich FQDN, Netzpräfix oder anderer Schreibweise.

Beispiel: Zwei IP-Adressen zu einer bestehenden Regel hinzufügen

Angenommen, die bestehende Regel hat den Index 3 und soll zusätzlich für die beiden Clients 2.2.2.2 und 3.3.3.3 gelten. Dann lautet der vollständige Befehl:

vserver export-policy rule add-clientmatches -vserver vs0 -policyname default_expolicy -ruleindex 3 -clientmatches "2.2.2.2,3.3.3.3"

Der Parameter -vserver verweist auf die Daten-SVM vs0. -policyname bezeichnet die Export-Policy, während -ruleindex 3 die konkrete Regel auswählt. Die Anführungszeichen fassen die kommaseparierte Liste als einen Parameter zusammen.

Führe den Befehl in der ONTAP-CLI aus. Anschließend kannst du die Client-Matches dieser Regel gezielt anzeigen:

vserver export-policy rule show -vserver vs0 -policyname default_expolicy -ruleindex 3 -fields clientmatch

Zeigt die Ausgabe beide Adressen, war die Ergänzung erfolgreich. Findest du nur eine Adresse oder keine passende Regel, prüfe den gespeicherten Index und die Schreibweise der Policy. Ein bereits vorhandener Eintrag wird nicht verdoppelt.

Beide Adressen erhalten genau die Rechte, die für Regel 3 bereits definiert sind. Der Befehl vergibt keine neuen Lese-, Schreib- oder Root-Rechte, sondern erweitert lediglich den Kreis der Clients, auf die diese Regel zutrifft.

DNS, Kerberos und stabile Client-Adressen berücksichtigen

DNS beeinflusst, ob ein Hostname oder eine Domain als Client-Match zuverlässig greift. Prüfe auf der Daten-SVM, ob die hinterlegten DNS-Server für die NFS-Clients passende Vorwärts- und Rückwärtsauflösungen liefern. Ein fehlender oder widersprüchlicher Eintrag kann dazu führen, dass ONTAP einen Client nicht der erwarteten Regel zuordnet.

Ein kurzer Name wie host1 ist nicht automatisch identisch mit host1.example.com. Verwende in der Regel und bei späteren Abfragen genau die Form, die im DNS und in der Policy vorgesehen ist.

Bei Kerberos muss der Sicherheitstyp zur Client-Konfiguration passen. krb5 bietet Authentifizierung, krb5i ergänzt Integritätsschutz und krb5p schützt zusätzlich die übertragenen Daten. Stimmen Realm, Service-Principals, Uhrzeit oder DNS nicht, kann der Zugriff trotz passendem Client-Match scheitern. Eine Zeitabweichung zwischen Client, SVM und Kerberos-Infrastruktur ist dabei ein häufiger, unscheinbarer Auslöser.

Nutze für Kerberos-Clients stabile Namen und prüfe, ob die Namensauflösung in beide Richtungen konsistent ist. Ändert sich der Hostname, muss auch die zugehörige Kerberos-Identität zur Umgebung passen.

Statische oder dauerhaft reservierte Client-Adressen sind für IP-basierte Matches besser geeignet als wechselnde DHCP-Adressen. Temporäre IPv6-Adressen solltest du nicht fest in eine Policy schreiben. Für größere Umgebungen sind feste Netzpräfixe oder sauber gepflegte DNS-Namen meist robuster als viele einzelne, vergängliche Adressen.

Vorwärts- und Rückwärtsauflösung der NFS-Clients prüfen.
Kurznamen und FQDN nicht ungeprüft gleichsetzen.
Kerberos-Realm, Principals und Systemzeit gemeinsam kontrollieren.
Für IP-Matches feste oder reservierte Adressen verwenden.
Temporäre IPv6-Adressen nicht als dauerhafte Clientdefinition nutzen.

Export-Policy-Regel mit dem exakten Client-Match prüfen

Prüfe die Regel zuerst ohne den Filter -clientmatch. So erhältst du den tatsächlich gespeicherten Wert:

vserver export-policy rule show -vserver svm -policyname default -ruleindex 1 -instance

Für eine kompakte Ausgabe genügt:

vserver export-policy rule show -vserver svm -policyname default -fields clientmatch

Übernimm danach den vollständigen Eintrag exakt. Ein gespeicherter FQDN wie hostname1.example.com wird nicht automatisch durch die Abfrage nach hostname1 gefunden. Das Gleiche gilt für eine IP-Adresse, ein Präfix, eine Netgroup oder einen Domain-Match. Der Filter arbeitet semantisch und ist keine freie Textsuche.

Prüfe außerdem, ob der angegebene -ruleindex zur Regel gehört, in der der gesuchte Wert steht. Werden Index und Client-Match gemeinsam verwendet, müssen beide Bedingungen erfüllt sein. Ein falscher Index erzeugt daher ebenfalls die Meldung There are no entries matching your query.

Den gespeicherten Client-Match vollständig anzeigen.
FQDN und Kurzname nicht vertauschen.
Bei Netzen das Präfix oder die Netzmaske exakt übernehmen.
Den richtigen Regelindex mit dem Match kombinieren.
Keine verkürzten Suchbegriffe verwenden.

Nach einer Änderung mit add-clientmatches prüfst du auf diese Weise, ob die neuen Einträge in der erwarteten Regel angekommen sind. Erst die vollständige Ausgabe, dann der gezielte Filter.

Fehlersuche bei „There are no entries matching your query“

Die Meldung There are no entries matching your query bedeutet zunächst nur, dass die gesamte Filterkombination kein Ergebnis liefert. Sie beweist nicht, dass der Client keinen Zugriff erhält. Trenne deshalb die Fehlersuche in drei Prüfungen:

Ist die angegebene SVM korrekt?
Existiert die Export-Policy unter diesem Namen?
Passt der Regelindex zum gespeicherten Eintrag?

Führe die Abfrage schrittweise aus. Beginne mit der Policy und ergänze erst dann den Index. Den Client-Filter setzt du zuletzt. So erkennst du, an welcher Bedingung die Suche scheitert.

Prüfe bei einer erweiterten Regel außerdem, ob die Adresse bereits vorhanden war. Der Befehl add-clientmatches meldet eine vorhandene Adresse nicht als neuen Eintrag. Kontrolliere daher die vollständige Liste und nicht nur die erwartete Änderung.

Bleibt die Abfrage leer, obwohl die Regel sichtbar ist, entferne zunächst -clientmatch und -ruleindex. Zeigt ONTAP die Policy dann an, füge die Filter einzeln wieder hinzu. Dieses Ausschlussverfahren grenzt einen falschen Wert schnell ein.

Prüfe abschließend die wirksame Regel am konkreten Volume oder Exportpfad. Eine gefundene Policy-Regel allein beweist noch nicht, dass genau dieser Pfad die Policy verwendet. Stimmen Pfadzuordnung und Policy nicht überein, liegt das Problem außerhalb des Client-Match-Filters.

Fazit: Regel gezielt erstellen, erweitern und verifizieren

Eine saubere Arbeitsweise besteht aus drei klar getrennten Schritten: Regel anlegen, bestehende Regel gezielt erweitern und das Ergebnis anschließend mit der gespeicherten Konfiguration abgleichen. So bleibt nachvollziehbar, welche Änderung vorgenommen wurde und welche Wirkung sie haben soll.

Für die tägliche Administration ist vor allem die Trennung der Befehle wichtig. vserver export-policy rule create erstellt eine vollständige Regel. vserver export-policy rule add-clientmatches erweitert dagegen ausschließlich die Client-Matches. Soll sich eine andere Eigenschaft ändern, ist dafür vserver export-policy rule modify zuständig.

Dokumentiere nach jeder Änderung mindestens SVM, Policy, Regelindex, Zeitpunkt und die betroffenen Client-Matches. Diese kurze Änderungsnotiz erleichtert spätere Audits und zeigt, ob ein Zugriff bewusst erweitert oder nur technisch korrigiert wurde. Bei kritischen Exporten empfiehlt sich zusätzlich ein kontrollierter Zugriffstest mit einem berechtigten und einem nicht berechtigten Client.

Die gewünschte Regeländerung eindeutig beschreiben.
Nur den Befehl verwenden, der genau dieses Feld ändert.
Die Konfiguration nach der Änderung erneut auslesen.
Den Zugriff mit realen Testbedingungen prüfen.
Änderung und Ergebnis nachvollziehbar dokumentieren.

Damit wird aus einer einzelnen CLI-Eingabe ein belastbarer Ablauf: Die Regel bleibt übersichtlich, unbeabsichtigte Rechteänderungen werden vermieden und spätere Fehler lassen sich schneller eingrenzen. Gerade bei vielen SVMs oder häufigen Clientwechseln spart diese Disziplin im Betrieb spürbar Zeit.