Condividi tramite

Risolvere i problemi di connettività e accesso File di Azure (SMB)

  • Articolo

Questo articolo elenca i problemi comuni che possono verificarsi quando si tenta di connettersi e accedere alle condivisioni file di Azure SMB (Server Message Block) da client Windows o Linux. L'articolo descrive anche le possibili cause e risoluzioni per tali problemi.

Note

Questo articolo è stato utile? Diamo importanza al contributo degli utenti. Usare il pulsante Feedback in questa pagina per comunicare se questo articolo è stato utile o come possiamo migliorarlo.

Importante

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

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

Non è possibile connettersi o montare una condivisione file di Azure

Selezionare la scheda Windows o Linux a seconda del sistema operativo client usato per accedere alle condivisioni file di Azure.

Quando si tenta di connettersi a una condivisione file di Azure in Windows, è possibile che vengano visualizzati i messaggi di errore seguenti.

Errore 5 durante il montaggio di una condivisione file di Azure

  • Errore di sistema 5. Accesso negato.

Causa 1: canale di comunicazione non crittografato

Per motivi di sicurezza, le connessioni alle condivisioni file di Azure vengono bloccate se il canale di comunicazione non è crittografato e il tentativo di connessione non viene effettuato dallo stesso data center in cui si trovano tali condivisioni. Se l'impostazione Trasferimento sicuro obbligatorio è abilitata nell'account di archiviazione, anche le connessioni non crittografate all'interno dello stesso data center sono bloccate. Un canale di comunicazione crittografato è disponibile solo se il sistema operativo del client dell'utente finale supporta la crittografia SMB.

Windows 8, Windows Server 2012 e versioni successive di ogni richiesta di negoziazione di sistema che includono SMB 3.x, che supporta la crittografia.

Soluzione per la causa 1

  1. Effettuare la connessione da un client che supporta la crittografia SMB (Windows 8/Windows Server 2012 o versione successiva).
  2. Effettuare la connessione da una macchina virtuale (VM) nello stesso data center dell'account di archiviazione di Azure usato per la condivisione file di Azure.
  3. Se il client non supporta la crittografia SMB, verificare che l'opzione Trasferimento sicuro obbligatorio sia disabilitata nell'account di archiviazione.

Causa 2: nell'account di archiviazione sono abilitate regole di rete virtuale o del firewall

Il traffico di rete è negato se, nell'account di archiviazione, sono configurate regole di rete virtuale (VNET) o del firewall, a meno che all'indirizzo IP o alla rete virtuale client sia consentito l'accesso.

Soluzione per la causa 2

Verificare che le regole di rete virtuale e di firewall siano configurate correttamente nell'account di archiviazione. Per verificare se le regole di rete virtuale o del firewall sono la causa del problema, modificare temporaneamente le impostazioni dell'account di archiviazione per consentire l'accesso da tutte le reti. Per altre informazioni, vedere Configurare i firewall e le reti virtuali di Archiviazione di Azure.

Causa 3: se si usa l'autenticazione basata su identità, le autorizzazioni a livello di condivisione non sono corrette

Se gli utenti accedono alla condivisione file di Azure usando l'autenticazione basata sull'identità, l'accesso alla condivisione file non riesce con l'errore "Accesso negato" se le autorizzazioni a livello di condivisione non sono corrette.

Soluzione per la causa 3

Verificare che le autorizzazioni a livello di condivisione siano configurate correttamente. Vedere Assegnare autorizzazioni a livello di condivisione. Le assegnazioni di autorizzazioni a livello di condivisione sono supportate per i gruppi e gli utenti sincronizzati da Servizi di dominio Active Directory a Microsoft Entra ID usando microsoft Entra Connect Sync o la sincronizzazione cloud Microsoft Entra Connect. Verificare che i gruppi e gli utenti a cui sono assegnate autorizzazioni a livello di condivisione non siano gruppi "solo cloud" non supportati.

Errore 53, Errore 67 o Errore 87 quando si prova a montare o smontare una condivisione file di Azure

