Risolvere i problemi relativi alle condivisioni file NFS di Azure

Si applica a: ✔️ condivisioni file di Azure NFS

Annotazioni

CentOS a cui si fa riferimento in questo articolo è una distribuzione Linux e raggiungerà End Of Life (EOL). Valutare le proprie esigenze e pianificare di conseguenza. Per altre informazioni, vedere Indicazioni sulla fine della vita di CentOS.

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

Importante

Il contenuto di questo articolo si applica solo alle condivisioni NFS. Per risolvere i problemi di SMB in Linux, vedere Risoluzione dei problemi di File di Azure in Linux (SMB). Le condivisioni file NFS Azure non sono supportate per Windows.

Usare lo strumento di diagnostica Always-On

È possibile usare lo strumento AOD (Always-On Diagnostics) per raccogliere i log nei client NFSv4 e SMB Linux. Il daemon viene eseguito in background come servizio di sistema e può essere configurato per rilevare anomalie in varie origini, ad esempio log dmesg, dati di debug, metriche di errore e metriche di latenza. Può acquisire dati da tcpdump, nfsstat, mountstsat e altre origini, insieme all'utilizzo della CPU e della memoria del sistema. Lo strumento è utile per raccogliere informazioni di debug su problemi di campo difficili da riprodurre.

Lo strumento Di diagnostica Always-On è attualmente compatibile con i sistemi che eseguono SUSE Linux Enterprise Server 15 (SLES 15) e Red Hat Enterprise Linux 8 (RHEL 8). Seguire i passaggi di installazione che corrispondono al sistema operativo:

Importante

Always-On Diagnostics non supporta i volumi NFS con la crittografia dei dati in transito abilitata. Per abilitare la raccolta di log nella condivisione NFS interessata, è necessario montare la condivisione senza EiT.

In RHEL 8 seguire queste istruzioni per installare lo strumento Di diagnostica Always-On:

  1. Scaricare il pacchetto di configurazione del repository.

    curl -ssl -O https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
    
  2. Installare il pacchetto di configurazione del repository.

    sudo rpm -i packages-microsoft-prod.rpm
    
  3. Eliminare il pacchetto di configurazione del repository dopo l'installazione e l'aggiornamento dei file di indice del pacchetto.

    rm packages-microsoft-prod.rpm
    sudo dnf update
    
  4. Installare il pacchetto .

    sudo dnf install aod
    

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 disabilitato viene riabilitato dopo aver rilevato un nome di file o directory non valido

Anche se si disabilita l'idmapping, il sistema può riabilitarlo 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 alfanumerico o GID. Per un elenco di caratteri non supportati in File di Azure, vedere Naming and referencing shares, directory, files e metadata. Il due punti è uno dei caratteri non supportati.

Soluzione alternativa

Assicurati di disabilitare l'idmapping e che nulla lo riattivi. Esegui la procedura seguente:

  1. Smontare la condivisione.

  2. Disabilitare l'idmapping eseguendo il comando seguente:

    sudo echo Y > /sys/module/nfs/parameters/nfs4_disable_idmapping
    
  3. Montare nuovamente la condivisione.

  4. Se stai eseguendo rsync, esegui rsync con l'argomento -numeric-ids da una directory che non abbia un nome di directory o di 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

Soluzione

Seguire le istruzioni in Creare una condivisione di file NFS.

Non è possibile connettersi o montare una condivisione file NFS Azure

Causa 1: la richiesta ha origine da un client in una rete non attendibile o da un INDIRIZZO IP non attendibile

