About supported file system protocols

Filestore supports the following file system protocols:

NFSv3

  • Available in all service tiers.
  • Supports bidirectional communication between the client and server.
    • Uses multiple ports.
    • Creates a trust channel for network traffic and operations.
  • Offers quick setup for standard POSIX access.

NFSv4.1 (Preview)

  • Available in enterprise and zonal service tiers.
  • Compatible with modern firewall configurations and supports network security compliance requirements.
    • Communication is always initiated by the client and always served through a single server port, 2049.
    • Supports client and server authentication.

Each protocol is best suited to specific use cases. The following table compares the specifications of each protocol:

Specification NFSv3 NFSv4.1
Supported service tiers All service tiers Enterprise and zonal
Bidirectional communication Yes No. Communication is always initiated by the client using server port 2049.
Authentication No Yes. Requires RPCSEC_GSS Authentication, implemented using LDAP and Kerberos, both available in Managed Service for Microsoft Active Directory.
Supports file or directory Access Control Lists (ACLs) No Yes. Supports up to 50 Access Control Entries (ACEs) per list.
Groups support Up to 16 groups Unlimited groups support when connected to Managed Microsoft AD.
Security setting sys. Creates a trust channel. sys. Creates a trust channel. krb5. Authenticates the client and server. krb5i. Provides authentication and message integrity checks.krb5p. Provides authentication, message integrity checks, and in-transit data encryption.
Operations latency None Operations latency increases with the security level selected.
Recovery type Stateless Stateful
File locking type Network Lock Manager (NLM). The lock is controlled by the client. Lease-based advisory locking. The lock is controlled by the server.
Supports client failures No Yes
Supports private services connection (PSC) No No

Benefits of NFSv3

The NFSv3 protocol offers quick setup for standard POSIX access.

NFSv3 limitations

The following is a list of NFSv3 limitations:

Benefits of NFSv4.1

The NFSv4.1 protocol uses the RPCSEC_GSS Authentication method, which is implemented using LDAP and Kerberos to provide client and server authentication, message integrity checks, and in-transit data encryption.

These security capabilities make the NFSv4.1 protocol compatible with modern network security compliance requirements:

  • Uses a single server port, 2049, for all communication, helping simplify firewall configurations.

  • Unlimited groups support when using Managed Microsoft AD integration.

  • Supports better client failure handling with lease-based advisory locking.

    • 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.

  • Supports stateful recovery.

    • 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.

Managed Service for Microsoft Active Directory

While Managed Service for Microsoft Active Directory (Managed Microsoft AD) is not a strict requirement, it is the only Google Cloud-managed solution to support both LDAP and Kerberos, both of which are requirements for the Filestore NFSv4.1 protocol.

Administrators are strongly encouraged to use Managed Service for Microsoft Active Directory (Managed Microsoft AD) to implement and manage LDAP and Kerberos.

As a Google Cloud-managed solution, Managed Microsoft AD provides the following benefits:

  • Offers multiregion deployment, supporting up to five regions on the same domain.

    • Reduces latency by ensuring users and their respective login servers are in closer proximity.

  • Supports POSIX RFC 2307 and RFC 2307bis, requirements for NFSv4.1 implementation.

  • Automates unique identifier (UID) and globally unique identifier (GUID) user mapping.

  • Users and groups can be created in or migrated to Managed Microsoft AD.

  • Administrators can create a domain trust with the current on-premises, self-managed, Active Directory (AD) and LDAP domain. With this option, migration is not necessary.

  • Provides an SLA.

NFSv4.1 limitations

The following is a list of NFSv4.1 limitations:

  • The NFSv4.1 protocol can't be combined with the following features:

  • Once configured, don't delete Managed Microsoft AD and network peering. Doing so causes the Filestore share to be inaccessible while mounted on a client, making your data inaccessible. Google Cloud is not liable for outages caused by administrator or user actions.

  • When using any of the authenticated Kerberos security settings, users can expect some operations latency. Latency rates vary by the service tier and security setting specified. Latency increases with each increasing security level.

  • Data access auditing is not supported.

  • The Filestore NFSv4.1 solution requires RPCSEC_GSS Authentication. This authentication method is only implemented using LDAP and Kerberos, both available in Managed Microsoft AD. Other authentication mechanisms are not supported.

  • Lacks support for private services connection (PSC).

  • If you want a Filestore instance to join Managed Microsoft AD through a Shared VPC, you must use gcloud or the Filestore API. You can't join the instance to Managed Microsoft AD using the Google Cloud console.

  • The Managed Microsoft AD domain name must not exceed 56 characters.

What's next