Risolvere i problemi relativi alle condivisioni file di Azure NFS

Questo articolo elenca i problemi comuni relativi alle condivisioni file di Azure NFS e offre possibili cause e soluzioni alternative.

Si applica a

Tipo di condivisione file	SMB	NFS
Condivisioni file Standard (GPv2), archiviazione con ridondanza locale/archiviazione con ridondanza della zona
Condivisioni file Standard (GPv2), archiviazione con ridondanza geografica/archiviazione con ridondanza geografica della zona
Condivisioni file Premium (FileStorage), archiviazione con ridondanza locale/archiviazione con ridondanza della zona

chgrp "filename" non riuscito: argomento non valido (22)

Causa 1: l'idmapping non è disabilitato

Poiché File di Azure non consente uid/GID alfanumerici, è necessario disabilitare l'idmapping.

Causa 2: l'idmapping è stato disabilitato, ma è stato riabilitato dopo aver rilevato un nome file/dir non valido

Anche se si disabilita correttamente l'idmapping, può essere riabilitato automaticamente in alcuni casi. Ad esempio, quando File di Azure rileva un nome file non valido, viene restituito un errore. Dopo aver visualizzato questo codice di errore, un client Linux NFS 4.1 decide di riabilitare l'idmapping e invia richieste future con UID/GID alfanumerico. Per un elenco di caratteri non supportati in File di Azure, vedere questo articolo. I due punti sono uno dei caratteri non supportati.

Soluzione alternativa

Assicurarsi di aver disabilitato l'idmapping e che non sia stato riabilitandolo. Esegui la procedura seguente:

1. Smontare la condivisione.

2. Disabilitare l'idmapping con:

   sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
   

3. Montare nuovamente la condivisione.

4. Se si esegue rsync, eseguire rsync con l'argomento —numeric-ids da una directory che non ha una directory o un nome file non valido.

Impossibile creare una condivisione NFS

Causa: impostazioni dell'account di archiviazione non supportate

NFS è disponibile solo negli account di archiviazione con la configurazione seguente:

• Livello - Premium
• Tipo account - FileStorage
• Aree - Elenco delle aree supportate

Soluzione

Seguire le istruzioni in Come creare una condivisione NFS.

Non è possibile connettersi o montare una condivisione file di Azure NFS

Causa 1: la richiesta ha origine da un client in una rete non attendibile/ip non attendibile

A differenza di SMB, NFS non dispone dell'autenticazione basata sull'utente. L'autenticazione per una condivisione si basa sulla configurazione della regola di sicurezza di rete. Per garantire che i client stabiliscino solo connessioni sicure alla condivisione NFS, è necessario usare l'endpoint di servizio o gli endpoint privati. Per accedere alle condivisioni da locale oltre agli endpoint privati, è necessario configurare una connessione VPN o ExpressRoute. Gli indirizzi IP aggiunti all'elenco di indirizzi consentiti dell'account di archiviazione per il firewall vengono ignorati. Per configurare l'accesso a una condivisione NFS, è necessario usare uno dei metodi seguenti:

• Endpoint servizio

  • Accesso dall'endpoint pubblico.

  • Disponibile solo nella stessa area.

  • Non è possibile usare il peering reti virtuali per l'accesso alla condivisione.

  • È necessario aggiungere singolarmente ogni rete virtuale o subnet all'elenco consentiti.

  • Per l'accesso locale, è possibile usare gli endpoint di servizio con ExpressRoute, VPN da punto a sito e da sito a sito. È consigliabile usare un endpoint privato perché è più sicuro.

    Il diagramma seguente illustra la connettività usando endpoint pubblici:

    

• Endpoint privato

  • L'accesso è più sicuro dell'endpoint di servizio.

  • L'accesso alla condivisione NFS tramite collegamento privato è disponibile dall'interno e dall'esterno dell'area di Azure dell'account di archiviazione (tra aree locali).

  • Il peering di reti virtuali con reti virtuali ospitate nell'endpoint privato consente alla condivisione NFS di accedere ai client nelle reti virtuali con peering.

  • È possibile usare endpoint privati con ExpressRoute, VPN da punto a sito e VPN da sito a sito.

    

Causa 2: Il trasferimento sicuro obbligatorio è abilitato

Le condivisioni file di Azure NFS non supportano attualmente la doppia crittografia. Azure offre un livello di crittografia per tutti i dati in transito tra i data center di Azure tramite MACSec. È possibile accedere solo alle condivisioni NFS da reti virtuali attendibili e tramite tunnel VPN. Non è disponibile alcuna crittografia aggiuntiva del livello di trasporto nelle condivisioni NFS.

Soluzione

Disabilitare Trasferimento sicuro necessario nel pannello di configurazione dell'account di archiviazione.

Causa 3: nfs-utils, nfs-client o nfs-common package non è installato