A differenza di SMB, NFS non supporta l'autenticazione basata sull'utente. L'autenticazione per una condivisione dipende dalla 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 Azure ExpressRoute. Il firewall dell'account di archiviazione ignora gli indirizzi IP aggiunti all'elenco consenti. Per configurare l'accesso a una condivisione NFS, usare uno dei metodi seguenti:

  • Endpoint del servizio

    • Accesso dall'endpoint pubblico.

    • Disponibile solo nella stessa area.

    • Non è possibile usare il peering di VNet per 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. Usare un endpoint privato perché è più sicuro.

      Il diagramma seguente illustra la connettività usando endpoint pubblici:

      Diagramma della connettività dell'endpoint pubblico.

  • Endpoint privato

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

    • L'accesso alla condivisione NFS tramite collegamento privato è disponibile sia all'interno che all'esterno della regione Azure dell'account di archiviazione (in altre regioni e in locale).

    • Il peering delle reti virtuali con reti ospitate su endpoint privati consente ai client, nelle reti virtuali in peering, di accedere alla condivisione NFS.

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

      Diagramma della connettività dell'endpoint privato.

Causa 2: il pacchetto nfs-utils, nfs-client o nfs-common 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:

Gli stessi comandi in questa sezione si applicano a CentOS e Oracle Linux.

sudo rpm -qa | grep nfs-utils

Soluzione

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

Gli stessi comandi in questa sezione si applicano a CentOS e Oracle Linux.

Versione del sistema operativo 7.X

sudo yum install nfs-utils

Versione del sistema operativo 8.X o 9.X

sudo dnf install nfs-utils

Causa 3: Blocco del firewall della 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 4: 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. Quindi, eliminare e ricreare l'endpoint privato in modo che sia associato al nuovo ID risorsa dell'account di archiviazione.

Causa 5: si sta provando a montare la condivisione usando il montaggio del client NFS anziché l'helper di montaggio AZNFS e l'impostazione Trasferimento sicuro obbligatorio e/o Richiedi crittografia in transito per NFS è abilitata nell'account di archiviazione.

L'impostazione Trasferimento sicuro obbligatorio applica la crittografia in transito per tutte le condivisioni file all'interno dell'account di archiviazione, a meno che l'impostazione Richiedi crittografia in transito per NFS sia abilitata, nel qual caso il trasferimento sicuro richiesto si applica solo al traffico REST/HTTPS. Per le condivisioni file NFS, l'uso della crittografia in transito richiede il montaggio della condivisione tramite l'helper di montaggio AZNFS, un pacchetto di utilità client che astrae la complessità di stabilire tunnel sicuri per il traffico NFSv4.1.

Soluzione

Disabilitare sia l'impostazione Trasferimento sicuro richiesto che l'impostazione Richiedi crittografia in transito per NFS nell'account di archiviazione oppure usare l'helper di montaggio AZNFS per montare la condivisione. Per ulteriori informazioni, vedere Crittografia in transito per condivisioni file di Azure NFS.

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

Causa: è stato introdotto un bug nel kernel Linux v5.11 e 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 inoltrate in una sola chiamata non presentano questo problema. Il bug è stato introdotto nel kernel Linux v5.11 e corretto nella versione 5.12.5. Quindi, qualsiasi versione intermedia presenta il bug. RHEL 8.4 usa questa versione del kernel.

Soluzione alternativa: effettuare il downgrade o aggiornare il kernel

Effettuare il downgrade o aggiornare il kernel a una versione esterna all'intervallo interessato per 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 di inode a 64 bit generati dal servizio NFS.

Soluzione

Per risolvere questo problema, scegliere una delle alternative seguenti:

  • Comprimere i numeri di inode da 64 bit a 32 bit utilizzando 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

Il sistema operativo client applica le autorizzazioni per le condivisioni file NFS, non il servizio File di Azure. Se si abilita l'impostazione Root Squash in una condivisione file NFS, l'utente radice nel sistema client diventa un utente anonimo (senza privilegi) a scopo di controllo di accesso. Questa restrizione 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

Nel 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 il root squash di File di Azure.

Quando si abilita No Root Squash, 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.

Hai bisogno di aiuto?

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

Vedi anche

Dichiarazione di non responsabilità sulle informazioni di terze parti

I prodotti di terze parti illustrati in questo articolo sono prodotti da aziende indipendenti da Microsoft. Microsoft non garantisce, implicitamente o altrimenti, circa le prestazioni o l'affidabilità di questi prodotti.