Quando si tenta di montare una condivisione file dall'ambiente locale o da un data center diverso, è possibile che vengano visualizzati gli errori seguenti:

  • Errore di sistema 53. Impossibile trovare il percorso di rete.
  • Errore di sistema 67. Impossibile trovare il nome della rete.
  • Errore di sistema 87. Parametro non corretto.

Causa 1: La porta 445 è bloccata

L'errore di sistema 53 o 67 può verificarsi se la comunicazione in uscita dalla porta 445 verso un data center di File di Azure è bloccata. Passare a TechNet per visualizzare un riepilogo degli ISP in grado di consentire o proibire l'accesso dalla porta 445.

È possibile verificare se la porta 445 è bloccata dal firewall o dai vincoli dell'ISP con lo strumento AzFileDiagnostics o il cmdlet Test-NetConnection.

Per usare il cmdlet Test-NetConnection, è necessario installare il modulo Azure PowerShell. Per maggiori informazioni, consultare la sezione Installare il modulo Azure PowerShell. Ricordarsi di sostituire <your-storage-account-name> e <your-resource-group-name> con i nomi pertinenti per il proprio account di archiviazione.

$resourceGroupName = "<your-resource-group-name>"
$storageAccountName = "<your-storage-account-name>"

# This command requires you to be logged into your Azure account and set the subscription your storage account is under, run:
# Connect-AzAccount -SubscriptionId 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'
# if you haven't already logged in.
$storageAccount = Get-AzStorageAccount -ResourceGroupName $resourceGroupName -Name $storageAccountName

# The ComputerName, or host, is <storage-account>.file.core.windows.net for Azure Public Regions.
# $storageAccount.Context.FileEndpoint is used because non-Public Azure regions, such as sovereign clouds
# or Azure Stack deployments, will have different hosts for Azure file shares (and other storage resources).
Test-NetConnection -ComputerName ([System.Uri]::new($storageAccount.Context.FileEndPoint).Host) -Port 445

Se la connessione ha avuto esito positivo, verrà visualizzato l'output seguente:

ComputerName     : <your-storage-account-name>
RemoteAddress    : <storage-account-ip-address>
RemotePort       : 445
InterfaceAlias   : <your-network-interface>
SourceAddress    : <your-ip-address>
TcpTestSucceeded : True

Note

Questo comando restituisce l'indirizzo IP corrente dell'account di archiviazione. Non è garantito che tale indirizzo IP rimanga invariato. Potrebbe cambiare in qualsiasi momento. Non includere l'indirizzo IP come hardcoded in script o nella configurazione di un firewall.

Soluzioni per la causa 1

Soluzione 1: usare Sincronizzazione file di Azure come endpoint QUIC È possibile usare Sincronizzazione file di Azure come soluzione alternativa per accedere alle File di Azure dai client con la porta 445 bloccata. Anche se File di Azure non supporta direttamente SMB su QUIC, Windows Server 2022 Azure Edition supporta il protocollo QUIC. È possibile creare una cache leggera dei file condivisi di Azure su una macchina virtuale Windows Server 2022 Azure Edition utilizzando Sincronizzazione File di Azure. Questa configurazione utilizza la porta 443, ampiamente aperta in uscita per supportare HTTPS, al posto della porta 445. Per saperne di più su questa opzione, vedere SMB su QUIC con Sincronizzazione File di Azure.

Soluzione 2: usare VPN o ExpressRoute Configurando una rete privata virtuale (VPN) o ExpressRoute dall'ambiente locale all'account di archiviazione di Azure, con File di Azure esposto nella rete interna usando endpoint privati, il traffico passa attraverso un tunnel sicuro anziché tramite Internet. Seguire le istruzioni per configurare una VPN per accedere alle File di Azure da Windows.

Soluzione 3: sbloccare la porta 445 con l'aiuto dell'amministratore ISP/IT Collaborare con il reparto IT o l'ISP per aprire la porta 445 in uscita agli intervalli IP di Azure.

