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 pengaturan versi objek diaktifkan dapat memengaruhi apa yang Anda lihat di berbagi fileSaat menulis ke bucket S3 dengan pembuatan 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 dilakukan jika Anda mengalami masalah tak terduga dengan berbagi file Anda.

Berbagi file macet dalam status MEMBUAT, MEMPERBARUI, atau MENGHAPUS

Status berbagi file merangkum kesehatan berbagi file Anda. Jika berbagi file S3 File Gateway Anda macet di CREATING statusUPDATING,, atauDELETING, gunakan langkah-langkah pemecahan masalah berikut untuk mengidentifikasi dan menyelesaikan masalah.

catatan

Saat Anda membuat berbagi file, Storage Gateway tidak memverifikasi bahwa peran IAM dan bucket Amazon S3 yang Anda tentukan sudah ada. Ini disengaja, karena peran IAM yang baru dibuat dapat membutuhkan waktu untuk tersedia bagi Storage Gateway untuk diasumsikan. Akibatnya, CreateSMBFileShare permintaan CreateNFSFileShare atau yang menentukan peran atau bucket yang tidak ada masih berhasil dan mengembalikan file share ARN, tetapi berbagi file tetap dalam CREATING status alih-alih berubah menjadiAVAILABLE. Sebelum melanjutkan pemecahan masalah, konfirmasikan bahwa peran IAM dan bucket Amazon S3 yang Anda tentukan ada.

Konfirmasikan izin peran IAM dan hubungan kepercayaan

Per AWS Identity and Access Management an (IAM) yang terkait dengan berbagi file Anda harus ada, dan 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. Konfirmasikan bahwa peran IAM yang Anda tentukan untuk berbagi file muncul dalam daftar peran. Jika peran tidak ada, buatlah, lalu buat berbagi file lagi. Untuk informasi selengkapnya, lihat Memberikan akses ke bucket Amazon S3.

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

  5. Pilih tab Relasi kepercayaan.

  6. Konfirmasikan bahwa Storage Gateway terdaftar sebagai entitas tepercaya. Jika Gerbang Penyimpanan 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"
    }
  ]
}

  7. 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 menyertakan 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 status CREATING atau jika AWS Security Token Service (AWS STS) dinonaktifkan di Wil AWS ayah Anda.

