Unterstützt LDAP und Kerberos für die Authentifizierung (krb5), Nachrichtenintegritätsprüfungen (krb5i) und die Verschlüsselung von Daten während der Übertragung (krb5p).
Bietet NFSv4.1-Datei-ACL-Unterstützung für Client und Server.
Jedes Protokoll eignet sich am besten für bestimmte Anwendungsfälle. In der folgenden Tabelle werden die Spezifikationen der einzelnen Protokolle verglichen:
Spezifikation
NFSv3
NFSv4.1
Unterstützte Dienststufen
Alle Dienststufen
Zonal, regional und für Unternehmen
Bidirektionale Kommunikation
Ja
Nein. Die Kommunikation wird immer vom Client über den Serverport 2049 initiiert.
Unterstützt Datei- oder Verzeichnis-ACLs (Access Control Lists)
Nein
Ja. Unterstützt bis zu 50 ACEs (Access Control Entries) pro Liste.
Google Groups-Support
Bis zu 16 Gruppen
Unterstützung für unbegrenzte Gruppen bei Verbindung mit Managed Microsoft AD.
Sicherheitseinstellung
sys. Erstellt einen Vertrauenskanal.
sys. Erstellt einen Vertrauenskanal. krb5. Authentifiziert den Client und den Server. krb5i. Bietet Authentifizierung und Nachrichtenintegritätsprüfungen.krb5p. Bietet Authentifizierung, Nachrichtenintegritätsprüfungen und Datenverschlüsselung während der Übertragung.
Vorgangslatenz
Keine
Die Latenz der Vorgänge erhöht sich mit dem ausgewählten Sicherheitsniveau.
Wiederherstellungstyp
Zustandslos
Zustandsorientiert
Sperrtyp der Datei
Network Lock Manager (NLM) Das Schloss wird vom Client gesteuert.
Lease-basierte richtlinienbasierte Sperrung Die Sperre wird vom Server gesteuert.
Das NFSv3-Protokoll bietet eine schnelle Einrichtung für den standardmäßigen POSIX-Zugriff.
Einschränkungen von NFSv3
Im Folgenden finden Sie eine Liste der Einschränkungen von NFSv3:
Es fehlt die Client- und Serverauthentifizierung und -verschlüsselung.
Es gibt keine Fehlerbehandlung für Clients.
Vorteile von NFSv4.1
Das NFSv4.1-Protokoll verwendet die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird, um Client- und Serverauthentifizierung, Nachrichtenintegritätsprüfungen und die Verschlüsselung von Daten während der Übertragung bereitzustellen.
Diese Sicherheitsfunktionen machen das NFSv4.1-Protokoll mit modernen Compliance-Anforderungen an die Netzwerksicherheit kompatibel:
Es wird ein einzelner Serverport, 2049, für die gesamte Kommunikation verwendet, was die Firewallkonfiguration vereinfacht.
Unterstützt NFSv4.1-Datei-ACLs (Access Control Lists).
Jede ACL unterstützt bis zu 50 Zugriffssteuerungseinträge (ACEs) pro Datei oder Verzeichnis. Dazu gehören auch Erbschaftsunterlagen.
Unterstützung für unbegrenzte Gruppen bei Verwendung der Managed Microsoft AD-Integration.
Bessere Fehlerbehandlung bei Clients durch leasebasierte richtlinienbasierte Sperrung
Der Client muss die fortlaufende Verbindung zum Server prüfen. Wenn der Client den Lease nicht verlängert, löst der Server die Sperre auf und die Datei wird für alle anderen Clients verfügbar, die über einen Lease Zugriff anfordern.
Wenn in NFSv3 ein Client gelöscht wird, während er gesperrt ist, kann kein anderer Client, z. B. ein neuer GKE-Knoten, auf die Datei zugreifen.
Unterstützt die zustandsorientierte Wiederherstellung.
Im Gegensatz zu NFSv3 ist NFSv4.1 ein TCP- und verbindungsbasiertes zustandsorientiertes Protokoll.
Der Status des Clients und des Servers in der vorherigen Sitzung kann nach der Wiederherstellung fortgesetzt werden.
Automatisiert die Nutzerzuordnung für eindeutige Kennungen (UID) und global eindeutige Kennungen (GUID).
Nutzer und Gruppen können in Managed Microsoft AD erstellt oder dorthin migriert werden.
Administratoren können eine Domain-Vertrauensstellung mit der aktuellen lokalen, selbst verwalteten Active Directory- (AD-) und LDAP-Domain erstellen. Bei dieser Option ist keine Migration erforderlich.
Bietet ein SLA.
Zugriffssteuerung und zusätzliches Verhalten
Filestore NFSv4.1-ACEs werden unter Linux mit den folgenden Befehlen verwaltet:
nfs4_setfacl: Erstellen oder bearbeiten Sie ACEs für eine Datei oder ein Verzeichnis.
nfs4_getfacl: Listet die ACEs für eine Datei oder ein Verzeichnis auf.
Jede ACL unterstützt bis zu 50 ACEs. Sechs Einträge sind für automatisch generierte ACEs reserviert, die von chmod-Vorgängen des Kunden erstellt wurden. Diese ACEs können nach dem Erstellen geändert werden.
Die automatisch generierten ACE-Einträge, die die Modusbits darstellen, sind in der folgenden Prioritätsreihenfolge aufgeführt:
DENY and ALLOW ACEs für OWNER@
DENY and ALLOW ACEs für die GROUP@
DENY and ALLOW ACEs für EVERYONE@
Wenn solche ACEs bereits vorhanden sind, werden sie wiederverwendet und gemäß den neuen angewandten Modus-Bits geändert.
Filestore NFSv4.1 unterstützt die Überprüfung des erforderlichen Zugriffs nur im POSIX-Modus RWX (Lesen, Schreiben und Ausführen). Es wird nicht zwischen write append- und write-Vorgängen unterschieden, die den Inhalt oder die SETATTR-Spezifikation ändern. Das Dienstprogramm nfs4_setfacl akzeptiert auch RWX als Verknüpfung und aktiviert automatisch alle entsprechenden Flags.
Die nfs4_getfacl führt keine Übersetzung des Prinzipals aus. Das nfs4_getfacl-Dienstprogramm zeigt die numerischen UID und GUID für die Hauptbenutzer an. Daher werden die speziellen Hauptkonten von OWNER@, GROUP@ und EVERYONE@ angezeigt.
Unabhängig davon, ob Managed Microsoft AD verwendet wird, müssen Administratoren bei der Arbeit mit AUTH-SYS und dem Dienstprogramm nfs4_setfacl die numerischen UID und GUID angeben, keine Nutzernamen. Dieses Dienstprogramm kann Namen nicht in diese Werte umwandeln. Wenn die Angabe nicht korrekt ist, wird für die Filestore-Instanz standardmäßig die nobody-ID verwendet.
Wenn Sie Schreibberechtigungen für eine Datei oder für Dateien angeben, die von einer übergeordneten ACE betroffen sind, muss die ACE sowohl die Flags w (Schreiben) als auch a (Anhängen) enthalten.
Wenn Sie die Berechtigungen für SETATTR prüfen, ähnelt die zurückgegebene Antwort POSIX in folgender Weise:
Der Superuser oder ROOT-Nutzer kann alles tun.
Nur der Eigentümer der Datei kann die Bits für den Dateimodus, die ACLs und die Zeitstempel auf eine bestimmte Zeit und Gruppe festlegen, z. B. auf eine der GUIDs, zu denen sie gehört.
Andere Nutzer als der Dateiinhaber können die Attribute, einschließlich der ACL, aufrufen.
Ein einzelner ACE umfasst sowohl effektive als auch nur vererbbare Berechtigungen. Im Gegensatz zu anderen NFSv4.1-Implementierungen werden in Filestore nicht automatisch übernommene Zugriffssteuerungsobjekte repliziert, um zwischen effektiven und nur zu übernehmenden Zugriffssteuerungsobjekten zu unterscheiden.
Einschränkungen von NFSv4.1
Im Folgenden finden Sie eine Liste der Einschränkungen von NFSv4.1:
Das NFSv4.1-Protokoll kann nicht mit den folgenden Funktionen kombiniert werden:
Das NFSv4.1-Protokoll unterstützt AUDIT and ALARM ACEs nicht. Filestore unterstützt keine Prüfung des Datenzugriffs.
Löschen Sie Managed Microsoft AD und das Netzwerk-Peering nach der Konfiguration nicht.
Dadurch ist die Filestore-Freigabe nicht zugänglich, während sie auf einem Client bereitgestellt wird, und Ihre Daten sind nicht zugänglich. Google Cloud haftet nicht für Ausfälle, die durch Administrator- oder Nutzeraktionen verursacht werden.
Bei Verwendung einer der authentifizierten Kerberos-Sicherheitseinstellungen kann es zu einer gewissen Latenz bei den Vorgängen kommen. Die Latenzraten variieren je nach Dienstebene und angegebener Sicherheitseinstellung. Die Latenz steigt mit jedem höheren Sicherheitsniveau.
Die Prüfung des Datenzugriffs wird nicht unterstützt.
Die Filestore NFSv4.1-Lösung verwendet die RPCSEC_GSS-Authentifizierung, die mit LDAP und Kerberos implementiert wird. Beide sind in verwaltetem Microsoft AD verfügbar. Filestore NFSv4.1 kann ähnlich wie NFSv3 auch ohne Authentifizierungsmechanismen verwendet werden.
Andere Authentifizierungsmechanismen werden nicht unterstützt.
Wenn Sie eine Filestore-Instanz über ein freigegebene VPC mit Managed Microsoft AD verknüpfen möchten, müssen Sie gcloud oder die Filestore API verwenden. Sie können die Instanz nicht über dieGoogle Cloud -Konsole mit Managed Microsoft AD verknüpfen.
Der Domainname der verwalteten Microsoft AD-Instanz darf maximal 56 Zeichen lang sein.
Wenn Sie eine Enterprise-Instanz erstellen möchten, müssen Sie die Vorgänge direkt über die Filestore API ausführen. Weitere Informationen finden Sie unter Dienststufen.
Beim Wiederherstellen einer Sicherung muss die neue Instanz dasselbe Protokoll wie die Quellinstanz verwenden.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-18 (UTC)."],[[["\u003cp\u003eFilestore supports two primary file system protocols: NFSv3, which offers quick setup for standard POSIX access, and NFSv4.1, which provides enhanced security and compatibility with modern network configurations.\u003c/p\u003e\n"],["\u003cp\u003eNFSv4.1 requires RPCSEC_GSS authentication, leveraging LDAP and Kerberos for client and server authentication, message integrity checks, and in-transit data encryption, and is best suited for environments with strict security needs.\u003c/p\u003e\n"],["\u003cp\u003eNFSv3 is available in all service tiers and offers bidirectional communication, while NFSv4.1 is available in zonal, regional, and enterprise tiers and uses a single server port for communication, simplifying firewall management.\u003c/p\u003e\n"],["\u003cp\u003eNFSv4.1 supports file access control lists (ACLs) with up to 50 entries per list, along with unlimited group support when integrated with Managed Microsoft AD, which is the recommended solution for managing LDAP and Kerberos for NFSv4.1.\u003c/p\u003e\n"],["\u003cp\u003eWhile offering security advantages, NFSv4.1 has limitations, including increased operational latency with higher security levels, the inability to use it with the Filestore GKE CSI driver or multishares for GKE, and the lack of data access auditing.\u003c/p\u003e\n"]]],[],null,["# About supported file system protocols\n\nFilestore supports the following file system protocols:\n\nNFSv3\n\n- Available in all service tiers.\n- Supports bidirectional communication between the client and server.\n - Uses multiple ports.\n - Creates a trust channel for network traffic and operations.\n- Offers quick setup for standard POSIX access.\n\nNFSv4.1\n\n- Available in [zonal, regional, and\n enterprise service tiers](/filestore/docs/service-tiers).\n- Compatible with modern firewall configurations and supports network security compliance requirements.\n - Communication is always initiated by the client and always served through a single server port, `2049`.\n - Supports client and server authentication.\n - Requires [RPCSEC_GSS Authentication](https://docs.kernel.org/filesystems/nfs/rpc-server-gss.html) which is implemented using [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) and [Kerberos](https://web.mit.edu/kerberos/krb5-latest/doc/), both available in [Managed Service for Microsoft Active Directory](/managed-microsoft-ad/docs/overview).\n - Supports LDAP and Kerberos for authentication (`krb5`), message integrity checks (`krb5i`), and in-transit data encryption (`krb5p`).\n - Offers NFSv4.1 file ACL support for the client and server.\n\nEach protocol is best suited to specific use cases. The following table compares\nthe specifications of each protocol:\n\nBenefits of NFSv3\n-----------------\n\nThe NFSv3 protocol offers quick setup for standard POSIX access.\n\n### NFSv3 limitations\n\nThe following is a list of NFSv3 limitations:\n\n- Lacks client and server authentication and encryption.\n- Lacks client failure handling.\n\nBenefits of NFSv4.1\n-------------------\n\nThe NFSv4.1 protocol uses the [RPCSEC_GSS Authentication](https://docs.kernel.org/filesystems/nfs/rpc-server-gss.html)\nmethod, which is implemented using [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol)\nand [Kerberos](https://web.mit.edu/kerberos/krb5-latest/doc/) to provide client\nand server authentication, message integrity checks, and in-transit data\nencryption.\n\nThese security capabilities make the NFSv4.1 protocol compatible with modern\nnetwork security compliance requirements:\n\n- Uses a single server port, `2049`, for all communication, helping simplify\n firewall configurations.\n\n- Supports NFSv4.1 file access control lists (ACLs).\n\n - Each ACL supports up to 50 access control entries (ACEs) per file or directory. This includes inheritance records.\n- Unlimited groups support when using Managed Microsoft AD integration.\n\n- Supports better client failure handling with lease-based advisory locking.\n\n - The client must verify continued connection with the server. If the client doesn't renew the lease, the server releases the lock and the file becomes available to any other client requesting access through a lock lease. In NFSv3, if a client is deleted while under lock, the file can't be accessed by another client, such as a new GKE node.\n- Supports stateful recovery.\n\n - Unlike NFSv3, NFSv4.1 is a TCP- and connection-based stateful protocol. The state of the client and server in the previous session can be resumed after recovery.\n\n### Managed Service for Microsoft Active Directory\n\nWhile [Managed Service for Microsoft Active Directory (Managed Microsoft AD)](/security/products/managed-microsoft-ad/docs/overview)\nis not a strict requirement, it is the only Google Cloud-managed solution to\nsupport both LDAP and Kerberos, both of which are requirements for the\nFilestore NFSv4.1 protocol.\n\nAdministrators are strongly encouraged to use\n[Managed Service for Microsoft Active Directory (Managed Microsoft AD)](/security/products/managed-microsoft-ad/docs/overview)\nto implement and manage LDAP and Kerberos.\n\nAs a Google Cloud-managed solution, Managed Microsoft AD provides the\nfollowing benefits:\n\n- Offers multiregion deployment, supporting up to five regions on the same domain.\n\n - Reduces latency by ensuring users and their respective login servers are in closer proximity.\n- Supports [POSIX RFC 2307](https://www.rfc-editor.org/rfc/rfc2307.txt) and\n [RFC 2307bis](https://datatracker.ietf.org/doc/html/draft-howard-rfc2307bis-01),\n requirements for NFSv4.1 implementation.\n\n- Automates unique identifier (UID) and globally unique identifier (GUID) user\n mapping.\n\n- Users and groups can be created in or migrated to Managed Microsoft AD.\n\n- Administrators can create a domain trust with the current on-premises,\n self-managed, Active Directory (AD) and LDAP domain. With this option,\n migration is not necessary.\n\n- Provides an SLA.\n\n### Access control and additional behaviors\n\n- Filestore NFSv4.1 ACEs are managed on Linux using the following\n commands:\n\n - [**`nfs4_setfacl`**](https://linux.die.net/man/1/nfs4_setfacl): Create or edit ACEs on a file or directory.\n - [**`nfs4_getfacl`**](https://linux.die.net/man/1/nfs4_getfacl): List the ACEs on a file or directory.\n- Each ACL supports up to 50 ACEs. Six entries are reserved for autogenerated\n ACEs created by client `chmod` operations. These ACEs can be modified after\n creation.\n\n The autogenerated ACE records representing the mode bits are listed in the\n following order of priority:\n - `DENY and ALLOW ACEs` for the `OWNER@`\n - `DENY and ALLOW ACEs` for the `GROUP@`\n - `DENY and ALLOW ACEs` for `EVERYONE@`\n\n If such ACEs are already present, they will be re-used and modified\n according to the new applied mode bits.\n- Filestore NFSv4.1 supports checking the required access only in\n POSIX mode `RWX` (read, write, and execute). It won't differentiate between\n `write append` and `write` operations that modify the content or `SETATTR`\n specification. The `nfs4_setfacl` utility also accepts `RWX` as a shortcut and\n automatically turns on all the appropriate flags.\n\n- The `nfs4_getfacl` doesn't do any translation of the principal on its own. The\n `nfs4_getfacl` utility will show the numeric `UID` and `GUID` for the\n principals. As a result, the special principals of `OWNER@`, `GROUP@`, and\n `EVERYONE@` will be shown.\n\n- Regardless of whether using Managed Microsoft AD, when working with\n `AUTH-SYS` and the `nfs4_setfacl` utility, administrators must specify the\n numeric `UID` and `GUID`, not user names. This utility isn't able to\n translate names to these values. If not provided correctly, the\n Filestore instance will default to the `nobody` ID.\n\n- When specifying write permissions for a file, or even files affected by\n an inherited ACE, the ACE must include both the `w` (write) and `a` (append)\n flags.\n\n- When checking permissions for `SETATTR`, the returned response is similar to\n `POSIX` in the following way:\n\n - The superuser or `ROOT` user can do anything.\n - Only the file owner can set the mode bits, ACLs, and time stamps to a specific time and group, such as one of the `GUID`s it belongs to.\n - Users other than the file owner may view the attributes, including the ACL.\n- A single ACE encompasses both effective and inherit-only permissions. Contrary\n to other NFSv4.1 implementations, Filestore won't automatically\n replicate inherited ACES for the purpose of distinguishing between effective\n and inherit-only ACEs.\n\n### NFSv4.1 limitations\n\nThe following is a list of NFSv4.1 limitations:\n\n- The NFSv4.1 protocol can't be combined with the following features:\n\n - [Filestore GKE CSI driver](/filestore/docs/filestore-for-gke#csi-driver)\n - [Filestore multishares for GKE](/filestore/docs/multishares)\n- The NFSv4.1 protocol doesn't support `AUDIT and ALARM ACEs`. Filestore\n doesn't support data access auditing.\n\n- Once configured, don't delete Managed Microsoft AD and network peering.\n Doing so causes the Filestore share to be inaccessible while mounted\n on a client, making your data inaccessible. Google Cloud is not\n liable for outages caused by administrator or user actions.\n\n- When using any of the authenticated Kerberos security settings, users can\n expect some operations latency. Latency rates vary by the service tier and\n security setting specified. Latency increases with each increasing security\n level.\n\n- Data access auditing is not supported.\n\n- The Filestore NFSv4.1 solution uses [RPCSEC_GSS Authentication](https://docs.kernel.org/filesystems/nfs/rpc-server-gss.html), which is implemented using [LDAP](https://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol) and [Kerberos](https://web.mit.edu/kerberos/krb5-latest/doc/), both available in [Managed Microsoft AD](/security/products/managed-microsoft-ad/docs/overview). Filestore NFSv4.1 can also be used without any authentication mechanisms, similarly to NFSv3.\n Other authentication mechanisms are not supported.\n\n- If you want a Filestore instance to join Managed Microsoft AD\n through a Shared VPC, you must use `gcloud` or the Filestore\n API. You can't join the instance to Managed Microsoft AD using the\n Google Cloud console.\n\n- The Managed Microsoft AD domain name must not exceed 56 characters.\n\n- To create an enterprise instance, you must run operations\n directly through the Filestore API. For more information, see\n [Service tiers](/filestore/docs/service-tiers#legacy-tiers).\n\n- When restoring a backup, the new instance must use the same protocol as the\n source instance.\n\nWhat's next\n-----------\n\n- [Configure the NFSv4.1 protocol](/filestore/docs/configure-nfsv4)"]]
