View a markdown version of this page

Pemecahan masalah: masalah berbagi file - AWS Storage Gateway
Berbagi file macet dalam keadaan transisiTidak dapat membuat berbagi fileBerbagi file SMB tidak mengizinkan beberapa metode akses yang berbedaBeberapa berbagi file tidak dapat menulis ke bucket S3 yang dipetakanPemberitahuan untuk grup log yang dihapus saat menggunakan log auditTidak dapat mengunggah file ke bucket S3Tidak dapat mengubah enkripsi default ke SSE-KMSPerubahan yang dilakukan langsung di bucket S3 dengan versi objek diaktifkan dapat memengaruhi apa yang Anda lihat di berbagi fileSaat menulis ke bucket S3 dengan versi diaktifkan, Amazon S3 File Gateway dapat membuat beberapa versi objek Amazon S3Perubahan pada bucket S3 tidak tercermin di Storage GatewayIzin ACL tidak berfungsi seperti yang diharapkanKinerja gateway menurun setelah operasi rekursif

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemecahan masalah: masalah berbagi file

Anda dapat menemukan informasi berikut tentang tindakan yang harus diambil jika Anda mengalami masalah tak terduga dengan berbagi file Anda.

Berbagi file macet dalam keadaan MEMBUAT, MEMPERBARUI, atau MENGHAPUS

Status berbagi file merangkum kesehatan berbagi file Anda. Jika berbagi file S3 File Gateway macet diCREATING,UPDATING, atau DELETING status, gunakan langkah pemecahan masalah berikut untuk mengidentifikasi dan menyelesaikan masalah.

Konfirmasikan izin peran IAM dan hubungan kepercayaan

Peran AWS Identity and Access Management (IAM) yang terkait dengan berbagi file Anda harus memiliki izin yang cukup untuk mengakses bucket Amazon S3. Selain itu, kebijakan kepercayaan peran harus memberikan izin layanan Storage Gateway untuk mengambil peran tersebut.

Untuk memverifikasi izin peran IAM:

  1. Buka konsol IAM di https://console.aws.amazon.com/iam/.

  2. Di panel navigasi, pilih Peran.

  3. Pilih peran IAM yang terkait dengan berbagi file Anda.

  4. Pilih tab Trust relationship.

  5. Konfirmasikan bahwa Storage Gateway terdaftar sebagai entitas tepercaya. Jika Storage Gateway bukan entitas tepercaya, pilih Edit hubungan kepercayaan, lalu tambahkan kebijakan berikut:

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

  6. Verifikasi bahwa peran IAM memiliki izin yang benar dan bucket Amazon S3 terdaftar sebagai sumber daya dalam kebijakan IAM. Untuk informasi selengkapnya, lihat Memberikan akses ke bucket Amazon S3.

catatan

Untuk menghindari masalah pencegahan wakil yang membingungkan lintas layanan, gunakan kebijakan hubungan kepercayaan yang mencakup kunci konteks kondisi. Untuk informasi selengkapnya, lihat Pencegahan "confused deputy" lintas layanan.

Verifikasi AWS STS diaktifkan di Wilayah Anda

Berbagi file dapat macet di UPDATING negara bagian CREATING atau jika AWS Security Token Service (AWS STS) dinonaktifkan di AWS Wilayah Anda.

Untuk memverifikasi status AWS STS:

  1. Buka AWS Identity and Access Management konsol di https://console.aws.amazon.com/iam/.

  2. Di panel navigasi, pilih Pengaturan akun.

  3. Di bagian Security Token Service (STS), verifikasi bahwa Status Aktif untuk AWS Wilayah tempat Anda ingin membuat berbagi file.

  4. Jika statusnya Tidak Aktif, pilih Aktifkan untuk mengaktifkan AWS STS di Wilayah tersebut.

Verifikasi bucket S3 ada dan ikuti aturan penamaan

Berbagi file Anda memerlukan bucket Amazon S3 yang valid yang mengikuti konvensi penamaan Amazon S3.

