Problemi noti relativi al supporto del protocollo NFS (NFS) 3.0 per Archiviazione BLOB di Azure

  • Articolo

Questo articolo descrive le limitazioni e i problemi noti del supporto del protocollo NFS (NFS) 3.0 per Archiviazione BLOB di Azure.

Importante

Poiché è necessario abilitare la funzionalità dello spazio dei nomi gerarchico dell'account per usare NFS 3.0, tutti i problemi noti descritti nell'articolo Problemi noti relativi ad Azure Data Lake Storage si applicano anche all'account.

Supporto di NFS 3.0

  • Il supporto di NFS 3.0 non può essere abilitato per gli account di archiviazione esistenti.

  • Il supporto di NFS 3.0 non può essere disabilitato in un account di archiviazione dopo averlo abilitato.

  • Le opzioni di ridondanza geografica e archiviazione con ridondanza geografica della zona e archiviazione con ridondanza geografica e accesso in lettura non sono supportate quando si crea un account di archiviazione NFS 3.0.

  • Gli elenchi di controllo di accesso (ACL) non possono essere usati per autorizzare una richiesta NFS 3.0. Infatti, se l'ACL o un BLOB o una directory contiene una voce per un utente o un gruppo denominato, tale file diventa inaccessibile nel client per gli utenti nonroot. È necessario rimuovere queste voci per ripristinare l'accesso agli utenti nonroot nel client. Per informazioni su come rimuovere una voce ACL per utenti e gruppi denominati, vedere Come impostare gli elenchi di controllo di accesso.

Funzionalità di NFS 3.0

Le funzionalità NFS 3.0 seguenti non sono ancora supportate.

  • NFS 3.0 su UDP. È supportato solo NFS 3.0 su TCP.

  • Blocco dei file con Network Lock Manager (NLM). I comandi di montaggio devono includere il -o nolock parametro .

  • Sottodirectory di montaggio. È possibile montare solo la directory radice (contenitore).

  • Elenco di montaggi (ad esempio: usando il comando showmount -a).

  • Elenco delle esportazioni (ad esempio: usando il comando showmount -e).

  • Collegamento rigido.

  • Esportazione di un contenitore come di sola lettura.

Client NFS 3.0

Il client Windows per NFS non è ancora supportato. Esiste tuttavia una soluzione alternativa che usa il sottosistema Windows per Linux (WSL 2) per montare l'archiviazione usando il protocollo NFS 3.0. Vedere il progetto BlobNFS-wsl2 in GitHub.

Funzionalità di Archiviazione BLOB

Quando si abilita il supporto del protocollo NFS 3.0, alcune funzionalità di archiviazione BLOB sono completamente supportate, ma alcune funzionalità potrebbero essere supportate solo a livello di anteprima o non ancora supportate.

Per informazioni sul supporto di ogni funzionalità di archiviazione BLOB negli account con supporto NFS 3.0 abilitato, vedere Supporto delle funzionalità di archiviazione BLOB per gli account Archiviazione di Azure.

Nota

I siti Web statici sono un esempio di funzionalità parzialmente supportata perché la pagina di configurazione per i siti Web statici non viene ancora visualizzata nella portale di Azure per gli account con supporto NFS 3.0 abilitato. È possibile abilitare i siti Web statici solo usando PowerShell o l'interfaccia della riga di comando di Azure.

Eventi di archiviazione BLOB

I nomi delle operazioni NFS non vengono visualizzati nei log delle risorse o nelle risposte restituite da Griglia di eventi. Vengono visualizzate solo le operazioni BLOB in blocchi. Quando l'applicazione effettua una richiesta usando il protocollo NFS 3.0, tale richiesta viene convertita in combinazione di operazioni BLOB in blocchi. Ad esempio, le richieste di lettura RPC (Remote Procedure Call) di NFS 3.0 vengono convertite nell'operazione Get BLOB. Le richieste di scrittura RPC di NFS 3.0 vengono convertite in una combinazione di Get Block List, Put Blocke Put Block List.

Gli eventi di archiviazione non sono supportati per operazioni specifiche di NFS. Tuttavia, se si eseguono operazioni blob o data lake storage su un account abilitato per NFS, gli eventi verranno creati in base all'API chiamata.

Appartenenza a un gruppo in una condivisione NFS

I file e le directory creati in una condivisione NFS ereditano sempre l'ID gruppo della directory padre, indipendentemente dal fatto che l'opzione Set Group Identification (SGID) sia impostata nella directory padre.

Vedi anche