Untuk memverifikasi AWS Status 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 Layanan Token Keamanan (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 mengikuti aturan penamaan

Berbagi file Anda memerlukan bucket Amazon S3 yang sudah ada yang mengikuti konvensi penamaan Amazon S3. Storage Gateway tidak memverifikasi bahwa bucket ada saat Anda membuat berbagi file, sehingga berbagi file yang menunjuk ke bucket yang dihapus atau tidak pernah dibuat tetap dalam CREATING status.

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 ada. Jika bucket tidak ada, buatlah. Setelah Anda membuat bucket, status berbagi file harus berubah menjadiAVAILABLE. Untuk informasi selengkapnya, lihat Membuat bucket di Panduan Pengguna Layanan Penyimpanan Sederhana Amazon.

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

    catatan

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

Paksa menghapus berbagi file yang macet dalam status DELETING

Saat Anda menghapus berbagi file, gateway menghapus berbagi dari bucket Amazon S3 terkait. Namun, data yang sedang 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 unggah. 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 memaksa menghapus berbagi file:

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

  2. Di panel navigasi, pilih Ber bagi file.

  3. Pilih berbagi file 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 perintah AWS CLI delete-file-share dengan parameter disetel ke--force-delete. true

penting

Sebelum memaksa menghapus file share, konfirmasikan bahwa gateway Anda tidak dalam OFFLINE status. Jika gateway offline, selesaikan masalah offline terlebih dahulu. Untuk informasi selengkapnya, lihat Pemecahan masalah: gateway offline di konsol Storage Gateway.

Jika mesin virtual gateway (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 bertransisi keluar dari statusCREATING,UPDATING, atauDELETING. Masalah jaringan umum meliputi:

  • Gateway Anda offline atau VM gateway dihapus.

  • Akses jaringan antara Storage Gateway dan titik akhir 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 - Konfigurasi, masukkan nomor yang sesuai dengan U ji Konektivitas S3.

  3. Pilih jenis titik akhir Amazon S3:

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

    • 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 VPC Amazon S3 (misalnya,vpce-0329c2790456f2d01-0at85l34).

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

  • Kegagalan Tes 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 Tes SSL - Menunjukkan bahwa inspeksi SSL atau inspeksi paket mendalam sedang terjadi antara VM gateway dan titik akhir layanan Amazon S3. 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 - Konfigurasi, masukkan nomor yang sesuai dengan Konfigur HTTP/SOCKS asi Proxy.

  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 pendengar yang dikonfigurasi), lalu ke titik akhir Amazon S3 melalui port 443.

  4. Konfirmasikan bahwa proxy atau firewall mengizinkan 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 tetap ada, Anda dapat menghapus konfigurasi proxy sementara 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 untuk titik akhir Amazon S3. Pastikan tabel rute subnet Amazon EC2 merutekan lalu lintas Amazon S3 ke titik akhir Amazon S3 dengan benar. Untuk informasi selengkapnya, lihat port jaringan yang diperlukan.

  • Untuk gateway lokal - Konfirmasikan bahwa aturan firewall mengizinkan port yang diperlukan dan bahwa 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 Amazon S3 Amazon VPC yang digunakan oleh gateway belum dihapus. Jika titik akhir Amazon VPC 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 file share macet dalam status CREATING, verifikasi bahwa bucket S3 tempat Anda memetakan berbagi file sudah ada. Untuk informasi tentang cara melakukannya, lihatBerbagi file macet dalam status MEMBUAT, MEMPERBARUI, atau MENGHAPUS, sebelumnya.

  2. Jika bucket S3 ada, maka verifikasi bahwa AWS Security Token Service itu diaktifkan di wilayah tempat Anda membuat berbagi file. Jika token keamanan tidak aktif, Anda harus mengaktifkannya. Untuk informasi tentang cara mengaktifkan token menggunakan AWS Security Token Service, lihat Meng aktifkan dan menonaktifkan AWS STS di Wil AWS ayah di Panduan Pengguna IAM.

Berbagi file SMB tidak mengizinkan beberapa metode akses yang berbeda

Berbagi file SMB memiliki batasan berikut:

  1. Ketika klien yang sama mencoba untuk memasang berbagi 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 Active Directory yang diekspor oleh gateway yang sama.

Beberapa berbagi file tidak dapat menulis ke bucket S3 yang dipetakan

Kami tidak menyarankan untuk mengonfigurasi bucket S3 Anda untuk mengizinkan beberapa berbagi file untuk menulis ke satu bucket S3. Pendekatan ini dapat menyebabkan hasil yang tidak terduga.

Sebagai gantinya, sebaiknya Anda mengizinkan hanya 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 File Gateway.

Pemberitahuan untuk grup log yang dihapus saat menggunakan log audit

Jika grup log tidak ada, pengguna dapat memilih tautan grup log di bawah pesan itu 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 Anda, 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 File Gateway.

  3. Jika File Gateway Anda menggunakan SSE-KMS atau DSSE-KMS untuk enkripsi, pastikan peran IAM yang terkait dengan berbagi file menyertakan KMS:Encrypt, KMS:Decrypt, k ms: ReEncrypt *, kms:, dan kms: permissions. GenerateDataKey DescribeKey Untuk informasi selengkapnya, lihat Menggunakan Identity-Based Kebijakan (Kebijakan IAM) untuk Gerbang Penyimpanan.

Tidak dapat mengubah enkripsi default untuk digunakan 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) default untuk bucket S3 Anda, objek yang disimpan oleh Amazon S3 File Gateway di bucket tidak akan dienkripsi. SSE-KMS Secara default, S3 File Gateway 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 digunakan SSE-KMS dengan AWS KMS kunci Anda sendiri, Anda harus mengaktifkan SSE-KMS enkripsi. Untuk melakukannya, Anda memberikan Amazon Resource Name (ARN) dari kunci KMS saat membuat file share. Anda juga dapat memperbarui pengaturan KMS untuk berbagi file Anda dengan menggunakan operasi UpdateSMBFileShare API UpdateNFSFileShare atau. 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 pengaturan 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 mungkin tidak diperbarui sebagai akibat dari 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 beberapa salinan objek dengan nama yang sama. Setiap salinan memiliki nilai ID yang terpisah, misalnyafile1.jpg: ID="xxx" danfile1.jpg:ID="yyy". Jumlah objek dengan nama identik dan masa hidupnya dikendalikan oleh kebijakan siklus hidup Amazon S3. Untuk detail selengkapnya tentang konsep Amazon S3 ini, lihat Menggunakan 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 pembuatan versi diaktifkan.