Untuk memverifikasi bucket S3 Anda:

  1. Buka konsol Amazon S3 di. https://console.aws.amazon.com/s3/

  2. Konfirmasikan bahwa bucket Amazon S3 yang dipetakan ke berbagi file Anda sudah ada. Jika ember tidak ada, buatlah. Setelah Anda membuat bucket, status berbagi file akan berubah menjadiAVAILABLE. Untuk informasi selengkapnya, lihat Membuat bucket di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

  3. Pastikan nama bucket Anda mematuhi aturan penamaan bucket di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

    catatan

    S3 File Gateway tidak mendukung bucket Amazon S3 dengan period . () dalam nama bucket.

Hapus paksa file share yang macet dalam status DELETING

Saat Anda menghapus file share, gateway akan menghapus share dari bucket Amazon S3 terkait. Namun, data yang saat ini diunggah terus diunggah sebelum penghapusan selesai. Selama proses ini, berbagi file menunjukkan DELETING status.

penting

Periksa CloudWatch metrik Amazon CachePercentDirty untuk gateway Anda untuk menentukan berapa banyak data yang tertunda upload. Untuk informasi selengkapnya tentang metrik Storage Gateway, lihatMemantau Gateway File Gateway S3 Anda.

Jika Anda tidak ingin menunggu semua unggahan yang sedang berlangsung selesai, Anda dapat menghapus file share secara paksa.

Untuk menghapus paksa berbagi file:

  1. Buka konsol Storage Gateway di https://console.aws.amazon.com/storagegateway/.

  2. Di panel navigasi, pilih Berbagi file.

  3. Pilih file share yang ingin Anda hapus.

  4. Pilih tab Detail, dan tinjau pesan Berbagi file ini sedang dihapus.

  5. Verifikasi ID berbagi file dalam pesan, lalu pilih kotak konfirmasi.

    catatan

    Anda tidak dapat membatalkan operasi penghapusan paksa.

  6. Pilih Paksa hapus sekarang.

Atau, Anda dapat menggunakan AWS CLI delete-file-shareperintah dengan --force-delete parameter yang disetel ketrue.

penting

Sebelum menghapus file share secara paksa, konfirmasikan bahwa gateway Anda tidak dalam OFFLINE status. Jika gateway sedang offline, pertama-tama selesaikan masalah offline. Untuk informasi selengkapnya, lihat Pemecahan masalah: gateway offline di konsol Storage Gateway.

Jika gateway virtual machine (VM) sudah dihapus, Anda harus menghapus gateway dari konsol Storage Gateway untuk menghapus semua berbagi file terkait, termasuk yang terjebak dalam DELETING status. Untuk informasi selengkapnya, lihat Menghapus gateway Anda dan menghapus sumber daya terkait.

Memecahkan masalah konektivitas jaringan

Masalah jaringan dapat mencegah berbagi file Anda dari transisi keluar dariCREATING,UPDATING, atau DELETING status. Masalah jaringan umum meliputi:

  • Gateway Anda sedang offline atau gateway VM dihapus.

  • Akses jaringan antara Storage Gateway dan endpoint layanan Amazon S3 diblokir.

  • Titik akhir Amazon S3 Amazon VPC yang digunakan gateway untuk berkomunikasi dengan Amazon S3 telah dihapus.

  • Port jaringan yang diperlukan tidak terbuka atau perutean jaringan tidak dikonfigurasi dengan benar.

Uji konektivitas S3 dari konsol lokal gateway

Untuk menguji konektivitas S3:

  1. Masuk ke konsol lokal gateway Anda. Untuk informasi selengkapnya, lihat Masuk ke konsol lokal File Gateway.

  2. Di menu utama Storage Gateway - Configuration, masukkan nomor yang sesuai dengan Test S3 Connectivity.

  3. Pilih jenis endpoint Amazon S3:

    • Untuk lalu lintas Amazon S3 yang mengalir melalui Gateway Internet, Gateway NAT, Gateway Transit, atau titik akhir Amazon S3 Gateway Amazon VPC, pilih Publik.

    • Untuk lalu lintas Amazon S3 yang mengalir melalui antarmuka Amazon S3 titik akhir Amazon VPC, pilih VPC (). PrivateLink

    • Untuk titik akhir FIPS, pilih opsi FIPS.

  4. Masuk ke Wilayah bucket Amazon S3.

  5. Jika menggunakan titik akhir Amazon VPC, masukkan nama DNS titik akhir Amazon S3 Amazon VPC (misalnya,). vpce-0329c2790456f2d01-0at85l34

