View a markdown version of this page

Risoluzione dei problemi: problemi di condivisione dei file - AWS Storage Gateway
Condivisione di file bloccata in stato di transizioneNon è possibile creare una condivisione di fileLe condivisioni di file SMB non consentono diversi metodi di accessoLe condivisioni di file multiple non possono scrivere nel bucket S3 mappatoNotifica per il gruppo di log eliminato quando si utilizzano i log di controlloNon riesco a caricare file nel bucket S3Non è possibile modificare la crittografia predefinita in SSE-KMSLe modifiche apportate direttamente in un bucket S3 con il controllo delle versioni degli oggetti attivato possono influire su ciò che vedi nella condivisione dei fileQuando si scrive su un bucket S3 con il controllo delle versioni attivato, Amazon S3 File Gateway può creare più versioni di oggetti Amazon S3Le modifiche a un bucket S3 non si riflettono in Storage GatewayLe autorizzazioni ACL non funzionano come previstoLe prestazioni del gateway sono diminuite dopo un'operazione ricorsiva

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Risoluzione dei problemi: problemi di condivisione dei file

Di seguito è spiegato cosa fare se si verificano problemi imprevisti nella condivisione file.

Condivisione di file bloccata nello stato CREAZIONE, AGGIORNAMENTO o ELIMINAZIONE

Lo stato della condivisione dei file riassume lo stato della condivisione di file. Se la condivisione di file S3 File Gateway è bloccata nello DELETING statoCREATING, oUPDATING, utilizza i seguenti passaggi per la risoluzione dei problemi per identificare e risolvere il problema.

Nota

Quando crei una condivisione di file, Storage Gateway non verifica che il ruolo IAM e il bucket Amazon S3 specificati esistano già. Questo è intenzionale, perché l'assunzione di un ruolo IAM appena creato può richiedere del tempo per essere assunto da Storage Gateway. Di conseguenza, una CreateSMBFileShare richiesta CreateNFSFileShare or che specifica un ruolo o un bucket inesistente ha comunque esito positivo e restituisce un ARN di condivisione di file, ma la condivisione di file rimane nello CREATING stato invece di passare a. AVAILABLE Prima di continuare la risoluzione dei problemi, verifica che esistano sia il ruolo IAM che il bucket Amazon S3 che hai specificato.

Conferma le autorizzazioni del ruolo IAM e la relazione di fiducia

Il ruolo AWS Identity and Access Management (IAM) associato alla condivisione di file deve esistere e deve disporre di autorizzazioni sufficienti per accedere al bucket Amazon S3. Inoltre, la politica di fiducia del ruolo deve concedere al servizio Storage Gateway le autorizzazioni per assumere il ruolo.

