Compartir por


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

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

Importante

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

Compatibilidad con NFS 3.0

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

  • La compatibilidad con NFS 3.0 no se puede deshabilitar en una cuenta de almacenamiento después de haberla habilitado.

  • No se admiten opciones de redundancia geográfica (GRS), almacenamiento con redundancia de zona geográfica (GZRS) ni almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS) al crear una cuenta de almacenamiento NFS 3.0.

  • Las listas de control de acceso (ACL) no pueden utilizarse 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 nombrado, ese archivo se vuelve inaccesible en el cliente para los usuarios que no son raíz. Tendrá que eliminar estas entradas para restaurar el acceso a los usuarios no raíz en el cliente. Para obtener información sobre cómo eliminar una entrada ACL para usuarios y grupos con nombre, consulte Cómo configurar ACL.

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). El montaje de comandos debe incluir el parámetro -o nolock.

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

  • Enumeración de los 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 como 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 Subsistema de Windows para Linux (WSL 2) para montar el almacenamiento mediante el protocolo NFS 3.0. Consulte el proyecto BlobNFS-wsl2 en GitHub.

Característica de Blob Storage

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

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

Nota:

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

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.

Los eventos de almacenamiento no se admiten para operaciones específicas de NFS. Sin embargo, si está realizando operaciones de almacenamiento de blobs o lago de datos 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