Gateway secara otomatis melakukan tes konektivitas yang memvalidasi koneksi jaringan dan koneksi SSL. Jika tes gagal:

  • Kegagalan Uji Jaringan - Biasanya disebabkan oleh aturan firewall, konfigurasi grup keamanan, atau perutean jaringan yang tidak tepat. Verifikasi bahwa port yang diperlukan terbuka dan perutean jaringan dikonfigurasi dengan benar.

  • Kegagalan Uji SSL - Menunjukkan bahwa inspeksi SSL atau inspeksi paket mendalam terjadi antara titik akhir layanan VM gateway dan Amazon S3 Anda. Nonaktifkan SSL dan inspeksi paket mendalam untuk lalu lintas Storage Gateway.

Verifikasi konfigurasi proxy

Jika gateway Anda menggunakan server proxy, verifikasi bahwa proxy tidak memblokir komunikasi jaringan.

Untuk memeriksa konfigurasi proxy:

  1. Di menu utama Storage Gateway - Configuration, masukkan nomor yang sesuai dengan HTTP/SOCKS Proxy Configuration.

  2. Pilih opsi untuk melihat konfigurasi proxy jaringan saat ini.

  3. Jika proxy dikonfigurasi, verifikasi bahwa lalu lintas Amazon S3 dapat mengalir dari Storage Gateway ke server proxy melalui port 3128 (atau port listener yang dikonfigurasi), lalu ke endpoint Amazon S3 melalui port 443.

  4. Konfirmasikan bahwa proxy atau firewall memungkinkan lalu lintas ke dan dari port jaringan dan titik akhir layanan yang diperlukan oleh Storage Gateway. Untuk informasi selengkapnya, lihat port jaringan yang diperlukan.

Jika masalah berlanjut, Anda dapat menghapus sementara konfigurasi proxy untuk menentukan apakah proxy menyebabkan masalah.

Verifikasi grup keamanan dan perutean jaringan

  • Untuk gateway di Amazon EC2 - Konfirmasikan bahwa grup keamanan memiliki port 443 terbuka ke titik akhir Amazon S3. Verifikasi bahwa tabel rute subnet Amazon EC2 dengan benar merutekan lalu lintas Amazon S3 ke titik akhir Amazon S3. Untuk informasi selengkapnya, lihat port jaringan yang diperlukan.

  • Untuk gateway lokal - Konfirmasikan bahwa aturan firewall mengizinkan port yang diperlukan dan tabel rute lokal merutekan lalu lintas Amazon S3 dengan benar ke titik akhir Amazon S3. Untuk informasi selengkapnya, lihat port jaringan yang diperlukan.

  • Titik akhir VPC - Verifikasi bahwa titik akhir VPC Amazon S3 Amazon yang digunakan oleh gateway belum dihapus. Jika titik akhir VPC Amazon dihapus dan gateway tidak memiliki alamat IP publik, gateway tidak dapat berkomunikasi dengan Amazon S3.

Anda tidak dapat membuat berbagi file

  1. Jika Anda tidak dapat membuat berbagi file karena berbagi file macet dalam status CREATING, verifikasi bahwa bucket S3 tempat Anda memetakan file share sudah ada. Untuk informasi tentang cara melakukannya, lihatBerbagi file macet dalam keadaan MEMBUAT, MEMPERBARUI, atau MENGHAPUS, sebelumnya.

  2. Jika bucket S3 ada, maka verifikasi yang AWS Security Token Service diaktifkan di wilayah tempat Anda membuat file share. Jika token keamanan tidak aktif, Anda harus mengaktifkannya. Untuk informasi tentang cara mengaktifkan token menggunakan AWS Security Token Service, lihat Mengaktifkan dan menonaktifkan AWS STS di AWS Wilayah dalam Panduan Pengguna IAM.

Berbagi file SMB tidak mengizinkan beberapa metode akses yang berbeda