Soluzione 4: usare strumenti basati su API REST come Storage Explorer o PowerShell File di Azure supporta anche REST oltre a SMB. L'accesso a REST viene eseguito sulla porta 443, ovvero su TCP standard. Sono disponibili vari strumenti scritti usando l'API REST che consentono un'esperienza avanzata dell'interfaccia utente. Storage Explorer è uno di questi. Scaricare e installare Storage Explorer e connettersi alla condivisione file supportata da File di Azure. È anche possibile usare PowerShell che usa anche l'API REST.

Causa 2: NTLMv1 è abilitato

L'errore di sistema 53 o 87 può verificarsi se sul client è abilitata la comunicazione NTLMv1. File di Azure supporta solo l'autenticazione NTLMv2. Con la comunicazione NTLMv1 abilitata, il client è meno sicuro. Di conseguenza, la comunicazione viene bloccata per File di Azure.

Per determinare se si tratta della causa dell'errore, verificare che la sottochiave del Registro di sistema seguente non sia impostata su un valore minore di 3:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa > LmCompatibilityLevel

Per altre informazioni, vedere l'argomento LmCompatibilityLevel su TechNet.

Soluzione per la causa 2

Ripristinare il valore LmCompatibilityLevel sul valore predefinito 3 nella sottochiave seguente del Registro di sistema:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa

Errore con codice di errore 0x800704b3

Quando si tenta di montare una condivisione file di Azure, viene visualizzato l'errore seguente:

Codice errore: 0x800704b3
Nome simbolico: ERROR_NO_NET_OR_BAD_PATH
Descrizione dell'errore: il percorso di rete è stato digitato in modo non corretto, non esiste o il provider di rete non è attualmente disponibile. Provare a digitare di nuovo il percorso o contattare l'amministratore di rete.

Causa

Questo errore può verificarsi se qualsiasi servizio correlato alla rete Windows principale è disabilitato come qualsiasi servizio che dipende in modo esplicito da tali servizi di rete non verrà avviato.

Soluzione

Controllare se uno dei servizi seguenti si trova in uno stato Arrestato nella macchina virtuale Windows:

  • Connessioni di rete
  • Servizio Elenco reti
  • Riconoscimento presenza in rete
  • Servizio Interfaccia archivio di rete
  • Client DHCP
  • Helper NetBIOS di TCP/IP
  • Workstation

Se sono presenti, avviare i servizi e riprovare a montare la condivisione file di Azure.

L'applicazione o il servizio non può accedere a un'unità File di Azure montata

Causa

Le unità vengono montate per utente. Se l'applicazione o il servizio è in esecuzione con un account utente diverso da quello che ha montato l'unità, l'applicazione non visualizzerà l'unità.

Soluzione

Usare una delle soluzioni seguenti:

  • Montare l'unità dallo stesso account utente che contiene l'applicazione. Si può usare uno strumento come PsExec.

  • Passare il nome e la chiave dell'account di archiviazione nei parametri nome utente e password del net use comando.

  • Usare il cmdkey comando per aggiungere le credenziali in Gestione credenziali. Eseguire questa azione da una riga di comando nel contesto dell'account del servizio tramite un account di accesso interattivo o usando runas.

    cmdkey /add:<storage-account-name>.file.core.windows.net /user:AZURE\<storage-account-name> /pass:<storage-account-key>

  • Mappare direttamente la condivisione, senza usare una lettera di unità mappata. Alcune applicazioni potrebbero non riconnettersi correttamente alla lettera di unità, quindi l'uso del percorso UNC completo potrebbe essere più affidabile:

    net use * \\storage-account-name.file.core.windows.net\share

Dopo aver seguito le istruzioni, è possibile che venga visualizzato il messaggio di errore seguente quando si esegue net use per l'account del servizio di sistema/rete: "Errore di sistema 1312. Una sessione di accesso specificata non esiste. Potrebbe essere già stata terminata." Se viene visualizzato questo errore, assicurarsi che il nome utente passato a net use includa le informazioni sul dominio ( ad esempio: [storage account name].file.core.windows.net).

Nessuna cartella con una lettera di unità in "My Computer" o "This PC"

Se si esegue il mapping di una condivisione file di Azure come amministratore usando il net use comando , la condivisione sembra mancante.

