Share via

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) dai client Windows o Linux. Fornisce anche possibili cause e soluzioni per questi problemi.

Nota

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), LRS/ZRS
Condivisioni file standard (GPv2), GRS/GZRS
Condivisioni file Premium (FileStorage), LRS/ZRS

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 quando si monta una condivisione file di Azure

  • Si è verificato l'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 risiedono le condivisioni file di Azure. Se l'impostazione Trasferimento sicuro obbligatorio è abilitata nell'account di archiviazione, vengono bloccate anche le connessioni non crittografate all'interno dello stesso data center. Un canale di comunicazione crittografato viene fornito solo se il sistema operativo client dell'utente finale supporta la crittografia SMB.

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

Soluzione per la causa 1

  1. Connettersi da un client che supporta la crittografia SMB (Windows 8/Windows Server 2012 o versioni successive).
  2. Connettersi da una macchina virtuale (VM) nello stesso data center dell'account di archiviazione di Azure usato per la condivisione file di Azure.
  3. Verificare che l'impostazione Trasferimento sicuro obbligatorio sia disabilitata nell'account di archiviazione se il client non supporta la crittografia SMB.

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

Il traffico di rete viene negato se le regole della rete virtuale (VNET) e del firewall sono configurate nell'account di archiviazione, a meno che l'indirizzo IP del client o la rete virtuale non sia consentita.

Soluzione per la causa 2

Verificare che le regole della rete virtuale e del firewall siano configurate correttamente nell'account di archiviazione. Per verificare se la rete virtuale o le regole 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 firewall e reti virtuali di Archiviazione di Azure.

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

Se gli utenti accedono alla condivisione file di Azure usando Active Directory (AD) o l'autenticazione Microsoft Entra Domain Services, l'accesso alla condivisione file ha esito negativo con l'errore "Accesso negato" se le autorizzazioni a livello di condivisione non sono corrette.

Soluzione per la causa 3

Verificare che le autorizzazioni siano configurate correttamente:

  • Active Directory Domain Services (AD DS) vedere Assegnare autorizzazioni a livello di condivisione.

    Le assegnazioni di autorizzazioni a livello di condivisione sono supportate per gruppi e utenti sincronizzati da Servizi di dominio Active Directory a Microsoft Entra ID usando Microsoft Entra Connect Sync o Microsoft Entra Connect cloud sync. Verificare che i gruppi e gli utenti a cui vengono assegnate autorizzazioni a livello di condivisione non siano gruppi "solo cloud" non supportati.

  • Microsoft Entra Domain Services vedere Assegnare autorizzazioni a livello di condivisione.

Errore 53, Errore 67 o Errore 87 durante il montaggio o lo smontaggio di una condivisione file di Azure

Quando si tenta di montare una condivisione file dall'ambiente locale o da un data center diverso, potrebbero verificarsi gli errori seguenti:

  • Si è verificato l'errore di sistema 53. Impossibile trovare il percorso di rete.
  • Si è verificato l'errore di sistema 67. Impossibile trovare il nome di rete.
  • Si è verificato l'errore di sistema 87. Parametro non corretto.

Causa 1: la porta 445 è bloccata

L'errore di sistema 53 o l'errore di sistema 67 può verificarsi se la comunicazione in uscita della porta 445 a un data center File di Azure è bloccata. Per visualizzare il riepilogo degli ISP che consentono o non consentono l'accesso dalla porta 445, passare a TechNet.

Per verificare se il firewall o l'ISP blocca la porta 445, usare lo strumento AzFileDiagnostics o il Test-NetConnection cmdlet .

Per usare il Test-NetConnection cmdlet , è necessario installare il modulo Azure PowerShell. Per altre informazioni, vedere Installare Azure PowerShell modulo. Ricordarsi di sostituire <your-storage-account-name> e <your-resource-group-name> con i nomi pertinenti per l'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

Nota