Berbagi file SMB memiliki batasan sebagai berikut:

  1. Ketika klien yang sama mencoba memasang file SMB Active Directory dan akses Tamu, pesan kesalahan berikut akan ditampilkan: 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. Pengguna Windows tidak dapat tetap terhubung ke dua berbagi file SMB Akses Tamu, dan mungkin terputus saat koneksi Akses Tamu baru dibuat.

  3. Klien Windows tidak dapat memasang akses tamu dan berbagi file SMB Direktori Aktif yang diekspor oleh gateway yang sama.

Beberapa berbagi file tidak dapat menulis ke bucket S3 yang dipetakan

Kami tidak menyarankan mengonfigurasi bucket S3 Anda untuk memungkinkan beberapa pembagian file ditulis ke satu bucket S3. Pendekatan ini dapat menyebabkan hasil yang tidak terduga.

Sebagai gantinya, kami menyarankan Anda hanya mengizinkan satu file share untuk menulis ke setiap bucket S3. Anda membuat kebijakan bucket untuk mengizinkan hanya peran yang terkait dengan berbagi file Anda untuk menulis ke bucket. Untuk informasi selengkapnya, lihat Praktik Terbaik untuk Gateway File.

Pemberitahuan untuk grup log yang dihapus saat menggunakan log audit

Jika grup log tidak ada, pengguna dapat memilih tautan grup log di bawah pesan tersebut untuk membuat grup log baru atau menggunakan grup log yang ada untuk digunakan sebagai target log audit

Tidak dapat mengunggah file ke bucket S3 Anda

Jika Anda tidak dapat mengunggah file ke bucket S3, lakukan hal berikut:

  1. Pastikan Anda telah memberikan akses yang diperlukan untuk Amazon S3 File Gateway untuk mengunggah file ke bucket S3 Anda. Untuk informasi selengkapnya, lihat Memberikan akses ke bucket Amazon S3.

  2. Pastikan peran yang membuat bucket memiliki izin untuk menulis ke bucket S3. Untuk informasi selengkapnya, lihat Praktik Terbaik untuk Gateway File.

  3. Jika File Gateway Anda menggunakan SSE-KMS atau DSSE-KMS untuk enkripsi, pastikan peran IAM yang terkait dengan berbagi file mencakup izin KMS:Encrypt, KMS:Decrypt, kms: *, kms:, dan kms:. ReEncrypt GenerateDataKey DescribeKey Untuk informasi selengkapnya, lihat Menggunakan Kebijakan Berbasis Identitas (Kebijakan IAM) untuk Storage Gateway.

Tidak dapat mengubah enkripsi default untuk menggunakan SSE-KMS untuk mengenkripsi objek yang disimpan di bucket S3 saya

Jika Anda mengubah enkripsi default dan menjadikan SSE-KMS (enkripsi sisi server dengan kunci yang AWS KMS dikelola) sebagai default untuk bucket S3, objek yang disimpan oleh Amazon S3 File Gateway dalam bucket tidak dienkripsi dengan SSE-KMS. Secara default, Gateway File S3 menggunakan enkripsi sisi server yang dikelola dengan Amazon S3 (SSE-S3) saat menulis data ke bucket S3. Mengubah default tidak akan secara otomatis mengubah enkripsi Anda.

Untuk mengubah enkripsi untuk menggunakan SSE-KMS dengan AWS KMS kunci Anda sendiri, Anda harus mengaktifkan enkripsi SSE-KMS. Untuk melakukannya, Anda memberikan Nama Sumber Daya Amazon (ARN) dari kunci KMS saat Anda membuat berbagi file. Anda juga dapat memperbarui pengaturan KMS untuk berbagi file Anda dengan menggunakan operasi UpdateNFSFileShare atau UpdateSMBFileShare API. Pembaruan ini berlaku untuk objek yang disimpan dalam bucket S3 setelah pembaruan. Untuk informasi selengkapnya, lihat Enkripsi data menggunakan AWS KMS.

Perubahan yang dilakukan langsung di bucket S3 dengan versi objek diaktifkan dapat memengaruhi apa yang Anda lihat di berbagi file

Jika bucket S3 Anda memiliki objek yang ditulis oleh klien lain, tampilan bucket S3 Anda mungkin bukan up-to-date karena pembuatan versi objek bucket S3. Anda harus selalu menyegarkan cache Anda sebelum memeriksa file yang menarik.