Causa

Per impostazione predefinita, Windows Esplora file non viene eseguito come amministratore. Se si esegue net use da un prompt dei comandi amministrativo, eseguire il mapping dell'unità di rete come amministratore. Poiché le unità mappate sono incentrate sull'utente, l'account utente connesso non visualizza le unità se vengono montate con un account utente diverso.

Soluzione

Montare la condivisione da una riga di comando senza privilegi di amministratore. In alternativa, è possibile seguire questo argomento di TechNet per configurare il valore del EnableLinkedConnections Registro di sistema.

Il comando net use non viene eseguito se l'account di archiviazione contiene una barra

Causa

Il net use comando interpreta una barra (/) come opzione della riga di comando. Se il nome dell'account utente inizia con una barra, il mapping dell'unità ha esito negativo.

Soluzione

Per risolvere il problema, è possibile attenersi a una delle procedure seguenti:

  • Eseguire il comando PowerShell seguente:

    New-SmbMapping -LocalPath y: -RemotePath \\server\share -UserName accountName -Password "password can contain / and \ etc"

    Da un file batch, si può eseguire il comando in questo modo:

    Echo new-smbMapping ... | powershell -command –

  • Racchiudere la chiave tra virgolette doppie, a meno che la barra non sia il primo carattere. Se è il primo carattere, usare la modalità interattiva e immettere la password separatamente oppure rigenerare le chiavi per ottenere una chiave che non inizi con una barra.

Il comando New-PSDrive ha esito negativo e viene visualizzato l'errore "il tipo di risorsa di rete non è corretto"

Causa

Questo messaggio di errore potrebbe essere visualizzato se la condivisione file non è accessibile. Ad esempio, la porta 445 è bloccata o si è verificato un problema di risoluzione DNS.

Soluzione

Assicurarsi che la porta 445 sia aperta e controllare la risoluzione DNS e la connettività alla condivisione file.

Impossibile accedere, modificare o eliminare una condivisione file di Azure (o uno snapshot di condivisione)

Errore "Il nome utente o la password non è corretto" dopo un failover avviato dal cliente

In uno scenario di failover avviato dal cliente con account di archiviazione con ridondanza geografica, gli handle di file e i lease non vengono mantenuti in caso di failover. I client devono smontare e rimontare le condivisioni file.

Errore "Nessun accesso" quando si tenta di accedere o eliminare una condivisione file di Azure

Quando si tenta di accedere o eliminare una condivisione file di Azure usando il portale di Azure, è possibile che venga visualizzato l'errore seguente:

Nessun codice di errore di accesso: 403

Causa 1: Le regole della rete virtuale o del firewall sono abilitate nell'account di archiviazione

Soluzione per la causa 1

Verificare che le regole di rete virtuale e di firewall siano configurate correttamente nell'account di archiviazione. Per verificare se le regole della rete virtuale o del firewall causano il problema, modificare temporaneamente l'impostazione nell'account di archiviazione in Consenti l'accesso da tutte le reti. Per altre informazioni, vedere Configurare i firewall e le reti virtuali di Archiviazione di Azure.

Causa 2: L'account utente non ha accesso all'account di archiviazione

Soluzione per la causa 2

Passare all'account di archiviazione in cui si trova la condivisione file di Azure, selezionare Controllo di accesso (IAM) e verificare che l'account utente abbia accesso all'account di archiviazione. Per altre informazioni, vedere Come proteggere l'account di archiviazione con il controllo degli accessi in base al ruolo di Azure.

Blocchi di file e lease

