本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 故障診斷：檔案共用問題 如果您的檔案共享發生非預期問題，您可在下列資訊中找到應採取的動作。 **Topics** + [檔案共享卡在建立、更新或刪除狀態](#troubleshooting-file-share-stuck-states) + [您無法建立檔案共享](#create-file-troubleshoot) + [SMB 檔案共用不允許多種不同的存取方法](#smb-fileshare-troubleshoot) + [多個檔案共享無法寫入映射的 S3 儲存貯體](#multiwrite) + [使用稽核日誌時已刪除日誌群組的通知](#multiwrite) + [無法將檔案上傳至 S3 儲存貯體](#access-s3bucket) + [無法將預設加密變更為使用 SSE-KMS 來加密存放在 S3 儲存貯體中的物件](#encryption-issues) + [在開啟物件版本控制的 S3 儲存貯體中直接進行的變更可能會影響您在檔案共享中看到的內容](#s3-object-versioning-file-share-issue) + [在開啟版本控制的情況下寫入 S3 儲存貯體時，Amazon S3 檔案閘道可能會建立多個版本的 Amazon S3 物件](#s3-object-versioning-file-gateway-issue) + [S3 儲存貯體的變更不會反映在 Storage Gateway 中](#s3-changes-issue) + [ACL 許可未如預期般運作](#smb-acl-issues) + [執行遞迴操作後，閘道效能下降](#recursive-operation-issues) ## 檔案共享卡在建立、更新或刪除狀態 檔案共用狀態摘要說明檔案共用的運作狀態。如果您的 S3 檔案閘道檔案共享卡在 `CREATING`、 `UPDATING`或 `DELETING` 狀態，請使用下列疑難排解步驟來識別和解決問題。 ### 確認 IAM 角色許可和信任關係 與您的檔案共享相關聯的 AWS Identity and Access Management (IAM) 角色必須具有足夠的許可，才能存取 Amazon S3 儲存貯體。此外，角色的信任政策必須授予 Storage Gateway 服務擔任角色的許可。 **若要驗證 IAM 角色許可：** 1. 在以下網址開啟 IAM 主控台：[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)。 1. 在導覽窗格中，選擇**角色**。 1. 選擇與您檔案共享相關聯的 IAM 角色。 1. 選擇**信任關係**標籤。 1. 確認 Storage Gateway 列為信任的實體。如果 Storage Gateway 不是信任的實體，請選擇**編輯信任關係**，然後新增下列政策： ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "storagegateway.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` 1. 確認 IAM 角色具有正確的許可，且 Amazon S3 儲存貯體已列為 IAM 政策中的資源。如需詳細資訊，請參閱[授予對 Amazon S3 儲存貯體的存取權](grant-access-s3.md)。 **注意** 為避免跨服務混淆代理人預防問題，請使用包含條件內容索引鍵的信任關係政策。如需詳細資訊，請參閱[預防跨服務混淆代理人](cross-service-confused-deputy-prevention.md)。 ### 確認您的區域已啟用 AWS STS 如果 AWS 區域已停用 AWS Security Token Service (AWS STS)，檔案共享可能會卡在 `CREATING`或 `UPDATING` 狀態。 **若要驗證 AWS STS 狀態：** 1. 在 https：//[https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) 開啟 AWS Identity and Access Management 主控台。 1. 在導覽窗格中，選擇**帳戶設定**。 1. 在**安全字符服務 (STS)** 區段中，確認您要建立檔案共享 AWS 的區域**的狀態**為**作用中**。 1. 如果狀態為**非作用中**，請選擇**啟用**以 AWS STS 在該區域中啟用 。 ### 驗證 S3 儲存貯體是否存在，並遵循命名規則 您的檔案共享需要遵循 Amazon S3 命名慣例的有效 Amazon S3 儲存貯體。 **若要驗證 S3 儲存貯體：** 1. 開啟位於 [https://console.aws.amazon.com/s3/](https://console.aws.amazon.com/s3/) 的 Amazon S3 主控台。 1. 確認映射至檔案共享的 Amazon S3 儲存貯體存在。如果儲存貯體不存在，請建立它。建立儲存貯體後，檔案共用狀態應變更為 `AVAILABLE`。如需詳細資訊，請參閱 *Amazon Simple Storage Service 主控台使用者指南*中的[建立儲存貯體](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html)。 1. 請確認您的儲存貯體名稱符合《*Amazon Simple Storage Service 使用者指南*》中的[儲存貯體命名規則](https://docs.aws.amazon.com/AmazonS3/latest/dev/BucketRestrictions.html#bucketnamingrules)。 **注意** S3 File Gateway 不支援儲存貯體名稱中包含句點 (`.`) 的 Amazon S3 儲存貯體。 ### 強制刪除停滯在刪除狀態的檔案共用 當您刪除檔案共享時，閘道會從相關聯的 Amazon S3 儲存貯體中移除共享。不過，目前上傳的資料會在刪除完成之前繼續上傳。在此過程中，檔案共享會顯示 `DELETING` 狀態。 **重要** 檢查閘道`CachePercentDirty`的 Amazon CloudWatch 指標，以判斷待上傳的資料量。如需 Storage Gateway 指標的詳細資訊，請參閱 [監控 S3 檔案閘道](monitoring-file-gateway.md)。 如果您不想等待所有進行中的上傳完成，您可以強制刪除檔案共享。 **若要強制刪除檔案共享：** 1. 在 https：//[https://console.aws.amazon.com/storagegateway/](https://console.aws.amazon.com/storagegateway/) 開啟 Storage Gateway 主控台。 1. 在導覽窗格中，選擇**檔案共享**。 1. 選取您要刪除的檔案共享。 1. 選擇**詳細資訊**索引標籤，並檢閱**此檔案共享正在刪除**的訊息。 1. 在訊息中驗證檔案共享的 ID，然後選取確認方塊。 **注意** 您無法復原強制刪除操作。 1. 選擇**立即強制刪除**。 或者，您可以使用 AWS CLI [delete-file-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/storagegateway/delete-file-share.html) 命令，並將 `--force-delete` 參數設定為 `true`。 **重要** 在強制刪除檔案共享之前，請確認您的閘道未處於 `OFFLINE` 狀態。如果閘道離線，請先解決離線問題。如需詳細資訊，請參閱[故障診斷：Storage Gateway 主控台中的閘道離線](troubleshooting-gateway-offline.md)。 如果閘道虛擬機器 (VM) 已刪除，您必須從 Storage Gateway 主控台刪除閘道，以移除所有相關聯的檔案共用，包括停滯在 `DELETING` 狀態的檔案共用。如需詳細資訊，請參閱[刪除您的閘道並移除相關聯的資源](deleting-gateway-common.md)。 ### 疑難排解網路連線問題 網路問題可能會使您的檔案共享無法從 `CREATING`、 `UPDATING`或 `DELETING` 狀態轉換。常見的網路問題包括： + 您的閘道已離線或閘道 VM 已刪除。 + Storage Gateway 和 Amazon S3 服務端點之間的網路存取會遭到封鎖。 + 已刪除閘道用來與 Amazon S3 通訊的 Amazon S3 Amazon VPC 端點。 + 必要的網路連接埠未開啟或網路路由設定不正確。 #### 從閘道本機主控台測試 S3 連線 **若要測試 S3 連線：** 1. 登入您閘道的本機主控台。如需詳細資訊，請參閱[登入 File Gateway 本機主控台](LocalConsole-login-fgw.md)。 1. 在 **Storage Gateway - 組態**主功能表中，輸入與**測試 S3 連線對應的**數字。 1. 選擇 Amazon S3 端點類型： + 對於流經網際網路閘道、NAT 閘道、傳輸閘道或 Amazon S3 閘道 Amazon VPC 端點的 Amazon S3 流量，請選擇**公**有。 + 對於流經 Amazon S3 介面 Amazon VPC 端點的 Amazon S3 流量，請選擇 **VPC (PrivateLink)**。 + 針對 FIPS 端點，選擇 FIPS 選項。 1. 輸入 Amazon S3 儲存貯體區域。 1. 如果使用 Amazon VPC 端點，請輸入 Amazon S3 Amazon VPC 端點 DNS 名稱 （例如 `vpce-0329c2790456f2d01-0at85l34`)。 閘道會自動執行連線測試，以驗證網路連線和 SSL 連線。如果測試失敗： + **網路測試失敗** - 通常是由防火牆規則、安全群組組態或不當的網路路由所造成。確認必要的連接埠已開啟，且網路路由已正確設定。 + **SSL 測試失敗** - 表示閘道 VM 和 Amazon S3 服務端點之間發生 SSL 檢查或深度封包檢查。停用 Storage Gateway 流量的 SSL 和深度封包檢查。 #### 驗證代理組態 如果您的閘道使用代理伺服器，請確認代理未封鎖網路通訊。 **若要檢查代理組態：** 1. 在 **Storage Gateway - 組態**主功能表中，輸入對應至 **HTTP/SOCKS Proxy 組態**的數字。 1. 選取 選項以檢視目前的網路代理組態。 1. 如果已設定代理，請確認 Amazon S3 流量可以透過連接埠 3128 （或設定的接聽程式連接埠） 從 Storage Gateway 流向代理伺服器，然後透過連接埠 443 流向 Amazon S3 端點。 1. 確認代理或防火牆允許進出 Storage Gateway 所需網路連接埠和服務端點的流量。如需詳細資訊，請參閱所需的網路連接埠。 如果問題仍然存在，您可以暫時移除代理組態，以判斷代理是否造成問題。 #### 驗證安全群組和網路路由 + **對於 Amazon EC2 上的閘道** - 確認安全群組已向 Amazon S3 端點開啟連接埠 443。驗證 Amazon EC2 子網路的路由表是否正確地將 Amazon S3 流量路由至 Amazon S3 端點。如需詳細資訊，請參閱所需的網路連接埠。 + **對於內部部署閘道** - 確認防火牆規則允許必要的連接埠，且本機路由表會將 Amazon S3 流量正確路由至 Amazon S3 端點。如需詳細資訊，請參閱所需的網路連接埠。 + **VPC 端點** - 確認閘道使用的 Amazon S3 Amazon VPC 端點尚未刪除。如果刪除 Amazon VPC 端點，且閘道沒有公有 IP 地址，則閘道無法與 Amazon S3 通訊。 ## 您無法建立檔案共享 1. 如果您因為檔案共享卡在 CREATING 狀態而無法建立檔案共享，請確認您映射檔案共享的 S3 儲存貯體是否存在。如需如何執行作業的資訊，請參閱上一篇的[檔案共享卡在建立、更新或刪除狀態](#troubleshooting-file-share-stuck-states)。 1. 如果 S3 儲存貯體存在，請確認 AWS Security Token Service 已在您建立檔案共享的區域中啟用。如果安全字符非作用中，您應該啟用它。如需有關如何使用 啟用權杖的資訊 AWS Security Token Service，請參閱《*IAM 使用者指南*》中的[在 AWS 區域中啟用和停用 AWS STS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html)。 ## SMB 檔案共用不允許多種不同的存取方法 SMB 檔案共享有以下限制： 1. 當相同的用戶端嘗試同時掛載 Active Directory 和訪客存取 SMB 檔案共享，會顯示以下錯誤訊息：`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.` 1. Windows 使用者不能保持連線到兩個訪客存取 SMB 檔案共享，當新的訪客存取連線建立時可能會中斷連線。 1. Windows 用戶端無法同時掛載訪客存取和由相同閘道匯出的 Active Directory SMB 檔案共享。 ## 多個檔案共享無法寫入映射的 S3 儲存貯體 我們不建議您設定 S3 儲存貯體，以允許多個檔案共用寫入一個 S3 儲存貯體。這種方法會造成無法預測的結果。 相反地，我們建議您只允許一個檔案共享寫入一個 S3 儲存貯體。您建立一個儲存貯體政策，僅允許與您檔案共享相關聯的角色寫入儲存貯體。如需詳細資訊，請參閱[檔案閘道的最佳實務](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html)。 ## 使用稽核日誌時已刪除日誌群組的通知 如果日誌群組不存在，使用者可以選取該訊息下方的日誌群組連結，以建立新日誌群組或使用現有的日誌群組做為稽核日誌的目標 ## 無法將檔案上傳至 S3 儲存貯體 如果您無法將檔案上傳至 S3 儲存貯體，請執行下列動作： 1. 請確定您已授予 Amazon S3 File Gateway 將檔案上傳至 S3 儲存貯體所需的存取權。如需詳細資訊，請參閱[授予對 Amazon S3 儲存貯體的存取權](grant-access-s3.md)。 1. 確定建立儲存貯體的角色具有寫入 S3 儲存貯體的許可。如需詳細資訊，請參閱[檔案閘道的最佳實務](https://docs.aws.amazon.com/filegateway/latest/files3/best-practices.html)。 1. 如果您的檔案閘道使用 SSE-KMS 或 DSSE-KMS 進行加密，請確定與檔案共享相關聯的 IAM 角色包含 *kms:Encrypt*、 *kms:Decrypt*、 *kms:ReEncrypt\$1*、 *kms:GenerateDataKey* 和 *kms:DescribeKey* 許可。如需詳細資訊，請參閱[針對 Storage Gateway 使用以身分為基礎的政策 (IAM 政策）](https://docs.aws.amazon.com/filegateway/latest/files3/using-identity-based-policies.html)。 ## 無法將預設加密變更為使用 SSE-KMS 來加密存放在 S3 儲存貯體中的物件 如果您變更預設加密並將 SSE-KMS （使用 AWS KMS受管金鑰的伺服器端加密） 設為 S3 儲存貯體的預設值，Amazon S3 File Gateway 存放在儲存貯體中的物件不會使用 SSE-KMS 加密。根據預設，S3 File Gateway 在將資料寫入 S3 儲存貯體時，會使用由 Amazon S3 (SSE-S3) 管理的伺服器端加密。變更預設值不會自動變更您的加密。 若要將加密變更為搭配您自己的 AWS KMS 金鑰使用 SSE-KMS，您必須開啟 SSE-KMS 加密。若要這樣做，當您建立檔案共享時要提供 KMS 金鑰的 Amazon Resource Name (ARN)。您也可以使用 `UpdateNFSFileShare` 或 `UpdateSMBFileShare` API 操作，更新您檔案共享的 KMS 設定。此更新適用於更新後存放在 S3 儲存貯體中的物件。如需詳細資訊，請參閱[使用 的資料加密 AWS KMS](encryption.md)。 ## 在開啟物件版本控制的 S3 儲存貯體中直接進行的變更可能會影響您在檔案共享中看到的內容 如果您的 S3 儲存貯體有另一個用戶端寫入的物件，則由於 S3 儲存貯體物件版本控制，您的 S3 儲存貯體檢視可能不是up-to-date。您應一律先重新整理您的快取，再檢查感興趣的檔案。 *物件版本控制*是選用的 S3 儲存貯體功能，透過存放多個同名物件的副本以利保護資料。每個副本都有個別的 ID 值，例如 `file1.jpg`：`ID="xxx"` 和 `file1.jpg`：`ID="yyy"`。相同名稱的物件數量及其生命週期由 Amazon S3 生命週期政策控制。如需這些 Amazon S3 概念的詳細資訊，請參閱《Amazon S3 開發人員指南》中的[使用版本控制](https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html)和[物件生命週期管理](https://docs.aws.amazon.com/AmazonS3/latest/dev/object-lifecycle-mgmt.html)。 *Amazon S3 * 當您刪除版本控制的物件時，該物件會以刪除標記加以標記並保留下來。只有 S3 儲存貯體擁有者才能永久刪除開啟版本控制的物件。 在您的 S3 檔案閘道中，顯示的檔案是擷取物件或重新整理快取時，S3 儲存貯體中物件的最新版本。S3 檔案閘道會忽略任何較舊版本或標記為刪除的任何物件。讀取檔案時，您讀取的資料是來自最新的版本。當您在檔案共享中寫入檔案時，S3 File Gateway 會在變更時建立新的具名物件版本，該版本會成為最新版本。 您的 S3 檔案閘道會繼續從較早版本讀取，而且如果您在應用程式外部將新版本新增至 S3 儲存貯體，您所做的更新會根據較早版本而定。若要讀取最新版的物件，請從主控台使用 [RefreshCache](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_RefreshCache.html) API 動作或重新整理，如 [重新整理 Amazon S3 儲存貯體物件快取](refresh-cache.md) 中所述。 **重要** 我們不建議將物件或檔案從檔案共用外部寫入 S3 File Gateway S3 儲存貯體。 ## 在開啟版本控制的情況下寫入 S3 儲存貯體時，Amazon S3 檔案閘道可能會建立多個版本的 Amazon S3 物件 開啟物件版本控制後，每次從 NFS 或 SMB 用戶端更新檔案時，您可能會擁有在 Amazon S3 中建立的多個物件版本。以下是可能導致在 S3 儲存貯體中建立多個物件版本的案例： + 當 NFS 或 SMB 用戶端在上傳到 Amazon S3 之後在 Amazon S3 檔案閘道中修改檔案時，S3 檔案閘道會上傳新的或修改的資料，而不是上傳整個檔案。檔案修改會導致建立新版本的 Amazon S3 物件。 + 當 NFS 或 SMB 用戶端將檔案寫入 S3 檔案閘道時，S3 檔案閘道會將檔案的資料上傳到 Amazon S3，後面接著其中繼資料 （擁有者、時間戳記等）。上傳檔案資料會建立 Amazon S3 物件，並上傳檔案的中繼資料會更新 Amazon S3 物件的中繼資料。此程序會建立另一個版本的物件，進而產生兩個版本的物件。 + 當 S3 檔案閘道上傳較大的檔案時，可能需要先上傳較小的檔案區塊，用戶端才能寫入檔案閘道。這的一些原因包括釋放快取空間或對檔案的高寫入速率。這可能會導致 S3 儲存貯體中有多個版本的物件。 在設定生命週期政策將物件移至不同的儲存類別之前，您應該監控 S3 儲存貯體以判斷物件存在多少版本。您應該設定舊版的生命週期過期，將 S3 儲存貯體中物件的版本數量降至最低。在 S3 儲存貯體之間使用相同區域複寫 (SRR) 或跨區域複寫 (CRR) 會增加使用的儲存體。如需複寫的詳細資訊，請參閱[複寫](https://docs.aws.amazon.com/AmazonS3/latest/dev/replication.html)。 **重要** 在了解開啟物件版本控制時，請勿設定 S3 儲存貯體之間的複寫。 使用版本控制的 S3 儲存貯體可以大幅增加 Amazon S3 中的儲存量，因為每次修改檔案都會建立新的 S3 物件版本。根據預設，Amazon S3 會繼續存放所有這些版本，除非您特別建立政策來覆寫此行為，並限制保留的版本數量。如果您在開啟物件版本控制時發現異常大量的儲存體用量，請檢查儲存政策是否已正確設定。瀏覽器請求的 `HTTP 503-slow down` 回應數增加，也會導致物件版本控制問題。 如果您在安裝 S3 檔案閘道之後開啟物件版本控制，則會保留所有唯一的物件 (`ID=”NULL”`)，而且您可以在檔案系統中查看所有物件。新版的物件會獲指派唯一的 ID (保留較舊版本)。以物件的時間戳記為基礎，只有最新的版本控制物件會出現在 NFS 檔案系統中。 開啟物件版本控制後，您的 S3 儲存貯體無法返回非版本控制狀態。但是您可以暫停版本控制。當您暫停版本控制時，新的物件會獲指派一個 ID。如有值為 `ID=”NULL”` 的相同具名物件存在，則會覆寫較舊的版本。但仍保留包含非 `NULL` ID 的任何版本。時間戳記會將新的物件視為最新的物件，這也是出現在 NFS 檔案系統中的物件。 ## S3 儲存貯體的變更不會反映在 Storage Gateway 中 當您使用檔案共享將檔案寫入本機快取時，Storage Gateway 會自動更新檔案共享快取。不過，當您將檔案直接上傳至 Amazon S3 時，Storage Gateway 不會自動更新快取。執行此操作時，您必須執行 `RefreshCache`操作，以查看檔案共享上的變更。如果您有多個檔案共享，則必須在每個檔案共享上執行 `RefreshCache`操作。 您可以使用 Storage Gateway 主控台和 () AWS Command Line Interface 重新整理快取AWS CLI： + 若要使用 Storage Gateway 主控台重新整理快取，請參閱重新整理 Amazon S3 儲存貯體中的物件。 + 若要使用 重新整理快取 AWS CLI： 1. 執行 命令 `aws storagegateway list-file-shares` 1. 使用您要重新整理的快取複製檔案共享的 Amazon Resource Number (ARN)。 1. 使用 ARN 做為 的值來執行 `refresh-cache`命令`--file-share-arn`： `aws storagegateway refresh-cache --file-share-arn arn:aws:storagegateway:eu-west-1:12345678910:share/share-FFDEE12` 若要自動化`RefreshCache`操作，請參閱[如何在 Storage Gateway 上自動化 RefreshCache 操作？](https://aws.amazon.com/premiumsupport/knowledge-center/storage-gateway-automate-refreshcache/) ## ACL 許可未如預期般運作 如果存取控制清單 (ACL) 許可未如預期搭配 SMB 檔案共享運作，您可以執行測試。 若要這樣做，請先在 Microsoft Windows 檔案伺服器或本機 Windows 檔案共享上測試許可。接著，將其行為與閘道的檔案共享進行比較。 ## 執行遞迴操作後，閘道效能下降 在某些情況下，您可以執行遞迴操作，例如重新命名目錄或開啟 ACL 的繼承，並將其強制向下。如果您這樣做，S3 File Gateway 會以遞迴方式將操作套用至檔案共享中的所有物件。 例如，假設您將繼承套用至 S3 儲存貯體中的現有物件。您的 S3 檔案閘道會以遞迴方式將繼承套用至儲存貯體中的所有物件。這類操作可能會導致閘道的效能下降。