--- title: Effektive Methode: So fügst du Export-Policy-Regeln in einem Vserver hinzu canonical: https://webhosting-verstehen.de/effektive-methode-so-fuegst-du-export-policy-regeln-in-einem-vserver-hinzu/ author: Webhosting-Verstehen Redaktion published: 2026-10-07 updated: 2026-09-19 language: de category: Virtual Private Server (VPS) description: Der Artikel erklärt, wie Export-Policy-Regeln in ONTAP geprüft, mit passenden Client-Matches erstellt und hinsichtlich Zugriff, Sicherheit und Protokoll korrekt konfiguriert werden. source: Provimedia GmbH --- # Effektive Methode: So fügst du Export-Policy-Regeln in einem Vserver hinzu > **Autor:** Webhosting-Verstehen Redaktion | **Veröffentlicht:** 2026-10-07 | **Aktualisiert:** 2026-09-19 **Zusammenfassung:** Der Artikel erklärt, wie Export-Policy-Regeln in ONTAP geprüft, mit passenden Client-Matches erstellt und hinsichtlich Zugriff, Sicherheit und Protokoll korrekt konfiguriert werden. --- ## 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. ## Nützliche Links zum Thema - [Eine Regel zu einer ONTAP NFS-Exportregel hinzufügen](https://docs.netapp.com/de-de/ontap/nfs-config/add-rule-export-policy-task.html) - [NetApp Protocols Overview | PDF - Scribd](https://de.scribd.com/document/223751755/Netapp) - [Installing orcharhino Server](https://docs.orcharhino.com/or/docs/sources/installation_and_maintenance/installing_orcharhino_server.html) --- *Dieser Artikel wurde ursprünglich veröffentlicht auf [webhosting-verstehen.de](https://webhosting-verstehen.de/effektive-methode-so-fuegst-du-export-policy-regeln-in-einem-vserver-hinzu/)* *© 2026 Provimedia GmbH*