Mendukung Daftar Kontrol Akses (ACL) file atau direktori
Tidak
Ya. Mendukung hingga 50 Entri Kontrol Akses (ACE) per daftar.
Dukungan grup
Maksimal 16 grup
Dukungan grup tanpa batas saat terhubung ke Microsoft AD Terkelola.
Setelan keamanan
sys. Membuat saluran kepercayaan.
sys. Membuat saluran kepercayaan. krb5. Mengautentikasi klien dan server. krb5i. Memberikan autentikasi dan pemeriksaan integritas pesan.krb5p. Menyediakan autentikasi, pemeriksaan integritas pesan, dan enkripsi data dalam pengiriman.
Latensi operasi
Tidak ada
Latensi operasi meningkat dengan tingkat keamanan yang dipilih.
Jenis pemulihan
Stateless
Stateful
Jenis penguncian file
Network Lock Manager (NLM). Kunci dikontrol oleh klien.
Penguncian saran berbasis sewa. Kunci dikontrol oleh server.
Protokol NFSv3 menawarkan penyiapan cepat untuk akses POSIX standar.
Batasan NFSv3
Berikut adalah daftar batasan NFSv3:
Tidak memiliki enkripsi dan autentikasi klien dan server.
Tidak memiliki penanganan kegagalan klien.
Manfaat NFSv4.1
Protokol NFSv4.1 menggunakan metode Autentikasi RPCSEC_GSS, yang diimplementasikan menggunakan LDAP
dan Kerberos untuk memberikan autentikasi
klien dan server, pemeriksaan integritas pesan, dan enkripsi data
dalam pengiriman.
Kemampuan keamanan ini membuat protokol NFSv4.1 kompatibel dengan persyaratan kepatuhan keamanan jaringan
modern:
Menggunakan satu port server, 2049, untuk semua komunikasi, sehingga membantu menyederhanakan
konfigurasi firewall.
Mendukung daftar kontrol akses (ACL) file NFSv4.1.
Setiap ACL mendukung hingga 50 entri kontrol akses (ACE) per file atau direktori. Hal ini mencakup catatan warisan.
Dukungan grup tanpa batas saat menggunakan integrasi Microsoft AD Terkelola.
Mendukung penanganan kegagalan klien yang lebih baik dengan penguncian saran berbasis sewa.
Klien harus memverifikasi koneksi yang berlanjut dengan server. Jika klien
tidak memperpanjang sewa, server akan melepaskan kunci dan file menjadi
tersedia untuk klien lain yang meminta akses melalui sewa kunci.
Di NFSv3, jika klien dihapus saat terkunci, file tidak dapat
diakses oleh klien lain, seperti node GKE baru.
Mendukung pemulihan stateful.
Tidak seperti NFSv3, NFSv4.1 adalah protokol stateful berbasis TCP dan koneksi.
Status klien dan server dalam sesi sebelumnya dapat dilanjutkan
setelah pemulihan.
Layanan Terkelola untuk Microsoft Active Directory
Mengotomatiskan pemetaan pengguna ID unik (UID) dan ID unik global (GUID).
Pengguna dan grup dapat dibuat di atau dimigrasikan ke Managed Microsoft AD.
Administrator dapat membuat kepercayaan domain dengan domain Active Directory (AD) dan LDAP lokal,
yang dikelola sendiri, saat ini. Dengan opsi ini,
migrasi tidak diperlukan.
Memberikan SLA.
Kontrol akses dan perilaku tambahan
ACE Filestore NFSv4.1 dikelola di Linux menggunakan perintah
berikut:
nfs4_setfacl: Membuat atau
mengedit ACE pada file atau direktori.
nfs4_getfacl: Mencantumkan
ACE pada file atau direktori.
Setiap ACL mendukung hingga 50 ACE. Enam entri dicadangkan untuk ACE otomatis
yang dibuat oleh operasi chmod klien. ACE ini dapat diubah setelah
pembuatan.
Data ACE yang dibuat secara otomatis yang mewakili bit mode tercantum dalam
urutan prioritas berikut:
DENY and ALLOW ACEs untuk OWNER@
DENY and ALLOW ACEs untuk GROUP@
DENY and ALLOW ACEs untuk EVERYONE@
Jika sudah ada, ACE tersebut akan digunakan kembali dan diubah
sesuai dengan bit mode baru yang diterapkan.
Filestore NFSv4.1 mendukung pemeriksaan akses yang diperlukan hanya dalam
mode POSIX RWX (baca, tulis, dan jalankan). Hal ini tidak akan membedakan antara
operasi write append dan write yang mengubah konten atau spesifikasi
SETATTR. Utilitas nfs4_setfacl juga menerima RWX sebagai pintasan dan
otomatis mengaktifkan semua flag yang sesuai.
nfs4_getfacl tidak menerjemahkan akun utama sendiri. Utilitas
nfs4_getfacl akan menampilkan UID dan GUID numerik untuk
prinsipal. Akibatnya, akun utama khusus OWNER@, GROUP@, dan
EVERYONE@ akan ditampilkan.
Terlepas dari apakah menggunakan Microsoft AD Terkelola, saat menggunakan
AUTH-SYS dan utilitas nfs4_setfacl, administrator harus menentukan
UID dan GUID numerik, bukan nama pengguna. Utilitas ini tidak dapat
menerjemahkan nama ke nilai ini. Jika tidak diberikan dengan benar, instance Filestore akan ditetapkan secara default ke ID nobody.
Saat menentukan izin tulis untuk file, atau bahkan file yang terpengaruh oleh
ACE yang diwarisi, ACE harus menyertakan flag w (tulis) dan a (tambahkan).
Saat memeriksa izin untuk SETATTR, respons yang ditampilkan mirip dengan
POSIX dengan cara berikut:
Pengguna superuser atau ROOT dapat melakukan apa pun.
Hanya pemilik file yang dapat menetapkan bit mode, ACL, dan stempel waktu ke
waktu dan grup tertentu, seperti salah satu GUID yang dimilikinya.
Pengguna selain pemilik file dapat melihat atribut, termasuk ACL.
Satu ACE mencakup izin efektif dan hanya warisan. Berbeda
dengan implementasi NFSv4.1 lainnya, Filestore tidak akan otomatis
mereplikasi ACES yang diwarisi untuk membedakan antara ACE yang efektif
dan ACE khusus warisan.
Batasan NFSv4.1
Berikut adalah daftar batasan NFSv4.1:
Protokol NFSv4.1 tidak dapat digabungkan dengan fitur berikut:
Protokol NFSv4.1 tidak mendukung AUDIT and ALARM ACEs. Filestore
tidak mendukung audit akses data.
Setelah dikonfigurasi, jangan hapus Managed Microsoft AD dan peering jaringan.
Tindakan ini menyebabkan berbagi Filestore tidak dapat diakses saat dipasang
di klien, sehingga data Anda tidak dapat diakses. Google Cloud tidak
bertanggung jawab atas pemadaman layanan yang disebabkan oleh tindakan administrator atau pengguna.
Saat menggunakan setelan keamanan Kerberos yang diautentikasi, pengguna dapat
mengalami beberapa latensi operasi. Rasio latensi bervariasi menurut tingkat layanan dan
setelan keamanan yang ditentukan. Latensi meningkat seiring dengan meningkatnya tingkat keamanan.
Audit akses data tidak didukung.
Solusi Filestore NFSv4.1 menggunakan Autentikasi RPCSEC_GSS, yang diimplementasikan menggunakan LDAP dan Kerberos, yang keduanya tersedia di Microsoft AD Terkelola. Filestore NFSv4.1 juga dapat digunakan tanpa mekanisme autentikasi apa pun, mirip dengan NFSv3.
Mekanisme autentikasi lainnya tidak didukung.
Jika ingin instance Filestore bergabung dengan Managed Microsoft AD
melalui VPC Bersama, Anda harus menggunakan gcloud atau Filestore
API. Anda tidak dapat bergabung ke instance ke Microsoft AD Terkelola menggunakan
konsolGoogle Cloud .
Nama domain Managed Microsoft AD tidak boleh melebihi 56 karakter.
Untuk membuat instance perusahaan, Anda harus menjalankan operasi
secara langsung melalui Filestore API. Untuk mengetahui informasi selengkapnya, lihat
Tingkat layanan.
Saat memulihkan cadangan, instance baru harus menggunakan protokol yang sama dengan
instance sumber.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 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)"]]