Questo comando restituisce l'indirizzo IP corrente dell'account di archiviazione. Questo indirizzo IP non è garantito per rimanere lo stesso e può cambiare in qualsiasi momento. Non hardcoded questo indirizzo IP in script o in una configurazione del 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 a File di Azure da client con la porta 445 bloccata. Anche se File di Azure non supporta direttamente SMB tramite QUIC, Windows Server 2022 Azure Edition supporta il protocollo QUIC. È possibile creare una cache leggera delle condivisioni file di Azure in una macchina virtuale Windows Server 2022 Azure Edition usando Sincronizzazione file di Azure. Questa configurazione usa la porta 443, che è ampiamente aperta in uscita per supportare HTTPS, anziché la porta 445. Per altre informazioni 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 esposti nella rete interna usando endpoint privati, il traffico passerà attraverso un tunnel sicuro anziché tramite Internet. Seguire le istruzioni per configurare una VPN per accedere a File di Azure da Windows.

Soluzione 3 : sbloccare la porta 445 con l'aiuto dell'amministratore ISP/IT Usare il reparto IT o l'ISP per aprire la porta 445 in uscita negli 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 REST funziona sulla porta 443 (tcp standard). Esistono vari strumenti scritti usando l'API REST che consentono un'esperienza di interfaccia utente avanzata. Storage Explorer è uno di loro. 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 l'errore di sistema 87 può verificarsi se la comunicazione NTLMv1 è abilitata nel client. File di Azure supporta solo l'autenticazione NTLMv2. Se NTLMv1 è abilitato, viene creato un client meno sicuro. Pertanto, la comunicazione è bloccata per File di Azure.

Per determinare se questa è la 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 LmCompatibilityLevel valore predefinito 3 nella sottochiave del Registro di sistema seguente:

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 di 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 oppure il provider di rete non è attualmente disponibile. Provare a ricreare il percorso o contattare l'amministratore di rete.

Causa

Questo errore può verificarsi se i servizi principali correlati alla rete Windows sono disabilitati perché qualsiasi servizio che dipende in modo esplicito da tali servizi di rete non verrà avviato.

Soluzione

Verificare se uno dei servizi seguenti si trovano in uno stato Arrestato nella macchina virtuale Windows:

  • Connexions réseau
  • Servizio elenco di rete
  • Riconoscimento della posizione di rete
  • Servizio di interfaccia dell'archivio di rete
  • DHCP Client
  • TCP/IP NetBIOS Helper
  • Workstation

Se disponibile, avviare il servizio o i servizi e ripetere il montaggio della 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. È possibile 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 Credential Manager. Eseguire questa azione da una riga di comando nel contesto dell'account del servizio, tramite un account di accesso interattivo o tramite runas.

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

  • Eseguire il mapping diretto della 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 queste 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à stato terminato." Se viene visualizzato questo errore, assicurarsi che il nome utente passato a net use includa 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 risulta 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 sono montate con un account utente diverso.

Soluzione

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

Il comando Net Use ha esito negativo se l'account di archiviazione contiene una barra in avanti

Causa

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

Soluzione

È possibile usare uno dei passaggi seguenti per risolvere il problema:

  • Eseguire il comando di PowerShell seguente:

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

    Da un file batch è possibile eseguire il comando in questo modo:

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

  • Inserire virgolette doppie intorno alla chiave per risolvere questo problema, a meno che la barra in avanti non sia il primo carattere. In caso affermativo, usare la modalità interattiva e immettere la password separatamente oppure rigenerare le chiavi per ottenere una chiave che non inizia con una barra in avanti.

New-PSDrive comando non riesce con 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 verifica 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 conservati durante il 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, potrebbe essere 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 della rete virtuale e del firewall siano configurate correttamente nell'account di archiviazione. Per verificare se la rete virtuale o le regole 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 firewall e 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 e lease di file

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 la modifica o l'eliminazione accidentale delle condivisioni file di Azure e degli 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 possono essere inseriti nell'account di archiviazione da un amministratore o da servizi come Backup di Azure. Esistono due varianti di blocchi di risorse: modifica, che impedisce tutte le modifiche all'account di archiviazione e alle relative risorse, ed eliminazione, 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, Azure PowerShell cmdlet 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, i cmdlet di gestione legacy File di Azure PowerShell senza Rm nel nome , ad esempio , Get-AzStorageSharee i comandi legacy File di Azure dell'interfaccia della share riga di comando nel gruppo di comandi ( ad esempio , az storage share list) usano 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 una sorta di blocco proprietario per le condivisioni file di Azure e gli 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 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 nelle risorse 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 PowerShell di Archiviazione di Azure.