Di S3 File Gateway Anda, file yang ditampilkan adalah versi terbaru dari objek dalam bucket S3 pada saat objek diambil atau cache diperbarui. S3 File Gateway 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, S3 File Gateway membuat versi baru dari objek bernama dengan perubahan Anda, dan versi itu menjadi versi terbaru.

S3 File Gateway 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 RefreshCache API atau refresh dari konsol seperti yang dijelaskan dalamMenyegarkan cache objek bucket Amazon S3.

penting

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

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

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

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

  • Ketika file ditulis ke S3 File Gateway oleh klien NFS atau SMB, S3 File Gateway mengunggah data file ke Amazon S3 diikuti oleh metadatanya, (kepemilikan, stempel waktu, dll.). Mengunggah data file membuat objek Amazon S3, dan mengunggah metadata untuk file 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 mengosongkan ruang cache atau tingkat penulisan yang tinggi ke file. Hal ini dapat menghasilkan beberapa versi objek di bucket S3.

Anda harus memantau bucket S3 Anda 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 Same-Region replikasi (SRR) atau Cross-Region replikasi (CRR) antara bucket S3 akan meningkatkan penyimpanan yang digunakan. Untuk informasi selengkapnya tentang replikasi, lihat Replikasi.

penting

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

Penggunaan bucket S3 berversi dapat sangat meningkatkan jumlah penyimpanan di Amazon S3 karena setiap modifikasi pada file membuat versi baru 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 pengaturan versi objek diaktifkan, periksa apakah kebijakan penyimpanan Anda diatur dengan tepat. Peningkatan jumlah HTTP 503-slow down tanggapan untuk permintaan browser juga dapat menjadi hasil dari masalah dengan pembuatan versi objek.

Jika Anda mengaktifkan versi objek setelah menginstal S3 File Gateway, 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 pembuatan versi objek, bucket S3 Anda tidak dapat dikembalikan ke status tanpa versi. 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 diganti. Namun, versi apa pun yang berisi non- NULL ID dipertahankan. Stempel waktu mengidentifikasi objek baru sebagai objek saat ini, dan itu adalah yang muncul di sistem file NFS.

Perubahan pada bucket S3 tidak tercermin di Storage Gateway

Storage Gateway memperbarui cache berbagi file secara otomatis saat Anda menulis file ke cache secara lokal menggunakan berbagi file. Namun, Storage Gateway tidak memperbarui cache secara otomatis 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 berbagi file, maka Anda harus menjalankan RefreshCache operasi pada setiap berbagi file.

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

  • Untuk menyegarkan cache menggunakan AWS CLI:

    1. Jalankan perintah aws storagegateway list-file-shares

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

    3. Jalan refresh-cache kan 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 pada 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, Anda dapat melakukan pengujian.

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

Kinerja 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, S3 File Gateway Anda secara rekursif menerapkan operasi ke semua objek dalam berbagi file.

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