Risolvere i problemi di File di Azure in Linux (SMB)

  • Articolo

Questo articolo elenca i problemi comuni che possono verificarsi quando si usano condivisioni file di Azure SMB con i client Linux. L'articolo descrive anche le possibili cause e risoluzioni per tali problemi.

È possibile usare AzFileDiagnostics per automatizzare il rilevamento dei sintomi e assicurarsi che il client Linux disponga dei prerequisiti corretti. Aiuta a configurare l'ambiente per ottenere prestazioni ottimali. È anche possibile trovare queste informazioni nello strumento di risoluzione dei problemi delle condivisioni file di Azure.

Importante

Questo articolo si applica solo alle condivisioni SMB. Per informazioni dettagliate sulle condivisioni NFS, vedere Risolvere i problemi relativi alle condivisioni file di Azure NFS.

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

Timestamp persi durante la copia dei file

Nelle piattaforme Linux/Unix il cp -p comando ha esito negativo se diversi utenti possiedono il file 1 e il file 2.

Causa

Il flag f force in COPYFILE comporta l'esecuzione cp -p -f in Unix. Questo comando non riesce anche a mantenere il timestamp del file di cui non si è proprietari.

Soluzione alternativa

Usare l'utente dell'account di archiviazione per copiare i file:

  • str_acc_name=[storage account name]
  • sudo useradd $str_acc_name
  • sudo passwd $str_acc_name
  • su $str_acc_name
  • cp -p filename.txt /share

ls: non è possibile accedere a '<percorso>': errore di input/output

Quando si tenta di elencare i file in una condivisione file di Azure usando il ls comando , il comando si blocca quando si elencano i file. Viene visualizzato l'errore seguente:

ls: cannot access '<percorso>': Input/output error (IS: non è possibile accedere a 'percorso': errore di input/output)

Soluzione

Aggiornare il kernel di Linux a una delle versioni seguenti che includono una correzione per questo problema:

  • 4.4.87+
  • 4.9.48+
  • 4.12.11+
  • Tutte le versioni successive o corrispondenti alla 4.13

Impossibile creare collegamenti simbolici - ln: impossibile creare il collegamento simbolico 't': Operazione non supportata

Causa

Per impostazione predefinita, il montaggio di condivisioni file di Azure in Linux tramite SMB non abilita il supporto per i collegamenti simbolici (collegamenti simbolici). È possibile che venga visualizzato un errore simile al seguente:

sudo ln -s linked -n t

ln: failed to create symbolic link 't': Operation not supported

Soluzione

Il client SMB Linux non supporta la creazione di collegamenti simbolici di tipo Windows tramite il protocollo SMB 2 o 3. Il client Linux supporta attualmente un altro stile di collegamenti simbolici, detto Minshall+French, per le operazioni create e follow. I clienti che necessitano di collegamenti simbolici possono usare l'opzione di montaggio "mfsymlinks". L'uso di "mfsymlinks" è consigliato perché è anche il formato usato dai Mac.

Per usare i collegamenti simbolici, aggiungere quanto segue alla fine del comando di montaggio SMB:

,mfsymlinks

Il comando è quindi simile al seguente:

sudo mount -t cifs //<storage-account-name>.file.core.windows.net/<share-name> <mount-point> -o vers=<smb-version>,username=<storage-account-name>,password=<storage-account-key>,dir_mode=0777,file_mode=0777,serverino,mfsymlinks

È quindi possibile creare i collegamenti simbolici come suggerito nel wiki.

Impossibile accedere a cartelle o file con uno spazio o un punto alla fine

Non è possibile accedere a cartelle o file dalla condivisione file di Azure durante il montaggio in Linux. I comandi come du e ls e/o le applicazioni di terze parti potrebbero non riuscire con un errore "Nessun file o directory di questo tipo" durante l'accesso alla condivisione; Tuttavia, è possibile caricare i file in queste cartelle tramite il portale di Azure.

Causa

Le cartelle o i file sono stati caricati da un sistema che codifica i caratteri alla fine del nome in un carattere diverso. I file caricati da un computer Macintosh possono avere un carattere "0xF028" o "0xF029" anziché 0x20 (spazio) o 0X2E (punto).

Soluzione

Usare l'opzione mapchars nella condivisione durante il montaggio della condivisione in Linux:

Invece di:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino

Usa:

sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars

Problemi di DNS con la migrazione in tempo reale degli account di archiviazione di Azure

L'I/O dei file nel file system montato inizia a dare errori "Host è inattivo" o "Autorizzazione negata". I log dmesg linux nel client mostrano errori ripetuti, ad esempio:

Status code returned 0xc000006d STATUS_LOGON_FAILURE
cifs_setup_session: 2 callbacks suppressed
CIFS VFS: \\contoso.file.core.windows.net Send error in SessSetup = -13

Si noterà anche che il nome di dominio completo del server viene ora risolto in un indirizzo IP diverso da quello a cui è attualmente connesso. Questo problema può verificarsi in qualsiasi scenario in cui l'indirizzo IP del server può cambiare, ad esempio la migrazione dell'account. Un altro scenario noto è il failover dell'account di archiviazione perché il mapping DNS può cambiare.

Causa

A scopo di bilanciamento del carico della capacità, gli account di archiviazione vengono talvolta migrati in tempo reale da un cluster di archiviazione a un altro. La migrazione dell'account attiva File di Azure il traffico da reindirizzare dal cluster di origine al cluster di destinazione aggiornando i mapping DNS in modo che puntino al cluster di destinazione. In questo modo tutto il traffico verso il cluster di origine viene bloccato da tale account. È previsto che il client SMB rilevi gli aggiornamenti DNS e reindirizzi ulteriore traffico al cluster di destinazione. Tuttavia, a causa di un bug nel client kernel SMB Linux, questo reindirizzamento non ha effetto. Di conseguenza, il traffico dei dati continua ad andare verso il cluster di origine, che ha smesso di gestire questo account dopo la migrazione.

