Compartir vía

Problemas conocidos de compatibilidad con el protocolo Network File System (NFS) 3.0 para Azure Blob Storage

En este artículo se describen las limitaciones y los problemas conocidos de compatibilidad con el protocolo Network File System (NFS) 3.0 para Azure Blob Storage.

Importante

Dado que debe habilitar la característica del espacio de nombres jerárquico de su cuenta para usar NFS 3.0, todos los problemas conocidos que se describen en el artículo Known issues with Azure Data Lake Storage también se aplican a su cuenta.

Compatibilidad con NFS 3.0

  • La compatibilidad con NFS 3.0 no se puede habilitar en cuentas de storage existentes.

  • La compatibilidad con NFS 3.0 no se puede deshabilitar en una cuenta de storage después de habilitarla.

  • Geo-Redundant Storage (GRS) solo se admite para escenarios de conmutación por error no planeados y no se admite para la conmutación por error planeada.

  • Las opciones de redundancia de almacenamiento redundante en zona geográfica (GZRS) y almacenamiento con redundancia geográfica de acceso de lectura (RA-GRS) no se admiten al crear una cuenta de almacenamiento NFS 3.0.

  • Las listas de control de acceso (ACLs) no se pueden usar para autorizar una solicitud NFS 3.0. De hecho, si la ACL o un blob o directorio contiene una entrada para un usuario o grupo específico, ese archivo se vuelve inaccesible en el cliente para los usuarios no root. Debe quitar estas entradas para restaurar el acceso a usuarios sin privilegios de root en el cliente. Para obtener información sobre cómo quitar una entrada de ACL para usuarios y grupos con nombre, vea Cómo establecer ACL.

  • Las cuentas que están habilitadas para NFS 3.0 no admiten la copia de seguridad en bóveda de Azure Data Lake Storage.

Características de NFS 3.0

Todavía no se admiten las siguientes características de NFS 3.0.

  • NFS 3.0 a través de UDP. Solo se admite NFS 3.0 a través de TCP.

  • Bloqueo de archivos con Network Lock Manager (NLM). Los comandos de montaje deben incluir el parámetro .

  • Superposición de subdirectorios. Solo puede montar el directorio raíz (contenedor).

  • Por ejemplo, enumeración de los puntos de montaje mediante el comando.

  • Enumeración de las exportaciones (por ejemplo: mediante el comando ).

  • Enlace rígido.

  • Exportación de un contenedor en modo de solo lectura.

Clientes de NFS 3.0

Todavía no se admite el cliente Windows para NFS. Sin embargo, hay una solución alternativa disponible que usa el Windows Subsystem for Linux (WSL 2) para montar storage mediante el protocolo NFS 3.0. Consulte el BlobNFS-wsl2 project en GitHub.

características de Blob Storage

Al habilitar la compatibilidad con el protocolo NFS 3.0, algunas características de Blob Storage son totalmente compatibles, pero es posible que algunas características solo se admitan en el nivel de versión preliminar o aún no se admitan en absoluto.

Para ver cómo se admite cada característica de Blob Storage en las cuentas que tienen habilitada la compatibilidad con NFS 3.0, consulte Compatibilidad de las características de Blob Storage con las cuentas de Azure Storage.

Nota:

Los sitios web estáticos son un ejemplo de una característica admitida parcialmente porque la página de configuración de sitios web estáticos aún no aparece en el Azure portal para las cuentas que tienen habilitada la compatibilidad con NFS 3.0. Solo puede habilitar sitios web estáticos mediante PowerShell o Azure CLI.

eventos de Blob Storage

Los nombres de las operaciones NFS no aparecen en los registros de recursos ni en las respuestas devueltas por Event Grid. Solo aparecen operaciones de blob en bloques. Cuando la aplicación realiza una solicitud mediante el protocolo NFS 3.0, esa solicitud se traduce en una combinación de operaciones de blobs en bloques. Por ejemplo, las solicitudes de llamada a procedimiento remoto (RPC) de lectura NFS 3.0 se traducen en la operación Obtener Blob. Las solicitudes de escritura RPC de NFS 3.0 se transforman en una combinación de Get Block List, Put Block y Put Block List.

Eventos de almacenamiento no son compatibles para operaciones específicas de NFS. Sin embargo, si está realizando operaciones de blob o data lake storage en la cuenta habilitada para NFS, los eventos se crearán en función de la API a la que se llama.

Pertenencia a grupos en un recurso compartido NFS

Los archivos y directorios que cree en un recurso compartido NFS siempre heredarán el identificador de grupo del directorio padre, independientemente de si la Identificación de Grupo (SGID) está establecida en el directorio padre.

Consulte también

  • Last updated on