Se non è possibile modificare o eliminare una condivisione file o uno snapshot di Azure, potrebbe essere dovuto a blocchi di file o lease. File di Azure offre due modi per impedire modifiche o eliminazioni accidentali di condivisioni file di Azure e snapshot di condivisione:

  • Blocchi delle risorse dell'account di archiviazione: tutte le risorse di Azure, incluso l'account di archiviazione, supportano i blocchi delle risorse. I blocchi potrebbero essere inseriti nell'account di archiviazione da un amministratore o da servizi come Backup di Azure. Esistono due varianti di blocchi delle risorse: modificare, che impedisce tutte le modifiche all'account di archiviazione e alle relative risorse ed eliminare, che impedisce solo le eliminazioni dell'account di archiviazione e delle relative risorse. Quando si modificano o si eliminano condivisioni tramite il Microsoft.Storage provider di risorse, i blocchi delle risorse vengono applicati alle condivisioni file di Azure e agli snapshot di condivisione. La maggior parte delle operazioni del portale, i cmdlet di Azure PowerShell per File di Azure con Rm nel nome (ad esempio, Get-AzRmStorageShare) e i comandi dell'interfaccia della share-rm riga di comando di Azure nel gruppo di comandi (ad esempio , az storage share-rm list) usano il Microsoft.Storage provider di risorse. Alcuni strumenti e utilità, ad esempio Storage Explorer, legacy File di Azure cmdlet di gestione di PowerShell senza Rm il nome (ad esempio, Get-AzStorageShare) e i comandi dell'interfaccia della riga di comando legacy File di Azure nel share gruppo di comandi ,ad esempio , az storage share listusano api legacy nell'API FileREST che ignorano il Microsoft.Storage provider di risorse e i blocchi delle risorse. Per altre informazioni sulle API di gestione legacy esposte nell'API FileREST, vedere Piano di controllo in File di Azure.

  • Lease di snapshot di condivisione/condivisione: i lease di condivisione sono un tipo di blocco proprietario per condivisioni file di Azure e snapshot di condivisione file. I lease possono essere inseriti in singole condivisioni file di Azure o snapshot di condivisione file da parte degli amministratori chiamando l'API tramite uno script o tramite servizi a valore aggiunto, ad esempio Backup di Azure. Quando un lease viene inserito in una condivisione file di Azure o in uno snapshot di condivisione file, è possibile modificare o eliminare lo snapshot di condivisione file o condivisione con l'ID lease. Gli amministratori possono anche rilasciare il lease prima delle operazioni di modifica, che richiedono l'ID lease o interrompere il lease, che non richiede l'ID lease. Per altre informazioni sui lease di condivisione, vedere Condivisione di lease.

Poiché i blocchi e i lease delle risorse potrebbero interferire con le operazioni di amministratore previste nell'account di archiviazione o nelle condivisioni file di Azure, è possibile rimuovere eventuali blocchi/lease delle risorse che sono stati inseriti manualmente o automaticamente da servizi a valore aggiunto, ad esempio Backup di Azure. Lo script seguente rimuove tutti i blocchi e i lease delle risorse. Ricordarsi di sostituire <resource-group> e <storage-account> con i valori appropriati per l'ambiente.

Prima di eseguire lo script seguente, è necessario installare la versione più recente del modulo di PowerShell Archiviazione di Azure.

Importante

I servizi a valore aggiunto che accettano blocchi delle risorse e lease di condivisione/condivisione snapshot sulle risorse File di Azure possono riapplicare periodicamente blocchi e lease. La modifica o l'eliminazione di risorse bloccate da servizi a valore aggiunto possono influire sul funzionamento regolare di tali servizi, ad esempio l'eliminazione di snapshot di condivisione gestiti da Backup di Azure.

# Parameters for storage account resource
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
    -ResourceGroupName $resourceGroupName `
    -Name $storageAccountName

# Remove resource locks
Get-AzResourceLock `
        -ResourceType "Microsoft.Storage/storageAccounts" `
        -ResourceGroupName $storageAccount.ResourceGroupName `
        -ResourceName $storageAccount.StorageAccountName | `
    Remove-AzResourceLock -Force | `
    Out-Null

# Remove share and share snapshot leases
Get-AzStorageShare -Context $storageAccount.Context | `
    Where-Object { $_.Name -eq $fileShareName } | `
    ForEach-Object {
        try {
            $leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($_.ShareClient)
            $leaseClient.Break() | Out-Null
        } catch { }
    }

Impossibile modificare, spostare/rinominare o eliminare un file o una directory

Selezionare la scheda Windows o Linux a seconda del sistema operativo client usato per accedere alle condivisioni file di Azure.

