Oferece suporte a LDAP e Kerberos para autenticação (krb5), verificações de integridade de mensagens (krb5i) e criptografia de dados em trânsito (krb5p).
Oferece suporte a ACL de arquivos NFSv4.1 para o cliente e o servidor.
Cada protocolo é mais adequado para casos de uso específicos. A tabela a seguir compara
as especificações de cada protocolo:
Especificação
NFSv3
NFSv4.1
Níveis de serviço compatíveis
Todos os níveis de serviço
Zonal, regional e empresarial
Comunicação bidirecional
Sim
Não. A comunicação é sempre iniciada pelo cliente usando a porta do servidor 2049.
Suporte a listas de controle de acesso (ACLs) de arquivos ou diretórios
Não
Sim. Suporta até 50 entradas de controle de acesso (ACEs) por lista.
Suporte a grupos
Até 16 grupos
Suporte a grupos ilimitados quando conectado ao Microsoft AD gerenciado.
Configuração de segurança
sys: cria um canal de confiança.
sys: cria um canal de confiança. krb5. Autentica o cliente e o servidor. krb5i. Fornece autenticação e verificações de integridade da mensagem.krb5p. Oferece autenticação, verificações de integridade de mensagens e criptografia de dados em trânsito.
Latência de operações
Nenhum
A latência das operações aumenta com o nível de segurança selecionado.
Tipo de recuperação
Sem estado
Com estado
Tipo de bloqueio de arquivo
Gerenciador de bloqueio de rede (NLM, na sigla em inglês). A fechadura é controlada pelo cliente.
Travamento de aviso com base em contrato de locação. A fechadura é controlada pelo servidor.
O protocolo NFSv3 oferece uma configuração rápida para acesso POSIX padrão.
Limitações do NFSv3
Confira a seguir uma lista de limitações do NFSv3:
Não tem autenticação e criptografia do cliente e do servidor.
Não há processamento de falhas do cliente.
Benefícios do NFSv4.1
O protocolo NFSv4.1 usa o método Autenticação RPCSEC_GSS,
que é implementado usando LDAP
e Kerberos para fornecer autenticação
de cliente e servidor, verificações de integridade de mensagens e criptografia
de dados em trânsito.
Esses recursos de segurança tornam o protocolo NFSv4.1 compatível com os requisitos modernos
de conformidade com a segurança de rede:
Usa uma única porta de servidor, 2049, para todas as comunicações, ajudando a simplificar
as configurações de firewall.
Suporte a listas de controle de acesso (ACLs) de arquivos NFSv4.1.
Cada ACL oferece suporte a até 50 entradas de controle de acesso (ACEs) por arquivo ou
diretório. Isso inclui registros de herança.
Suporte a grupos ilimitados ao usar a integração com o Microsoft AD gerenciado.
Suporte a um melhor processamento de falhas do cliente com bloqueio de aviso baseado em cessão.
O cliente precisa verificar a conexão contínua com o servidor. Se o cliente
não renovar o contrato de arrendamento, o servidor vai liberar a trava e o arquivo vai ficar
disponível para qualquer outro cliente que solicitar acesso por meio de um contrato de arrendamento de trava.
No NFSv3, se um cliente for excluído enquanto estiver bloqueado, o arquivo não poderá ser
acessado por outro cliente, como um novo nó do GKE.
Oferece suporte à recuperação com estado.
Ao contrário do NFSv3, o NFSv4.1 é um protocolo stateful baseado em TCP e em conexões.
O estado do cliente e do servidor na sessão anterior pode ser retomado
após a recuperação.
Serviço gerenciado para Microsoft Active Directory
Automatiza o mapeamento de usuário de identificador exclusivo (UID) e identificador exclusivo global (GUID, na sigla em inglês).
É possível criar ou migrar usuários e grupos para o Microsoft AD gerenciado.
Os administradores podem criar uma confiança de domínio com o domínio local,
autogerenciado, do Active Directory (AD) e do LDAP. Com essa opção,
a migração não é necessária.
Oferece um SLA.
Controle de acesso e outros comportamentos
Os ACEs do Filestore NFSv4.1 são gerenciados no Linux usando os seguintes
comandos:
nfs4_setfacl: cria ou
edita ACEs em um arquivo ou diretório.
nfs4_getfacl: lista os
ACEs em um arquivo ou diretório.
Cada ACL aceita até 50 ACEs. Seis entradas são reservadas para ACEs
gerados automaticamente criados por operações chmod do cliente. Esses ACEs podem ser modificados após a
criação.
Os registros ACE gerados automaticamente que representam os bits de modo são listados na
seguinte ordem de prioridade:
DENY and ALLOW ACEs para o OWNER@
DENY and ALLOW ACEs para o GROUP@
DENY and ALLOW ACEs para EVERYONE@
Se esses ACEs já estiverem presentes, eles serão reutilizados e modificados
de acordo com os novos bits de modo aplicados.
O Filestore NFSv4.1 oferece suporte à verificação do acesso necessário apenas no
modo POSIX RWX (leitura, gravação e execução). Ele não diferencia entre
operações write append e write que modificam o conteúdo ou a especificação
SETATTR. O utilitário nfs4_setfacl também aceita RWX como um atalho e
ativa automaticamente todas as flags adequadas.
O nfs4_getfacl não faz nenhuma tradução do principal por conta própria. O utilitário
nfs4_getfacl mostra o UID numérico e o GUID para os
principais. Como resultado, os principais especiais de OWNER@, GROUP@ e
EVERYONE@ serão mostrados.
Independentemente de usar o Microsoft AD gerenciado, ao trabalhar com
AUTH-SYS e o utilitário nfs4_setfacl, os administradores precisam especificar o
UID numérico e GUID, não os nomes de usuário. Esse utilitário não consegue
converter nomes em valores. Se não for fornecido corretamente, a
instância do Filestore vai usar o ID nobody por padrão.
Ao especificar permissões de gravação para um arquivo ou até mesmo arquivos afetados por
um ACE herdado, o ACE precisa incluir as flags w (gravação) e a (apêndice).
Ao verificar as permissões de SETATTR, a resposta retornada é semelhante a
POSIX da seguinte maneira:
O superusuário ou usuário ROOT pode fazer qualquer coisa.
Somente o proprietário do arquivo pode definir os bits de modo, as ACLs e os carimbos de data/hora para um
horário e grupo específicos, como um dos GUIDs a que ele pertence.
Os usuários que não são proprietários do arquivo podem conferir os atributos, incluindo a ACL.
Uma única ACE inclui permissões eficazes e somente de herança. Ao contrário
de outras implementações do NFSv4.1, o Filestore não vai replicar
automaticamente os ACES herdados para distinguir entre ACEs eficazes
e somente de herança.
Limitações do NFSv4.1
Confira a seguir uma lista de limitações do NFSv4.1:
O protocolo NFSv4.1 não pode ser combinado com os seguintes recursos:
O protocolo NFSv4.1 não oferece suporte a AUDIT and ALARM ACEs. O Filestore
não oferece suporte à auditoria de acesso a dados.
Depois de configurado, não exclua o Microsoft AD gerenciado e o peering de rede.
Isso faz com que o compartilhamento do Filestore fique inacessível enquanto estiver montado
em um cliente, tornando seus dados inacessíveis. Google Cloud não é
responsável por interrupções causadas por ações de administradores ou usuários.
Ao usar qualquer uma das configurações de segurança autenticadas do Kerberos, os usuários podem
esperar alguma latência nas operações. As taxas de latência variam de acordo com o nível de serviço e
a configuração de segurança especificada. A latência aumenta com cada nível de segurança
maior.
Não há suporte para auditoria de acesso a dados.
A solução Filestore NFSv4.1 usa a autenticação RPCSEC_GSS, que é implementada usando LDAP e Kerberos, ambos disponíveis no Microsoft AD gerenciado. O Filestore NFSv4.1 também pode ser usado sem mecanismos de autenticação, semelhante ao NFSv3.
Outros mecanismos de autenticação não são compatíveis.
Se você quiser que uma instância do Filestore participe do Managed Microsoft AD
por uma VPC compartilhada, use gcloud ou a API
do Filestore. Não é possível conectar a instância ao Microsoft AD gerenciado usando o
consoleGoogle Cloud .
O nome de domínio do Microsoft AD gerenciado não pode ter mais de 56 caracteres.
Para criar uma instância empresarial, é necessário executar operações
diretamente pela API Filestore. Para mais informações, consulte
Níveis de serviço.
Ao restaurar um backup, a nova instância precisa usar o mesmo protocolo da
instância de origem.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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)"]]