Soluzione alternativa

È possibile attenuare questo problema riavviando il sistema operativo client, ma potrebbe verificarsi di nuovo il problema se il sistema operativo client non viene aggiornato a una versione della distribuzione Linux con supporto per la migrazione dell'account.

Mentre smontare e rimontare la condivisione potrebbe sembrare risolvere temporaneamente il problema, non è una soluzione permanente. Quando il client si riconnette al server, il problema potrebbe verificarsi di nuovo. La mitigazione temporanea si verifica perché una nuova azione di montaggio ignora la cache del kernel SMB e risolve l'indirizzo DNS nello spazio utente. Tuttavia, la cache DNS del kernel viene usata durante qualsiasi ripristino di disconnessione di rete, che può causare la ripetizione del problema. Questo comportamento persiste anche all'esterno delle migrazioni degli account di archiviazione.

Per risolvere meglio questo problema, cancellare la cache del resolver DNS del kernel:

  1. Visualizzare lo stato del modulo kernel dns_resolver eseguendo il comando seguente:

    grep '.dns_resolver' /proc/keys

    L'output del comando dovrebbe essere simile all'esempio seguente:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: 1

  2. Cancellare la cache del resolver DNS del kernel eseguendo il comando seguente:

    sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))

  3. Visualizzare di nuovo lo stato del modulo kernel dns_resolver :

    grep '.dns_resolver' /proc/keys

    Verrà visualizzato un output del comando simile all'esempio seguente, a indicare che la cache è ora vuota:

    132b6bbf I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty

  4. Smontare e rimontare la condivisione per attenuare il problema.

Nota

In alcune distribuzioni Linux meno recenti, i passaggi di mitigazione precedenti potrebbero non funzionare. In questi casi, il riavvio del sistema operativo client è l'unica mitigazione nota.

Soluzione

Per una correzione permanente, aggiornare il sistema operativo client a una versione della distribuzione Linux con supporto per la migrazione dell'account. Diverse correzioni per il client kernel SMB Linux sono state inviate al kernel Linux mainline. Le distribuzioni seguenti presentano le correzioni:

  • Ubuntu: 20.04, 22.04, 24.04 e servizio Azure Kubernetes 22.04 (le correzioni sono implementate nella versione del kernel 5.15.0-1068)
  • RHEL: 8.6+
  • SLES: 15SP2, 15SP3, 15SP4 e 15SP5
  • Azure Linux: 2.0 (le correzioni vengono implementate nella versione del kernel 5.15.159.1) e nella versione 3.0

Alcune distribuzioni hanno eseguito il backporting di queste correzioni. È possibile verificare se esistono le correzioni seguenti nella versione della distribuzione in uso:

Impossibile montare la condivisione file SMB quando FIPS è abilitato

Quando fips (Federal Information Processing Standard) è abilitato in una macchina virtuale Linux, la condivisione file SMB non può essere montata. I log dmesg linux nel client visualizzano errori come:

kernel: CIFS: VFS: Could not allocate crypto hmac(md5)
kernel: CIFS: VFS: Error -2 during NTLMSSP authentication
kernel: CIFS: VFS: \\contoso.file.core.windows.net Send error in SessSetup = -2
kernel: CIFS: VFS: cifs_mount failed w/return code = -2

Importante

FIPS è un set di standard usati dal governo degli Stati Uniti per garantire la sicurezza e l'integrità dei sistemi informatici. Quando un sistema è in modalità FIPS, rispetta requisiti crittografici specifici descritti da questi standard.

Causa

Il client della condivisione file SMB usa l'autenticazione NTLMSSP, che richiede l'algoritmo hash MD5. Tuttavia, in modalità FIPS, l'algoritmo MD5 è limitato perché non è conforme a FIPS. MD5 è una funzione hash ampiamente usata che produce un valore hash a 128 bit. Tuttavia, MD5 è considerato non sicuro a scopo di crittografia.

Come verificare se la modalità FIPS è abilitata

Per verificare se la modalità FIPS è abilitata nel client, eseguire il comando seguente. Se il valore è impostato su 1, FIPS viene abilitato.

sudo cat /proc/sys/crypto/fips_enabled

Soluzione

Per risolvere questo problema, abilitare l'autenticazione Kerberos per la condivisione file SMB. Se FIPS è abilitato involontariamente, fare riferimento all'opzione2 per disabilitarla.

Opzione 1: Abilitare l'autenticazione Kerberos per la condivisione file SMB

Per montare una condivisione file SMB nella macchina virtuale Linux in cui è abilitato FIPS, usare l'autenticazione Kerberos/Azure AD. Per altre informazioni, vedere Abilitare l'autenticazione di Active Directory tramite SMB per i client Linux che accedono a File di Azure.

Opzione 2: Disabilitare FIPS per montare la condivisione Samba

  1. Modificare il valore sysctl di crypto.fips_enabled in 0 in /etc/sysctl.conf.

  2. Modificare nel GRUB_CMDLINE_LINUX_DEFAULT /etc/default/grub file e rimuovere il parametro fips=1.

  3. Ricompilare il file di configurazione grub2 con il comando seguente:

    sudo grub2-mkconfig -o /boot/grub2/grub.cfg

  4. Ricompilare l'immagine initramfs con il comando seguente:

    sudo dracut -fv

  5. Riavviare la macchina virtuale.

Per altre informazioni, vedere i documenti seguenti dai server di distribuzione Linux:

Serve aiuto?

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

Vedi anche

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.