Importante

I servizi a valore aggiunto che accettano blocchi di risorse e lease di snapshot di condivisione/condivisione nelle risorse File di Azure possono riapplicare periodicamente blocchi e lease. La modifica o l'eliminazione di risorse bloccate da servizi a valore aggiunto può influire sul normale funzionamento 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 in uso 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/sistema operativo richiede un handle di file, che è 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: l'accesso è esclusivo.
  • Read: altri potrebbero leggere il file mentre è aperto.
  • Write: altri potrebbero scrivere nel file mentre è aperto.
  • ReadWrite: combinazione di entrambe le Read modalità di condivisione e Write .
  • Delete: altri potrebbero 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 possono essere usati dallo script, dall'applicazione o dal servizio: lease di file. Quando un file viene affittato, 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 hanno uno scopo importante, a volte gli handle di file e i lease potrebbero essere orfani. In questo caso, questo può causare problemi nella modifica o nell'eliminazione di file. È possibile che vengano visualizzati messaggi di errore come:

  • Il processo non può accedere al file perché il file viene usato da un altro processo.
  • L'azione non può essere completata perché il file è aperto in un altro programma.
  • Il documento è bloccato per la modifica da un altro utente.
  • La risorsa specificata è 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.

Nota

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/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/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-AzStorageFileHandle .

Nota

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 di 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 il lease o interrompere il lease. Per rilasciare il lease, è necessario il LeaseId del lease, impostato quando si crea il lease. Non è necessario 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 mostrerà una voce di log come cifs: Bad value for 'snapshot'.

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" durante il tentativo 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, l'uso di trattini e due punti anziché 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.

Errori di quota del disco o di rete da un numero eccessivo di handle aperti

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

Errore 1816- Quota insufficiente disponibile per elaborare 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 File di Azure le destinazioni di scalabilità.

Soluzione

Ridurre il numero di handle aperti simultanei chiudendo alcuni handle e quindi riprovando. Per altre informazioni, vedere Archiviazione di Microsoft Azure elenco di controllo per le prestazioni e la scalabilità.

Per visualizzare gli handle aperti per una condivisione file, una directory o un file, usare 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 .

Nota

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 o si conserva un numero elevato di handle aperti per un lungo periodo di tempo, potrebbe verificarsi 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 passare contemporaneamente a una fase di riconnessione, creando una coda nel server che deve essere limitata. La logica di ripetizione dei tentativi e la limitazione delle richieste nel back-end per la riconnessione richiedono più tempo del timeout del client. Questa situazione si manifesta come un client che 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 di rete della durata di diversi minuti) che potrebbe causare questo errore.

Soluzione

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

Se si usano condivisioni file di Azure per archiviare contenitori di profili o immagini del disco per una distribuzione di desktop virtuali su larga scala o altri carichi di lavoro che aprono handle in file, directory e/o directory radice, è possibile raggiungere i limiti di scalabilità superiori 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 "Si sta copiando un file in una destinazione che non supporta la crittografia"

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

Causa

Questo problema può verificarsi se si usa Encrypting File System (EFS). 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 in rete, è prima necessario decrittografarlo. utilizzando uno dei metodi seguenti:

  • Usare il comando copy /d . 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 di valore = DWORD
    • Name = CopyFileAllowDecryptedRemoteDestination
    • Valore = 1

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

Errore ConditionHeadersNotSupported da un'applicazione Web tramite 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 è no-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 Azure Storage Explorer.

Screeshot che mostra la proprietà del file CacheControl.

Vedere 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.