Pembuatan versi objek adalah fitur bucket S3 opsional yang membantu melindungi data dengan menyimpan banyak salinan objek dengan nama yang sama. Setiap salinan memiliki nilai ID terpisah, misalnyafile1.jpg: ID="xxx" danfile1.jpg:ID="yyy". Jumlah objek yang diberi nama identik dan masa pakainya dikendalikan oleh kebijakan siklus hidup Amazon S3. Untuk detail selengkapnya tentang konsep Amazon S3 ini, lihat Menggunakan pembuatan versi dan manajemen siklus hidup Objek di Panduan Pengembang Amazon S3.

Saat Anda menghapus objek berversi, objek tersebut ditandai dengan penanda hapus tetapi dipertahankan. Hanya pemilik bucket S3 yang dapat menghapus objek secara permanen dengan versi diaktifkan.

Di S3 File Gateway Anda, file yang ditampilkan adalah versi terbaru dari objek dalam bucket S3 pada saat objek diambil atau cache di-refresh. S3 File Gateways mengabaikan versi lama atau objek apa pun yang ditandai untuk dihapus. Saat membaca file, Anda membaca data dari versi terbaru. Saat Anda menulis file di berbagi file, Gateway File S3 Anda membuat versi baru dari objek bernama dengan perubahan Anda, dan versi itu menjadi versi terbaru.

Gateway File S3 Anda terus membaca dari versi sebelumnya, dan pembaruan yang Anda buat didasarkan pada versi sebelumnya jika versi baru ditambahkan ke bucket S3 di luar aplikasi Anda. Untuk membaca versi terbaru objek, gunakan tindakan RefreshCacheAPI atau refresh dari konsol seperti yang dijelaskan dalamMenyegarkan cache objek bucket Amazon S3.

penting

Kami tidak menyarankan objek atau file ditulis ke bucket S3 File Gateway S3 Anda dari luar berbagi file.

Saat menulis ke bucket S3 dengan versi diaktifkan, Amazon S3 File Gateway dapat membuat beberapa versi objek Amazon S3

Dengan versi objek diaktifkan, Anda mungkin memiliki beberapa versi objek yang dibuat di Amazon S3 pada setiap pembaruan ke file dari klien NFS atau SMB Anda. Berikut adalah skenario yang dapat menghasilkan beberapa versi objek yang dibuat di bucket S3 Anda:

  • Saat file dimodifikasi di Amazon S3 File Gateway oleh klien NFS atau SMB setelah diunggah ke Amazon S3, Gateway File S3 mengunggah data baru atau yang dimodifikasi alih-alih mengunggah seluruh file. Modifikasi file menghasilkan versi baru objek Amazon S3 yang sedang dibuat.

  • Saat file ditulis ke Gateway File S3 oleh klien NFS atau SMB, Gateway File S3 mengunggah data file ke Amazon S3 diikuti oleh metadatanya, (kepemilikan, cap waktu, dll.). Mengunggah data file akan membuat objek Amazon S3, dan mengunggah metadata untuk file akan memperbarui metadata untuk objek Amazon S3. Proses ini menciptakan versi lain dari objek, menghasilkan dua versi objek.

  • Saat S3 File Gateway mengunggah file yang lebih besar, mungkin perlu mengunggah potongan file yang lebih kecil sebelum klien selesai menulis ke File Gateway. Beberapa alasan untuk ini termasuk untuk membebaskan ruang cache atau tingkat penulisan yang tinggi ke file. Ini dapat menghasilkan beberapa versi objek di bucket S3.

Anda harus memantau bucket S3 untuk menentukan berapa banyak versi objek yang ada sebelum menyiapkan kebijakan siklus hidup untuk memindahkan objek ke kelas penyimpanan yang berbeda. Anda harus mengonfigurasi kedaluwarsa siklus hidup untuk versi sebelumnya untuk meminimalkan jumlah versi yang Anda miliki untuk objek di bucket S3 Anda. Penggunaan replikasi Same-Region (SRR) atau replikasi Cross-Region (CRR) antara bucket S3 akan meningkatkan penyimpanan yang digunakan. Untuk informasi lebih lanjut tentang replikasi, lihat Replikasi.

penting

Jangan mengonfigurasi replikasi antara bucket S3 sampai Anda memahami berapa banyak penyimpanan yang digunakan saat pembuatan versi objek dihidupkan.