In Windows potrebbero essere visualizzati gli errori seguenti.

Handle o lease di file orfani

Uno degli scopi principali di una condivisione file è che più utenti e applicazioni possono interagire contemporaneamente con file e directory nella condivisione. Per facilitare questa interazione, le condivisioni file offrono diversi modi per mediare l'accesso a file e directory.

Quando si apre un file da una condivisione file di Azure montata su SMB, l'applicazione o il sistema operativo richiede un handle di file, ovvero un riferimento al file. Tra le altre cose, l'applicazione specifica una modalità di condivisione file quando richiede un handle di file, che specifica il livello di esclusività dell'accesso al file applicato da File di Azure:

  • None: si ha accesso esclusivo.
  • Read: altri utenti possono leggere il file mentre è aperto.
  • Write: altri utenti possono scrivere nel file mentre è aperto.
  • ReadWrite: combinazione di modalità di Read condivisione e Write .
  • Delete: altri possono eliminare il file mentre è aperto.

Anche se come protocollo senza stato, il protocollo FileREST non ha un concetto di handle di file, fornisce un meccanismo simile per mediare l'accesso a file e cartelle che lo script, l'applicazione o il servizio può usare: lease di file. Quando viene eseguito il lease di un file, viene considerato equivalente a un handle di file con una modalità di condivisione file di None.

Anche se gli handle di file e i lease servono a uno scopo importante, talvolta gli handle di file e i lease potrebbero essere orfani. In questo caso, questo può causare problemi durante la modifica o l'eliminazione di file. Potrebbero essere visualizzati messaggi di errore come:

  • Il processo non può accedere al file perché è in uso da un altro processo.
  • Non è possibile completare l'azione perché il file è aperto in un altro programma.
  • Il documento è bloccato per la modifica da parte di un altro utente.
  • La risorsa specificata è stata contrassegnata per l'eliminazione da un client SMB.

La risoluzione di questo problema dipende dal fatto che ciò sia causato da un handle di file orfano o da un lease.

Note

I lease REST vengono usati dalle applicazioni per impedire l'eliminazione o la modifica dei file. Prima di interrompere eventuali lease, è necessario identificare l'applicazione che li sta acquisendo. In caso contrario, è possibile interrompere il comportamento dell'applicazione.

Causa 1

Un handle di file impedisce la modifica o l'eliminazione di un file o una directory. È possibile usare il cmdlet Di PowerShell Get-AzStorageFileHandle per visualizzare gli handle aperti.

Se tutti i client SMB hanno chiuso gli handle aperti in un file o in una directory e il problema persiste, è possibile forzare la chiusura di un handle di file.

Soluzione 1

Per forzare la chiusura di un handle di file, usare il cmdlet di PowerShell Close-Az Archiviazione FileHandle.

Note

I Get-AzStorageFileHandle cmdlet e Close-AzStorageFileHandle sono inclusi nel modulo Az PowerShell versione 2.4 o successiva. Per installare il modulo Az PowerShell più recente, vedere Installare il modulo Azure PowerShell.

Causa 2

Un lease del file impedisce la modifica o l'eliminazione di un file. È possibile verificare se un file ha un lease di file con i comandi di PowerShell seguenti. Sostituire <resource-group>, <storage-account><file-share>, e <path-to-file> con i valori appropriati per l'ambiente.

# Set variables 
$resourceGroupName = "<resource-group>"
$storageAccountName = "<storage-account>"
$fileShareName = "<file-share>"
$fileForLease = "<path-to-file>"

# Get reference to storage account
$storageAccount = Get-AzStorageAccount `
        -ResourceGroupName $resourceGroupName `
        -Name $storageAccountName

