Risolvere i problemi di File di Azure in Linux (SMB)
Questo articolo elenca i problemi comuni che possono verificarsi quando si usano condivisioni file di Azure SMB con client Linux. Fornisce anche possibili cause e soluzioni per questi problemi.
È possibile usare AzFileDiagnostics per automatizzare il rilevamento dei sintomi e assicurarsi che il client Linux disponga dei prerequisiti corretti. Consente di configurare l'ambiente per ottenere prestazioni ottimali. Queste informazioni sono disponibili anche 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), LRS/ZRS | ||
Condivisioni file standard (GPv2), GRS/GZRS | ||
Condivisioni file Premium (FileStorage), LRS/ZRS |
I timestamp sono andati persi durante la copia dei file
Nelle piattaforme Linux/Unix, il cp -p
comando ha esito negativo se utenti diversi possiedono il file 1 e il file 2.
Causa
Il flag f
di forza in COPYFILE comporta l'esecuzione cp -p -f
su 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: impossibile accedere a '<path>': 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: impossibile accedere a '<path>': errore di input/output
Soluzione
Aggiornare il kernel Linux alle versioni seguenti che hanno una correzione per questo problema:
- 4.4.87+
- 4.9.48+
- 4.12.11+
- Tutte le versioni maggiori o uguali a 4.13
Non è possibile creare collegamenti simbolici - ln: non è stato possibile 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). Potrebbe essere 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 in stile Windows tramite il protocollo SMB 2 o 3. Attualmente, il client Linux supporta un altro stile di collegamenti simbolici denominato Minshall+French symlinks per le operazioni di creazione e follow. I clienti che necessitano di collegamenti simbolici possono usare l'opzione di montaggio "mfsymlinks". È consigliabile usare "mfsymlinks" 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 sarà 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 collegamenti simbolici come suggerito nel wiki.
Non è possibile accedere a cartelle o file con un nome 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. Comandi come du e ls e/o 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 quando si monta la condivisione in Linux:
Invece di:
sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino
Utilizzare:
sudo mount -t cifs $smbPath $mntPath -o vers=3.0,username=$storageAccountName,password=$storageAccountKey,serverino,mapchars
Problemi DNS relativi alla migrazione in tempo reale degli account di archiviazione di Azure
Gli I/O di file nel file system montato iniziano a fornire errori "Host inattivo" o "Autorizzazione negata". I log dmesg linux nel client mostrano errori ripetuti come:
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.
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. Ciò blocca tutto il traffico verso il cluster di origine da tale account. Si prevede che il client SMB preleva gli aggiornamenti DNS e reindirizza ulteriore traffico al cluster di destinazione. Tuttavia, a causa di un bug nel client del kernel SMB Linux, questo reindirizzamento non ha effetto. Di conseguenza, il traffico dati continua a passare al 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 è possibile che si verifichi nuovamente il problema se non si aggiorna il sistema operativo client a una versione di distribuzione Linux con il supporto della migrazione dell'account. Si noti che è possibile che umount e rimontaggio della condivisione risolvano temporaneamente il problema.
Per risolvere meglio questo problema, cancellare la cache del resolver DNS del kernel:
Visualizzare lo stato del modulo kernel
dns_resolver
eseguendo il comando seguente:grep '.dns_resolver' /proc/keys
Verrà visualizzato l'output del comando come nell'esempio seguente:
132b6bbf I------ 1 perm 1f030000 0 0 keyring .dns_resolver: 1
Cancellare la cache del resolver DNS del kernel eseguendo il comando seguente:
sudo keyctl clear $((16#$(grep '.dns_resolver' /proc/keys | cut -f1 -d\ ) ))
Visualizzare di nuovo lo stato del modulo kernel
dns_resolver
:grep '.dns_resolver' /proc/keys
Verrà visualizzato l'output del comando come nell'esempio seguente, che indica che la cache è ora vuota:
132b6bbf I------ 1 perm 1f030000 0 0 keyring .dns_resolver: empty
Soluzione
Per una correzione permanente, aggiornare il sistema operativo client a una versione di distribuzione Linux con il supporto per la migrazione dell'account. Diverse correzioni per il client del kernel SMB Linux sono state inviate al kernel Linux della linea principale. Le correzioni sono disponibili per kernel versione 5.15+ e Keyutils-1.6.2+. Alcune distribuzioni hanno eseguito il backporting di queste correzioni ed è possibile verificare se esistono le correzioni seguenti nella versione di distribuzione in uso:
cifs: usare l'output di scadenza di dns_query per pianificare la risoluzione successiva
cifs: impostare un minimo di 120s per la risoluzione DNS successiva
cifs: correzione della perdita di memoria di smb3_fs_context_dup::server_hostname
dns: applicare un TTL predefinito ai record ottenuti da getaddrinfo()
Impossibile montare la condivisione file SMB quando FIPS è abilitato
Quando federal information processing standard (FIPS) è abilitato in una macchina virtuale Linux, la condivisione file SMB non può essere montata. I log dmesg di 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 che il governo degli Stati Uniti usa per garantire la sicurezza e l'integrità dei sistemi informatici. Quando un sistema è in modalità FIPS, rispetta requisiti di crittografia 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 per scopi 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 è 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 inavvertitamente, fare riferimento all'opzione2 per disabilitarlo.
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
Modificare il valore sysctl di
crypto.fips_enabled
su 0 in/etc/sysctl.conf
.Modificare il
GRUB_CMDLINE_LINUX_DEFAULT
nel/etc/default/grub
file e rimuovere il parametrofips=1
.Ricompilare il file di configurazione grub2 con il comando seguente:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
Ricompilare l'immagine initramfs con il comando seguente:
sudo dracut -fv
Riavviare la macchina virtuale.
Per altre informazioni, vedere i documenti seguenti dai distributori Linux:
- RedHat: perché abilitare la modalità FIPS nei montaggi CIFS con interruzione del kernel
- SUSE: il montaggio CIFS ha esito negativo con errore "errore di montaggio(2): nessun file o directory di questo tipo"
Hai bisogno di assistenza?
Se è ancora necessaria assistenza, contattare il supporto tecnico per risolvere rapidamente il problema.
Vedere anche
- Risolvere i problemi di File di Azure
- Risolvere i problemi relativi alle prestazioni 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 generali di NFS in Linux
- Risolvere i problemi di Sincronizzazione file di Azure
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.
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per