Prima di eseguire il mount comando, installare il pacchetto nfs-utils, nfs-client o nfs-common.

Per verificare se il pacchetto NFS è installato, eseguire:

sudo rpm -qa | grep nfs-utils

sudo rpm -qa | grep nfs-client

sudo dpkg -l | grep nfs-common

Soluzione

Se il pacchetto non è installato, installare il pacchetto usando il comando specifico della distribuzione.

sudo yum install nfs-utils

sudo dnf install nfs-utils

sudo zypper install nfs-client

sudo apt update
sudo apt install nfs-common

Causa 4: Firewall che blocca la porta 2049

Il protocollo NFS comunica con il server sulla porta 2049. Assicurarsi che questa porta sia aperta all'account di archiviazione (server NFS).

Soluzione

Verificare che la porta 2049 sia aperta nel client eseguendo il comando seguente. Se la porta non è aperta, aprirla.

sudo nc -zv <storageaccountnamehere>.file.core.windows.net 2049

Causa 5: Account di archiviazione eliminato

Se non è possibile montare la condivisione file a causa di un errore: timeout della connessione, l'account di archiviazione contenente la condivisione file potrebbe essere eliminato accidentalmente.

Soluzione

Ripristinare l'account di archiviazione. Eliminare e ricreare l'endpoint privato in modo che sia associato al nuovo ID risorsa dell'account di archiviazione.

ls si blocca per l'enumerazione di directory di grandi dimensioni in alcuni kernel

Causa: è stato introdotto un bug nel kernel Linux v5.11 ed è stato corretto nella versione 5.12.5

Alcune versioni del kernel presentano un bug che causa l'inserimento di elenchi di directory in una sequenza READDIR infinita. Le piccole directory in cui tutte le voci possono essere spedite in una sola chiamata non presentano questo problema. Il bug è stato introdotto nel kernel Linux v5.11 ed è stato corretto nella versione 5.12.5. Quindi, tutto ciò che c'è tra ha il bug. RHEL 8.4 ha questa versione del kernel.

Soluzione alternativa: effettuare il downgrade o aggiornare il kernel

Il downgrade o l'aggiornamento del kernel a qualsiasi elemento esterno al kernel interessato deve risolvere il problema.

I comandi di sistema hanno esito negativo con l'errore "File non trovato"

Causa

Le applicazioni Linux a 32 bit che si basano su numeri inode potrebbero non funzionare come previsto con File di Azure a causa della formattazione dei numeri inode a 64 bit generati dal servizio NFS.

Soluzione

Per risolvere questo problema, scegliere una delle alternative seguenti:

• Comprimere i numeri di inode a 64 bit a 32 bit usando l'opzione di avvio del nfs.enable_ino64=0 kernel.

• Impostare il parametro module aggiungendo options nfs enable_ino64=0 al file /etc/modprobe.d/nfs.conf e riavviando la macchina virtuale.

È anche possibile rendere persistente questa opzione di avvio del kernel nel file grub.conf . Per altre informazioni, vedere la documentazione per la distribuzione linux.

Impossibile modificare la proprietà dei file e delle directory

Causa

Le autorizzazioni per le condivisioni file NFS vengono applicate dal sistema operativo client anziché dal servizio File di Azure. Se l'impostazione Root Squash è abilitata in una condivisione file NFS, l'utente radice nel sistema client viene considerato un utente anonimo (senza privilegi) a scopo di controllo di accesso. Ciò significa che, anche se si è connessi come radice nel sistema client, non è possibile usare il chown comando per modificare la proprietà dei file e delle directory di cui non si è proprietari.

Soluzione

Nella portale di Azure passare alla condivisione file e selezionare Proprietà. Modificare l'impostazione Root Squash (Squash radice) su No Root Squash (Nessuna squash radice). Per altre informazioni, vedere Configurare lo squash radice per File di Azure.

Con No Root Squash abilitato, l'utente radice nel sistema client ha gli stessi privilegi dell'utente radice nel sistema server. È ora possibile usare chown per modificare la proprietà di qualsiasi file o directory nella condivisione, indipendentemente dal proprietario corrente. Dopo aver apportato le modifiche, è possibile riabilitare Root Squash , se necessario.

Serve aiuto?

Se si necessita ancora di assistenza, contattare il supporto tecnico per ottenere una rapida risoluzione del problema.

Vedi anche

• Risolvere i problemi relativi ad Azure AD
• Risolvere i problemi relativi alle prestazioni di File di Azure
• Risolvere i problemi di connettività File di Azure (SMB)
• Risolvere i problemi di autenticazione e autorizzazione File di Azure (SMB)
• Risolvere File di Azure problemi SMB generali in Linux

Contattaci per ricevere assistenza

In caso di domande o bisogno di assistenza, creare una richiesta di supporto tecnico oppure formula una domanda nel Supporto della community di Azure. È possibile anche inviare un feedback sul prodotto al feedback della community di Azure.