# Get reference to file
$file = Get-AzStorageFile `
        -Context $storageAccount.Context `
        -ShareName $fileShareName `
        -Path $fileForLease

$fileClient = $file.ShareFileClient

# Check if the file has a file lease
$fileClient.GetProperties().Value

Se un file ha un lease, l'oggetto restituito deve contenere le proprietà seguenti:

LeaseDuration         : Infinite
LeaseState            : Leased
LeaseStatus           : Locked

Soluzione 2

Per rimuovere un lease da un file, è possibile rilasciare o interrompere il lease. Per rilasciare il lease, è necessario il valore di LeaseId impostato durante la creazione del lease. Non è necessario il LeaseId per interrompere il lease.

L'esempio seguente illustra come interrompere il lease per il file indicato nella causa 2 (questo esempio continua con le variabili di PowerShell dalla causa 2):

$leaseClient = [Azure.Storage.Files.Shares.Specialized.ShareLeaseClient]::new($fileClient)
$leaseClient.Break() | Out-Null

Non è possibile montare uno snapshot di condivisione file di Azure in Linux

"Errore di montaggio(22): argomento non valido" quando si tenta di montare uno snapshot di condivisione file di Azure in Linux

Causa

Se l'opzione snapshot per il mount comando non viene passata in un formato riconosciuto, il mount comando può non riuscire con questo errore. Per confermarlo, controllare i messaggi di log del kernel (dmesg) e dmesg visualizzerà una voce di log, cifs: Bad value for 'snapshot'ad esempio .

Soluzione

Assicurarsi di passare l'opzione snapshot per il mount comando nel formato corretto. Fare riferimento alla pagina manuale mount.cifs (ad esempio man mount.cifs). Un errore comune è il passaggio del timestamp GMT nel formato errato, ad esempio l'uso di trattini o due punti al posto dei punti. Per altre informazioni, vedere Montare uno snapshot di condivisione file.

"Token snapshot non valido" quando si tenta di montare uno snapshot di condivisione file di Azure in Linux

Causa

Se l'opzione snapshot mount viene passata a partire da @GMT, ma il formato è ancora errato (ad esempio usando trattini e due punti invece di punti), il mount comando può non riuscire con questo errore.

Soluzione

Assicurarsi di passare il timestamp GMT nel formato corretto, ovvero @GMT-year.month.day-hour.minutes.seconds. Per altre informazioni, vedere Montare uno snapshot di condivisione file.

"Errore di montaggio(2): Nessun file o directory di questo tipo" quando si tenta di montare uno snapshot di condivisione file di Azure

Causa

Se lo snapshot che si sta tentando di montare non esiste, il mount comando può non riuscire con questo errore. Per confermarlo, controllare i messaggi di log del kernel (dmesg) e dmesg mostrerà una voce di log, ad esempio:

[Mon Dec 12 10:34:09 2022] CIFS: Attempting to mount \\snapshottestlinux.file.core.windows.net\snapshot-test-share1
[Mon Dec 12 10:34:09 2022] CIFS: VFS: cifs_mount failed w/return code = -2

Soluzione

Assicurarsi che lo snapshot che si sta tentando di montare esista. Per altre informazioni su come elencare gli snapshot disponibili per una determinata condivisione file di Azure, vedere Montare uno snapshot di condivisione file.

Quote disco o errori di rete da troppi handle aperti

Selezionare la scheda Windows o Linux a seconda del sistema operativo client usato per accedere alle condivisioni file di Azure.

Errore 1816 - Quota insufficiente per l'elaborazione di questo comando

Causa

L'errore 1816 si verifica quando si raggiunge il limite massimo di handle aperti simultanei consentiti per un file o una directory nella condivisione file di Azure. Per altre informazioni, vedere Obiettivi di scalabilità per File di Azure.

Soluzione

Chiudere alcuni degli handle aperti simultaneamente per ridurne il numero e quindi riprovare. Per altre informazioni, vedere Elenco di controllo di prestazioni e scalabilità per Archiviazione di Microsoft Azure.

Visualizzare gli handle aperti per una condivisione file, una directory o un file usando il cmdlet di PowerShell Get-AzStorageFileHandle.

Per chiudere gli handle aperti per una condivisione file, una directory o un file, usare il cmdlet di PowerShell Close-AzStorageFileHandle.

Note

I Get-AzStorageFileHandle cmdlet e Close-AzStorageFileHandle sono inclusi nel modulo Az PowerShell versione 2.4 o successiva. Per installare il modulo Az PowerShell più recente, vedere Installare il modulo Azure PowerShell.

ERROR_UNEXP_NET_ERR (59) quando si eseguono operazioni su un handle

Causa

Se si memorizza nella cache un numero elevato di handle aperti per molto tempo, è possibile che venga visualizzato questo errore sul lato server a causa di motivi di limitazione. Quando un numero elevato di handle viene memorizzato nella cache dal client, molti di questi handle possono entrare in una fase di riconnessione contemporaneamente, creando una coda nel server che deve essere limitata. La logica di ripetizione dei tentativi e la limitazione nel back-end per la riconnessione richiede più tempo del timeout del client. Questa situazione si manifesta come un client non è in grado di usare un handle esistente per qualsiasi operazione, con tutte le operazioni che hanno esito negativo con ERROR_UNEXP_NET_ERR (59).

Esistono anche casi perimetrali in cui l'handle client viene disconnesso dal server (ad esempio, un'interruzione della rete che dura diversi minuti) che potrebbe causare questo errore.

Soluzione

Non conservare un numero elevato di handle memorizzati nella cache. Chiudere gli handle e quindi riprovare. Usare Get-AzStorageFileHandle e Close-AzStorageFileHandle i cmdlet di PowerShell per visualizzare/chiudere handle aperti.

Se si usano condivisioni file di Azure per archiviare i contenitori di profili o le immagini del disco per una distribuzione di desktop virtuale su larga scala o altri carichi di lavoro aperti su file, directory e/o directory radice, è possibile raggiungere i limiti di scalabilità superiore per gli handle aperti simultanei. In questo caso, usare una condivisione file di Azure aggiuntiva e distribuire i contenitori o le immagini tra le condivisioni.

Errore "You are copying a file to a destination that does not support encryption" (La destinazione in cui si sta copiando il file non supporta la crittografia)

Quando un file viene copiato tramite la rete, viene decrittografato nel computer di origine, trasmesso in testo non crittografato e crittografato nuovamente nella destinazione. Tuttavia, quando si prova a copiare un file crittografato potrebbe essere visualizzato l'errore seguente: "La destinazione in cui si sta copiando il file non supporta la crittografia."

Causa

Questo problema può verificarsi se si usa EFS (Encrypting File System). I file crittografati con BitLocker possono essere copiati in File di Azure. Tuttavia, File di Azure non supporta NTFS EFS.

Soluzione alternativa

Per copiare un file tramite rete, è necessario prima decrittografarlo. Usa uno dei seguenti metodi:

  • Usare il comando copy /d. Questo consente di salvare i file crittografati come file decrittografati nella destinazione.
  • Impostare la chiave del Registro di sistema seguente:
    • Percorso = HKLM\Software\Policies\Microsoft\Windows\System
    • Tipo valore = DWORD
    • Nome = CopyFileAllowDecryptedRemoteDestination
    • Valore = 1

Si noti che l'impostazione della chiave del Registro di sistema influisce su tutte le operazioni di copia eseguite nelle condivisioni di rete.

Error ConditionHeadersNotSupported da un'applicazione Web usando File di Azure dal browser

L'errore ConditionHeadersNotSupported si verifica quando si accede al contenuto ospitato in File di Azure tramite un'applicazione che usa intestazioni condizionali, ad esempio un Web browser, l'accesso non riesce. L'errore indica che le intestazioni della condizione non sono supportate.

Screenshot che mostra il messaggio di errore ConditionHeadersNotSupported.

Causa

Le intestazioni condizionali non sono ancora supportate. Le applicazioni che le implementano dovranno richiedere il file completo ogni volta che si accede al file.

Soluzione alternativa

Quando viene caricato un nuovo file, la proprietà CacheControl per impostazione predefinita non è cache. Per forzare l'applicazione a richiedere il file ogni volta, la proprietà CacheControl del file deve essere aggiornata da no-cache a no-cache, no-store, must-revalidate. A tale scopo, è possibile usare Archiviazione di Azure Explorer.

Screeshot che mostra la proprietà del file CacheControl.

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.