NFSv4.1 프로토콜은 LDAP 및 Kerberos를 사용하여 구현된 RPCSEC_GSS 인증 메서드를 사용하여 클라이언트 및 서버 인증, 메시지 무결성 검사, 전송 중인 데이터 암호화를 제공합니다.
이러한 보안 기능을 통해 NFSv4.1 프로토콜은 최신 네트워크 보안 규정 준수 요구사항과 호환됩니다.
모든 통신에 단일 서버 포트 2049를 사용하여 방화벽 구성을 간소화합니다.
NFSv4.1 파일 액세스 제어 목록 (ACL)을 지원합니다.
각 ACL은 파일 또는 디렉터리당 최대 50개의 액세스 제어 항목 (ACE)을 지원합니다. 여기에는 상속 레코드도 포함됩니다.
관리형 Microsoft AD 통합을 사용할 때 무제한 그룹 지원
임대 기반 어드바이저리 잠금을 사용하여 클라이언트 오류 처리를 개선합니다.
클라이언트는 서버와의 지속적인 연결을 확인해야 합니다. 클라이언트가 임대를 갱신하지 않으면 서버는 잠금을 해제하고 잠금 임대를 통해 액세스를 요청하는 다른 클라이언트가 파일을 사용할 수 있게 됩니다.
NFSv3에서는 잠금 상태에서 클라이언트가 삭제되면 새 GKE 노드와 같은 다른 클라이언트에서 파일에 액세스할 수 없습니다.
스테이트풀 복구를 지원합니다.
NFSv3과 달리 NFSv4.1은 TCP 및 연결 기반 상태 프로토콜입니다.
이전 세션의 클라이언트와 서버 상태는 복구 후 재개할 수 있습니다.
각 ACL은 최대 50개의 ACE를 지원합니다. 6개의 항목은 클라이언트 chmod 작업에서 생성된 자동 생성된 ACE용으로 예약되어 있습니다. 이러한 ACE는 생성 후 수정할 수 있습니다.
모드 비트를 나타내는 자동 생성된 ACE 레코드는 다음과 같은 우선순위 순서로 나열됩니다.
OWNER@의 DENY and ALLOW ACEs
GROUP@의 DENY and ALLOW ACEs
EVERYONE@의 DENY and ALLOW ACEs
이러한 ACE가 이미 있는 경우 새롭게 적용된 모드 비트에 따라 재사용 및 수정됩니다.
Filestore NFSv4.1은 POSIX 모드 RWX (읽기, 쓰기, 실행)에서만 필요한 액세스 권한 확인을 지원합니다. 콘텐츠 또는 SETATTR 사양을 수정하는 write append 작업과 write 작업을 구분하지 않습니다. nfs4_setfacl 유틸리티는 RWX를 바로가기로 허용하고 적절한 모든 플래그를 자동으로 사용 설정합니다.
nfs4_getfacl는 자체적으로 주 구성원을 번역하지 않습니다. nfs4_getfacl 유틸리티는 사용자의 숫자 UID 및 GUID를 표시합니다. 따라서 OWNER@, GROUP@, EVERYONE@의 특수 주 구성원이 표시됩니다.
관리형 Microsoft AD를 사용하는지와 관계없이 AUTH-SYS 및 nfs4_setfacl 유틸리티를 사용할 때 관리자는 사용자 이름이 아닌 숫자 UID 및 GUID를 지정해야 합니다. 이 유틸리티는 이름을 이러한 값으로 변환할 수 없습니다. 올바르게 제공되지 않으면 Filestore 인스턴스의 기본값은 nobody ID입니다.
파일 또는 상속된 ACE의 영향을 받는 파일의 쓰기 권한을 지정할 때 ACE에는 w (쓰기) 및 a (추가) 플래그가 모두 포함되어야 합니다.
SETATTR의 권한을 확인할 때 반환되는 응답은 다음과 같이 POSIX와 유사합니다.
수퍼유저 또는 ROOT 사용자는 무엇이든 할 수 있습니다.
파일 소유자만 모드 비트, ACL, 타임스탬프를 특정 시간 및 그룹(예: 속해 있는 GUID 중 하나)으로 설정할 수 있습니다.
파일 소유자가 아닌 사용자는 ACL을 비롯한 속성을 볼 수 있습니다.
단일 ACE는 유효 권한과 상속 전용 권한을 모두 포함합니다. 다른 NFSv4.1 구현과 달리 Filestore는 유효 ACE와 상속 전용 ACE를 구분하기 위해 상속된 ACE를 자동으로 복제하지 않습니다.
NFSv4.1 프로토콜은 AUDIT and ALARM ACEs를 지원하지 않습니다. Filestore는 데이터 액세스 감사를 지원하지 않습니다.
구성한 후에는 관리형 Microsoft AD 및 네트워크 피어링을 삭제하지 마세요.
이렇게 하면 클라이언트에 마운트되어 있는 동안 Filestore 공유에 액세스할 수 없으므로 데이터에 액세스할 수 없습니다. Google Cloud 는 관리자 또는 사용자 작업으로 인한 서비스 중단에 대해 책임을 지지 않습니다.
인증된 Kerberos 보안 설정을 사용하면 사용자에게 약간의 작업 지연이 발생할 수 있습니다. 지연 시간 비율은 지정된 서비스 등급 및 보안 설정에 따라 다릅니다. 보안 수준이 높아질수록 지연 시간이 증가합니다.
데이터 액세스 감사는 지원되지 않습니다.
Filestore NFSv4.1 솔루션은 관리형 Microsoft AD에서 모두 사용할 수 있는 LDAP 및 Kerberos를 사용하여 구현되는 RPCSEC_GSS 인증을 사용합니다. Filestore NFSv4.1은 NFSv3와 마찬가지로 인증 메커니즘 없이도 사용할 수 있습니다.
다른 인증 메커니즘은 지원되지 않습니다.
Filestore 인스턴스가 공유 VPC를 통해 관리 Microsoft AD에 참여하도록 하려면 gcloud 또는 Filestore API를 사용해야 합니다.Google Cloud 콘솔을 사용하여 인스턴스를 관리형 Microsoft AD에 조인할 수 없습니다.
관리 Microsoft AD 도메인 이름은 56자(영문 기준) 이하여야 합니다.
엔터프라이즈 인스턴스를 만들려면 Filestore API를 통해 직접 작업을 실행해야 합니다. 자세한 내용은 서비스 등급을 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-09-04(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)"]]
