Compartir a través de

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 función de espacio de nombres jerárquico de su cuenta para usar NFS 3.0, todos los problemas conocidos que se describen en el artículo Problemas conocidos con 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 con redundancia de zona geográfica (GZRS) y de almacenamiento de acceso de lectura con redundancia geográfica (RA-GRS) no se admiten al crear una cuenta de almacenamiento NFS 3.0.

  • Las listas de control de acceso (ACL) 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 los usuarios sin privilegios de raíz 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 habilitadas para NFS 3.0 no admiten la copia de seguridad archivada 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 -o nolock.

  • Montaje de subdirectorios. Solo puede montar el directorio raíz (contenedor).

  • Listado de montajes (por ejemplo: mediante el comando showmount -a).

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

  • Vínculo físico.

  • 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 características de Blob Storage para 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 RPC de escritura de NFS 3.0 se convierten 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 primario, independientemente de si se estableciera Configurar identificación de grupo (SGID) en el directorio primario.

Consulte también

  • Last updated on