Penggunaan bucket S3 berversi dapat sangat meningkatkan jumlah penyimpanan di Amazon S3 karena setiap modifikasi pada file membuat versi baru dari objek S3. Secara default, Amazon S3 terus menyimpan semua versi ini kecuali Anda secara khusus membuat kebijakan untuk mengganti perilaku ini dan membatasi jumlah versi yang disimpan. Jika Anda melihat penggunaan penyimpanan yang luar biasa besar dengan versi objek diaktifkan, periksa apakah kebijakan penyimpanan Anda ditetapkan dengan tepat. Peningkatan jumlah HTTP 503-slow down tanggapan untuk permintaan browser juga dapat menjadi hasil dari masalah dengan versi objek.

Jika Anda mengaktifkan versi objek setelah menginstal Gateway File S3, semua objek unik dipertahankan (ID=”NULL”) dan Anda dapat melihat semuanya di sistem file. Versi baru objek diberi ID unik (versi lama dipertahankan). Berdasarkan stempel waktu objek, hanya objek berversi terbaru yang dapat dilihat di sistem file NFS.

Setelah Anda mengaktifkan versi objek, bucket S3 Anda tidak dapat dikembalikan ke status nonversioned. Namun, Anda dapat menangguhkan pembuatan versi. Saat Anda menangguhkan pembuatan versi, objek baru diberi ID. Jika objek bernama yang sama ada dengan ID=”NULL” nilai, versi yang lebih lama akan ditimpa. Namun, versi apa pun yang berisi NULL non-ID dipertahankan. Stempel waktu mengidentifikasi objek baru sebagai yang sekarang, dan itulah yang muncul di sistem file NFS.

Perubahan pada bucket S3 tidak tercermin di Storage Gateway

Storage Gateway memperbarui cache berbagi file secara otomatis ketika Anda menulis file ke cache secara lokal menggunakan berbagi file. Namun, Storage Gateway tidak secara otomatis memperbarui cache saat Anda mengunggah file langsung ke Amazon S3. Ketika Anda melakukan ini, Anda harus melakukan RefreshCache operasi untuk melihat perubahan pada berbagi file. Jika Anda memiliki lebih dari satu file share, maka Anda harus menjalankan RefreshCache operasi pada setiap file share.

Anda dapat menyegarkan cache menggunakan konsol Storage Gateway dan AWS Command Line Interface (AWS CLI):

  • Untuk menyegarkan cache menggunakan konsol Storage Gateway, lihat Menyegarkan objek di bucket Amazon S3.

  • Untuk me-refresh cache menggunakan AWS CLI:

    1. Jalankan perintah aws storagegateway list-file-shares

    2. Salin Amazon Resource Number (ARN) dari file berbagi dengan cache yang ingin Anda refresh.

    3. Jalankan refresh-cache perintah dengan ARN Anda sebagai nilai untuk: --file-share-arn

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

Untuk mengotomatiskan RefreshCache operasi, lihat Bagaimana cara mengotomatiskan RefreshCache operasi di Storage Gateway?

Izin ACL tidak berfungsi seperti yang diharapkan

Jika izin daftar kontrol akses (ACL) tidak berfungsi seperti yang Anda harapkan dengan berbagi file SMB, Anda dapat melakukan pengujian.

Untuk melakukan ini, pertama-tama uji izin pada server file Microsoft Windows atau berbagi file Windows lokal. Kemudian bandingkan perilaku tersebut dengan berbagi file gateway Anda.

Performa gateway Anda menurun setelah Anda melakukan operasi rekursif

Dalam beberapa kasus, Anda mungkin melakukan operasi rekursif, seperti mengganti nama direktori atau mengaktifkan pewarisan untuk ACL, dan memaksanya turun ke pohon. Jika Anda melakukan ini, Gateway File S3 Anda secara rekursif menerapkan operasi ke semua objek dalam berbagi file.

Misalnya, Anda menerapkan pewarisan ke objek yang ada di bucket S3. Gateway File S3 Anda secara rekursif menerapkan pewarisan ke semua objek di bucket. Operasi semacam itu dapat menyebabkan kinerja gateway Anda menurun.