Per verificare le autorizzazioni del ruolo IAM:

  1. Aprire la console IAM all'indirizzo https://console.aws.amazon.com/iam/.

  2. Nel riquadro di navigazione, seleziona Ruoli.

  3. Verifica che il ruolo IAM specificato per la condivisione di file sia visualizzato nell'elenco dei ruoli. Se il ruolo non esiste, crealo e quindi crea nuovamente la condivisione dei file. Per ulteriori informazioni, consulta Concessione dell'accesso a un bucket Amazon S3.

  4. Scegli il ruolo IAM associato alla tua condivisione di file.

  5. Seleziona la scheda Relazioni di attendibilità

  6. Verifica che Storage Gateway sia elencato come entità attendibile. Se Storage Gateway non è un'entità attendibile, scegli Modifica relazione di fiducia, quindi aggiungi la seguente politica:

    {
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Service": "storagegateway.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

  7. Verifica che il ruolo IAM disponga delle autorizzazioni corrette e che il bucket Amazon S3 sia elencato come risorsa nella policy IAM. Per ulteriori informazioni, consulta Concessione dell'accesso a un bucket Amazon S3.

Nota

Per evitare problemi di prevenzione della confusione tra diversi servizi, utilizza una policy sulle relazioni di fiducia che includa chiavi di contesto condizionali. Per ulteriori informazioni, consulta Prevenzione del problema "confused deputy" tra servizi.

Verifica AWS STS è attivato nella tua regione

Le condivisioni di file possono rimanere bloccate nello UPDATING stato CREATING or se Servizio di token di sicurezza AWS (AWS STS) è disattivato nella tua AWS regione.

Per verificare AWS Stato STS:

  1. Aprire la AWS Identity and Access Management console all'indirizzo https://console.aws.amazon.com/iam/.

  2. Nel riquadro di navigazione, scegliere Account settings (Impostazioni account).

  3. Nella sezione Security Token Service (STS), verifica che lo stato sia attivo per la AWS regione in cui desideri creare la condivisione di file.

  4. Se lo stato è Inattivo, scegli Attiva per attivarlo AWS STS in quella regione.

Verifica che il bucket S3 esista e segua le regole di denominazione

La tua condivisione di file richiede un bucket Amazon S3 esistente che segua le convenzioni di denominazione di Amazon S3. Storage Gateway non verifica l'esistenza del bucket quando si crea la condivisione di file, quindi una condivisione di file che punta a un bucket eliminato o mai creato rimane nello stato. CREATING

Per verificare il bucket S3:

  1. Apri la console Amazon S3 all'indirizzo. https://console.aws.amazon.com/s3/

  2. Verifica che il bucket Amazon S3 mappato alla tua condivisione di file esista. Se il bucket non esiste, crealo. Dopo aver creato il bucket, lo stato di condivisione dei file dovrebbe cambiare in. AVAILABLE Per ulteriori informazioni, consulta Creazione di un bucket nella Guida per l'utente di Amazon Simple Storage Service.

  3. Verifica che il nome del bucket sia conforme alle regole per la denominazione dei bucket nella Amazon Simple Storage Service User Guide.

    Nota

    S3 File Gateway non supporta i bucket Amazon S3 con punti () nel nome del bucket. .

Forza l'eliminazione di una condivisione di file bloccata nello stato ELIMINAZIONE

Quando elimini una condivisione di file, il gateway rimuove la condivisione dal bucket Amazon S3 associato. Tuttavia, i dati attualmente in fase di caricamento continuano a essere caricati prima del completamento dell'eliminazione. Durante questo processo, la condivisione del file mostra uno stato. DELETING

Importante

Controlla la CloudWatch metrica Amazon del tuo gateway CachePercentDirty per determinare la quantità di dati in attesa di caricamento. Per ulteriori informazioni sulle metriche di Storage Gateway, consulta.

Se non desideri attendere il completamento di tutti i caricamenti in corso, puoi forzare l'eliminazione della condivisione di file.

Per forzare l'eliminazione di una condivisione di file:

  1. Aprire la console Storage Gateway all'indirizzo https://console.aws.amazon.com/storagegateway/.

  2. Nel pannello di navigazione, scegli Condivisioni di file.

  3. Seleziona la condivisione di file che desideri eliminare.

  4. Scegli la scheda Dettagli e rivedi il messaggio Questa condivisione di file viene eliminata.

  5. Verifica l'ID della condivisione di file nel messaggio, quindi seleziona la casella di conferma.

    Nota

    Non puoi annullare l'operazione di eliminazione forzata.

  6. Scegli Elimina forzatamente adesso.

In alternativa, puoi utilizzare il comando AWS CLI delete-file-share con il parametro impostato su. --force-delete true

Importante

Prima di forzare l'eliminazione di una condivisione di file, verificate che il gateway non sia in uno stato. OFFLINE Se il gateway è offline, risolvi innanzitutto il problema offline. Per ulteriori informazioni, consulta Risoluzione dei problemi: gateway offline nella console Storage Gateway.

Se la macchina virtuale (VM) del gateway è già stata eliminata, è necessario eliminare il gateway dalla console Storage Gateway per rimuovere tutte le condivisioni di file associate, comprese quelle bloccate nello DELETING stato. Per ulteriori informazioni, consulta Eliminazione del gateway e rimozione delle risorse associate.

Risolvere i problemi di connettività

I problemi di rete possono impedire la transizione della condivisione di file dallo statoCREATING,UPDATING, orDELETING. I problemi di rete più comuni includono:

  • Il gateway è offline o la VM del gateway è stata eliminata.

  • L'accesso alla rete tra Storage Gateway e l'endpoint del servizio Amazon S3 è bloccato.

  • L'endpoint Amazon S3 Amazon VPC utilizzato dal gateway per comunicare con Amazon S3 è stato eliminato.

  • Le porte di rete richieste non sono aperte o il routing di rete non è configurato correttamente.

Verifica la connettività S3 dalla console locale del gateway

Per testare la connettività S3:

  1. Accedere alla console locale del gateway. Per ulteriori informazioni, consulta Accesso alla console locale di File Gateway.

  2. Nel menu principale di Storage Gateway - Configuration, immettere il numero corrispondente a Test S3 Connectivity.

  3. Scegli il tipo di endpoint Amazon S3:

    • Per il traffico Amazon S3 che fluisce attraverso un endpoint Amazon VPC di Amazon Gateway, NAT Gateway, Transit Gateway o Amazon S3 Gateway Amazon VPC, scegli Public.

    • Per il traffico Amazon S3 che fluisce attraverso un endpoint Amazon VPC con interfaccia Amazon S3, scegli VPC (). PrivateLink

    • Per un endpoint FIPS, scegli l'opzione FIPS.

  4. Inserisci la regione del bucket Amazon S3.

  5. Se utilizzi un endpoint Amazon VPC, inserisci il nome DNS dell'endpoint Amazon S3 Amazon VPC (ad esempio,). vpce-0329c2790456f2d01-0at85l34

Il gateway esegue automaticamente un test di connettività che convalida sia la connessione di rete che la connessione SSL. Se il test fallisce:

  • Errore nel test di rete: in genere causato da regole del firewall, configurazioni dei gruppi di sicurezza o routing di rete non corretto. Verifica che le porte richieste siano aperte e che il routing di rete sia configurato correttamente.

  • Test SSL non riuscito: indica che è in corso un'ispezione SSL o un'ispezione approfondita dei pacchetti tra la macchina virtuale del gateway e gli endpoint del servizio Amazon S3. Disattiva SSL e l'ispezione approfondita dei pacchetti per il traffico di Storage Gateway.

Verifica la configurazione del proxy

Se il gateway utilizza un server proxy, verifica che il proxy non blocchi le comunicazioni di rete.

Per verificare la configurazione del proxy:

  1. Nel menu principale Storage Gateway - Configuration, immettere il numero corrispondente a HTTP/SOCKS Proxy Configuration.

  2. Selezionare l'opzione per visualizzare la configurazione attuale del proxy di rete.

  3. Se è configurato un proxy, verifica che il traffico Amazon S3 possa fluire da Storage Gateway al server proxy tramite la porta 3128 (o la porta listener configurata) e quindi all'endpoint Amazon S3 tramite la porta 443.

  4. Verifica che il proxy o il firewall consenta il traffico da e verso le porte di rete e gli endpoint di servizio richiesti da Storage Gateway. Per ulteriori informazioni, consulta le porte di rete richieste.

Se i problemi persistono, puoi rimuovere temporaneamente la configurazione del proxy per determinare se è il proxy a causare il problema.

Verifica i gruppi di sicurezza e il routing di rete

  • Per i gateway su Amazon EC2: conferma che il gruppo di sicurezza abbia la porta 443 aperta agli endpoint Amazon S3. Verifica che la tabella di routing della sottorete Amazon EC2 indirizzi correttamente il traffico Amazon S3 verso gli endpoint Amazon S3. Per ulteriori informazioni, consulta le porte di rete richieste.

  • Per i gateway locali: verifica che le regole del firewall consentano le porte richieste e che le tabelle di routing locali indirizzino correttamente il traffico di Amazon S3 agli endpoint Amazon S3. Per ulteriori informazioni, consulta le porte di rete richieste.

  • Endpoint VPC: verifica che l'endpoint Amazon S3 Amazon VPC utilizzato dal gateway non sia stato eliminato. Se l'endpoint Amazon VPC viene eliminato e il gateway non ha un indirizzo IP pubblico, il gateway non può comunicare con Amazon S3.

Non puoi creare una condivisione di file

  1. Se non riesci a creare una condivisione di file perché la condivisione di file è bloccata nello stato CREATING, verifica che il bucket S3 a cui hai mappato la condivisione di file esista. Per informazioni su come fare, consulta il paragrafo precedente, Condivisione di file bloccata nello stato CREAZIONE, AGGIORNAMENTO o ELIMINAZIONE.

  2. Se il bucket S3 esiste, verifica che Servizio di token di sicurezza AWS sia attivato nella regione in cui stai creando la condivisione di file. Se un token di sicurezza non è attivo, è necessario attivarlo. Per informazioni su come attivare un token utilizzando Servizio di token di sicurezza AWS, consulta Attivazione e disattivazione di AWS STS in an AWS Region nella IAM User Guide.

Le condivisioni di file SMB non consentono diversi metodi di accesso

Le condivisioni di file SMB hanno le seguenti restrizioni:

  1. Quando lo stesso client tenta di montare sia una condivisione file Active Directory che una condivisione SMB con accesso guest viene visualizzato il seguente messaggio di errore: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

  2. Un utente di Windows non può essere connesso a due condivisioni di file SMB con accesso guest e potrebbe essere disconnesso quando viene stabilita una nuova connessione con accesso guest.

  3. Un client di Windows non è in grado di montare insieme una condivisione file Active Directory e una condivisione SMB con accesso guest esportate dallo stesso gateway.

Le condivisioni di file multiple non possono scrivere nel bucket S3 mappato

Non è consigliabile configurare il bucket S3 per consentire a più condivisioni di file di scrivere in un bucket S3. Tale approccio, infatti, è in grado di determinare risultati imprevisti.

Al contrario, è bene consentire a un'unica condivisione file di scrivere su ciascun bucket S3. Per permettere al solo ruolo associato alla tua condivisione file di scrivere sul bucket, puoi creare una policy del bucket. Per ulteriori informazioni, consulta Best Practices for File Gateway.

Notifica per il gruppo di log eliminato quando si utilizzano i log di controllo

Se il gruppo di log non esiste, l'utente può selezionare il collegamento al gruppo di log sotto quel messaggio per creare un nuovo gruppo di log o utilizzare un gruppo di log esistente da utilizzare come destinazione per i log di controllo

Non riesci a caricare file nel tuo bucket S3

Se non riesci a caricare file nel tuo bucket S3, procedi come segue:

  1. Assicurati di aver concesso l'accesso richiesto ad Amazon S3 File Gateway per caricare i file nel tuo bucket S3. Per ulteriori informazioni, consulta Concessione dell'accesso a un bucket Amazon S3.

  2. Verificare che il ruolo che ha creato il bucket sia autorizzato a scrivere nel bucket S3. Per ulteriori informazioni, consulta Best Practices for File Gateway.

  3. Se File Gateway utilizza SSE-KMS o DSSE-KMS per la crittografia, assicurati che il ruolo IAM associato alla condivisione di file includa le autorizzazioni KMS:Encrypt, KMS:Decrypt, kms: *, kms: e kms:ReEncrypt. GenerateDataKey DescribeKey Per ulteriori informazioni, consulta Using Policies (IAM Policies) for Storage Gateway. Identity-Based

Non è possibile modificare la crittografia predefinita da utilizzare per SSE-KMS crittografare gli oggetti archiviati nel mio bucket S3

Se modifichi la crittografia predefinita e imposti SSE-KMS (crittografia lato server con chiavi AWS KMS gestite) quella predefinita per il bucket S3, gli oggetti con cui Amazon S3 File Gateway memorizza nel bucket non vengono crittografati. SSE-KMS Per impostazione predefinita, un S3 File Gateway utilizza la crittografia lato server gestita con Amazon S3 () quando scrive dati in un bucket S3. SSE-S3 Modificare l'impostazione predefinita non modificherà automaticamente la crittografia.

Per modificare la crittografia da utilizzare SSE-KMS con la tua AWS KMS chiave, devi attivare la crittografia. SSE-KMS A tale scopo, ti basta fornire l'Amazon Resource Name (ARN) della chiave KMS quando crei la condivisione file. Puoi anche aggiornare le impostazioni KMS per la condivisione file utilizzando l'operazione API UpdateNFSFileShare o UpdateSMBFileShare. Questo aggiornamento si applica agli oggetti archiviati nei bucket S3 dopo l'aggiornamento. Per ulteriori informazioni, consulta Crittografia dei dati tramite AWS KMS.

Le modifiche apportate direttamente in un bucket S3 con il controllo delle versioni degli oggetti attivato possono influire su ciò che vedi nella condivisione dei file

Se il bucket S3 contiene oggetti scritti da un altro client, la visualizzazione del bucket S3 potrebbe non essere aggiornata a causa del controllo delle versioni degli oggetti del bucket S3. Prima di esaminare i file d'interesse, occorre aggiornare la cache.

La funzione Versioni multiple degli oggetti è una funzione facoltativa dei bucket S3 che consente di preservare i dati memorizzando più copie di un oggetto con lo stesso nome. A ciascuna copia è assegnato un valore ID univoco, ad esempio file1.jpg: ID="xxx" e file1.jpg: ID="yyy". Il numero di oggetti con lo stesso nome e la loro durata sono controllati dalle policy del ciclo di vita di Amazon S3. Per maggiori dettagli su questi concetti di Amazon S3, consulta Using versioning and Object lifecycle management nella Amazon S3 Developer Guide.

Un oggetto con versione eliminato acquisisce il contrassegno di eliminazione, ma viene conservato. Solo il proprietario del bucket S3 può eliminare definitivamente un oggetto con la funzione Versioni multiple attiva.

Nel tuo S3 File Gateway, i file mostrati sono le versioni più recenti degli oggetti in un bucket S3 nel momento in cui l'oggetto è stato recuperato o la cache è stata aggiornata. I gateway di file S3 ignorano le versioni precedenti o gli oggetti contrassegnati per l'eliminazione. Quando si legge un file, vengono visualizzati i dati della versione più recente. Quando scrivi un file nella tua condivisione di file, S3 File Gateway crea una nuova versione di un oggetto denominato con le tue modifiche e quella versione diventa la versione più recente.

S3 File Gateway continua a leggere la versione precedente e gli aggiornamenti che apporti si basano sulla versione precedente nel caso in cui una nuova versione venga aggiunta al bucket S3 all'esterno dell'applicazione. Per leggere la versione più recente di un oggetto, usa l'azione RefreshCache API o aggiorna dalla console come descritto in. Aggiornamento della cache degli oggetti del bucket Amazon S3

Importante

Non è consigliabile scrivere oggetti o file nel bucket S3 File Gateway S3 dall'esterno della condivisione di file.

Quando si scrive su un bucket S3 con il controllo delle versioni attivato, Amazon S3 File Gateway può creare più versioni di oggetti Amazon S3

Con il controllo delle versioni degli oggetti attivato, potresti avere più versioni di un oggetto creato in Amazon S3 per ogni aggiornamento di un file dal tuo client NFS o SMB. Ecco alcuni scenari che possono comportare la creazione di più versioni di un oggetto nel bucket S3:

  • Quando un file viene modificato in Amazon S3 File Gateway da un client NFS o SMB dopo essere stato caricato su Amazon S3, S3 File Gateway carica i dati nuovi o modificati anziché caricare l'intero file. La modifica del file comporta la creazione di una nuova versione dell'oggetto Amazon S3.

  • Quando un file viene scritto su S3 File Gateway da un client NFS o SMB, S3 File Gateway carica i dati del file su Amazon S3 seguiti dai relativi metadati (proprietà, timestamp, ecc.). Il caricamento dei dati del file crea un oggetto Amazon S3 e il caricamento dei metadati del file aggiorna i metadati dell'oggetto Amazon S3. Questo processo crea un'altra versione dell'oggetto, dando luogo a due versioni di un oggetto.

  • Quando S3 File Gateway carica file di grandi dimensioni, potrebbe essere necessario caricare parti più piccole del file prima che il client termini la scrittura su File Gateway. Alcuni motivi includono la liberazione di spazio nella cache o un'elevata frequenza di scritture su un file. Ciò può comportare più versioni di un oggetto nel bucket S3.

È necessario monitorare il bucket S3 per determinare quante versioni di un oggetto esistono prima di impostare le politiche del ciclo di vita per spostare gli oggetti in diverse classi di archiviazione. È necessario configurare la scadenza del ciclo di vita per le versioni precedenti per ridurre al minimo il numero di versioni disponibili per un oggetto nel bucket S3. L'uso della Same-Region replica (SRR) o della Cross-Region replica (CRR) tra bucket S3 aumenterà lo spazio di archiviazione utilizzato. Per ulteriori informazioni sulla replica, vedere Replica. https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html

Importante

Non configurate la replica tra bucket S3 finché non avete capito quanto spazio di archiviazione viene utilizzato quando il controllo delle versioni degli oggetti è attivato.

L'uso di bucket S3 con versioni può aumentare notevolmente la quantità di storage in Amazon S3 perché ogni modifica a un file crea una nuova versione dell'oggetto S3. Per impostazione predefinita, Amazon S3 continua a memorizzare tutte queste versioni a meno che non si crei specificamente una policy per sovrascrivere questo comportamento e limitare il numero di versioni conservate. Se noti un utilizzo dello storage insolitamente elevato con il controllo delle versioni degli oggetti attivato, verifica di avere le politiche di archiviazione impostate in modo appropriato. L'utilizzo della funzione Versioni multiple degli oggetti può provocare, inoltre, l'incremento del numero di risposte HTTP 503-slow down alle richieste del browser.

Se attivate il controllo delle versioni degli oggetti dopo aver installato un S3 File Gateway, tutti gli oggetti univoci vengono mantenuti (ID=”NULL”) e potete visualizzarli tutti nel file system. Alle nuove versioni degli oggetti viene assegnato un ID univoco (le versioni precedenti vengono comunque conservate). Nel file system NFS viene visualizzata solo l'ultima versione dell'oggetto in base al suo time stamp.

Dopo aver attivato il controllo delle versioni degli oggetti, il bucket S3 non può essere riportato a uno stato senza versione. Tuttavia, si può sospendere la funzione. In seguito alla sospensione, a un nuovo oggetto viene assegnato un ID. In presenza di un oggetto con lo stesso nome e un valore ID=”NULL”, la versione meno recente viene sovrascritta. Eventuali versioni contenenti un ID diverso da NULL, tuttavia, restano disponibili. I time stamp identificano il nuovo oggetto come quello attuale, nonché l'unico da visualizzare nel file system NFS.

Le modifiche a un bucket S3 non si riflettono in Storage Gateway

Storage Gateway aggiorna automaticamente la cache della condivisione dei file quando si scrivono file nella cache localmente utilizzando la condivisione di file. Tuttavia, Storage Gateway non aggiorna automaticamente la cache quando carichi un file direttamente su Amazon S3. Quando si esegue questa operazione, è necessario eseguire un'RefreshCacheoperazione per visualizzare le modifiche sulla condivisione del file. Se si dispone di più di una condivisione di file, è necessario eseguire l'RefreshCacheoperazione su ciascuna condivisione di file.

È possibile aggiornare la cache utilizzando la console Storage Gateway e AWS Command Line Interface (AWS CLI):

  • Per aggiornare la cache utilizzando la console Storage Gateway, consulta Refreshing objects in your Amazon S3 bucket.

  • Per aggiornare la cache utilizzando: AWS CLI

    1. Esegui il comando aws storagegateway list-file-shares

    2. Copia l'Amazon Resource Number (ARN) della condivisione di file con la cache che desideri aggiornare.

    3. Esegui il refresh-cache comando con il tuo ARN come valore per: --file-share-arn

      aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12

Per automatizzare l'RefreshCacheoperazione, vedi Come posso automatizzare l' RefreshCache operazione su Storage Gateway?

Le autorizzazioni ACL non funzionano come previsto

Se le autorizzazioni della lista di controllo accessi (ACL) non funzionano come previsto con la tua condivisione di file SMB, è possibile eseguire un test.

Per eseguire questa operazione, testa prima le autorizzazioni su un server di file di Microsoft Windows o in una condivisione locale di file Windows. Quindi confronta il comportamento con la condivisione di file del gateway.

Le prestazioni del gateway sono diminuite dopo l'esecuzione di un'operazione ricorsiva

In alcuni casi, è possibile eseguire un'operazione ricorsiva, ad esempio rinominare una directory o attivare l'ereditarietà di un ACL, e forzarla nella struttura. In tal caso, S3 File Gateway applica l'operazione in modo ricorsivo a tutti gli oggetti nella condivisione di file.

Ad esempio, supponiamo di applicare l'ereditarietà agli oggetti esistenti in un bucket S3. Il tuo S3 File Gateway applica ricorsivamente l'ereditarietà a tutti gli oggetti nel bucket. Tali operazioni possono provocare il peggioramento delle prestazioni del gateway.