本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 針對 Storage Gateway 部署的問題進行故障診斷
您可以在下面找到與閘道、主機平台、檔案共用、高可用性、資料復原和安全性相關的最佳實務和疑難排解問題的相關資訊。內部部署閘道疑難排解資訊涵蓋部署在支援的虛擬化平台上的閘道。高可用性問題的故障診斷資訊涵蓋了在 VMware vSphere High Availability (HA) 平台上執行的閘道。
**主題**
+ [故障診斷：閘道離線問題](troubleshooting-gateway-offline.md) - 了解如何診斷可能導致您的閘道在 Storage Gateway 主控台中離線顯示的問題。
+ [故障診斷：Active Directory 問題](troubleshooting-active-directory.md) - 了解如何在嘗試將檔案閘道加入 Microsoft Active Directory 網域`ACCESS_DENIED`時收到錯誤訊息，例如 `TIMEOUT`、 `NETWORK_ERROR`或 。
+ [故障診斷：閘道啟用問題](troubleshooting-gateway-activation.md) - 了解如何在嘗試啟用 Storage Gateway 時收到內部錯誤訊息。
+ [故障診斷：內部部署閘道問題](troubleshooting-on-premises-gateway-issues.md) - 了解使用內部部署閘道時可能遇到的典型問題，以及如何允許 支援 連線至閘道以協助故障診斷。
+ [故障診斷：Microsoft Hyper-V 設定問題](troubleshooting-hyperv-setup.md) - 了解在 Microsoft Hyper-V 平台上部署 Storage Gateway 時可能遇到的典型問題。
+ [故障診斷：Amazon EC2 閘道問題](troubleshooting-EC2-gateway-issues.md) - 尋找您在使用 Amazon EC2 上部署的閘道時可能遇到的典型問題的相關資訊。
+ [故障診斷：硬體設備問題](troubleshooting-hardware-appliance-issues.md) - 了解如何解決使用 AWS Storage Gateway 硬體設備時可能遇到的問題。
+ [故障診斷：檔案閘道問題](troubleshooting-file-gateway-issues.md) - 尋找可協助您了解檔案閘道 CloudWatch 日誌中出現錯誤和運作狀態通知的原因的資訊。
+ [故障診斷：檔案共用問題](troubleshooting-file-share-issues.md) - 了解在檔案共享遇到意外問題時，您可以採取的動作。
+ [故障診斷：高可用性問題](troubleshooting-ha-issues.md) - 了解如果在 VMware HA 環境中部署的閘道發生問題，該怎麼辦。
# 故障診斷：Storage Gateway 主控台中的閘道離線
如果主控台顯示您的閘道離線， AWS Storage Gateway 請使用下列疑難排解資訊來判斷該怎麼做。
由於以下一個或多個原因，您的閘道可能顯示為離線：
+ 閘道無法連線到 Storage Gateway 服務端點。
+ 閘道意外關閉。
+ 與閘道相關聯的快取磁碟已中斷連線或修改，或已失敗。
若要讓閘道重新上線，請識別並解決導致閘道離線的問題。
## 檢查相關聯的防火牆或代理
如果您將閘道設定為使用代理，或將閘道放置在防火牆後方，請檢閱代理或防火牆的存取規則。代理或防火牆必須允許進出 Storage Gateway 所需網路連接埠和服務端點的流量。如需詳細資訊，請參閱[網路和防火牆需求](https://docs.aws.amazon.com/filegateway/latest/files3/Requirements.html#networks)。
## 檢查閘道流量的持續 SSL 或深度封包檢查
如果目前對閘道和 之間的網路流量執行 SSL 或深度封包檢查 AWS，則閘道可能無法與所需的服務端點通訊。若要讓閘道重新上線，您必須停用檢查。
## 在重新啟動或軟體更新後檢查 IOWaitPercent 指標
重新啟動或軟體更新後，請檢查檔案閘道的`IOWaitPercent`指標是否為 10 或更高。這可能會導致閘道在重建索引快取到 RAM 時回應速度變慢。如需詳細資訊，請參閱[故障診斷：使用 CloudWatch 指標](https://docs.aws.amazon.com/filegateway/latest/files3/troubleshooting-file-gateway-issues.html#gateway-not-responding)。
## 檢查 Hypervisor 主機上是否有電源中斷或硬體故障
閘道 Hypervisor 主機上的電源中斷或硬體故障可能會導致閘道意外關閉且無法連線。還原電源和網路連線後，您的閘道將可再次連線。
閘道恢復上線後，請務必採取步驟來復原資料。如需詳細資訊，請參閱[最佳實務：復原資料](https://docs.aws.amazon.com/filegateway/latest/files3/recover-data-from-gateway.html)。
## 檢查相關聯的快取磁碟是否有問題
如果至少有一個與閘道相關聯的快取磁碟遭到移除、變更或調整大小，或者已損毀，您的閘道可能會離線。
**如果從 Hypervisor 主機移除工作快取磁碟：**
1. 關機閘道。
1. 重新新增磁碟。
**注意**
請務必將磁碟新增至相同的磁碟節點。
1. 重新啟動閘道。
**如果快取磁碟損毀、已取代或已調整大小：**
+ 遵循將[現有 S3 檔案閘道取代為新執行個體](https://docs.aws.amazon.com/filegateway/latest/files3/migrate-data.html#replace-instance-file-gateway)中所述**的方法 2** 程序，以設定新的閘道，並從雲端重新下載快取磁碟資訊 AWS 。
# 故障診斷：將閘道加入 Active Directory 時發生問題
使用下列疑難排解資訊，判斷當您嘗試將檔案閘道加入 Microsoft Active Directory 網域`ACCESS_DENIED`時，收到錯誤訊息時該怎麼做，例如 `TIMEOUT`、 `NETWORK_ERROR`或 。
若要解決這些錯誤，請執行下列檢查和組態。
## 透過執行 nping 測試，確認閘道可以到達網域控制站
**若要執行 nping 測試：**
1. 使用 Hypervisor 管理軟體 (VMware、Hyper-V 或 KVM) 連接內部部署閘道的閘道本機主控台，或使用 ssh 連接 Amazon EC2 閘道。
1. 輸入對應的數字以選取**閘道主控台**，然後輸入 `h`以列出所有可用的命令。若要測試 Storage Gateway 虛擬機器與網域之間的連線，請執行下列命令：
`nping -d corp.domain.com -p 389 -c 1 -t tcp`
**注意**
`corp.domain.com` 將 取代為您的 Active Directory 網域 DNS 名稱，並將 取代`389`為您環境的 LDAP 連接埠。
確認您已在防火牆中開啟必要的連接埠。
以下是閘道能夠到達網域控制站的成功 nping 測試範例：
```
nping -d corp.domain.com -p 389 -c 1 -t tcp
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC
SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40 seq=2597195024 win=1480
RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44 seq=4170716243 win=8192
Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms
Raw packets sent: 1 (40B) | Rcvd: 1 (44B) | Lost: 0 (0.00%)
Nping done: 1 IP address pinged in 1.09 seconds
```
以下是 nping 測試的範例，其中目的地沒有連線或沒有回應`corp.domain.com`：
```
nping -d corp.domain.com -p 389 -c 1 -t tcp
Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC
SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389 S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480
Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A
Raw packets sent: 1 (40B) | Rcvd: 0 (0B) | Lost: 1 (100.00%)
Nping done: 1 IP address pinged in 1.07 seconds
```
## 檢查為 Amazon EC2 閘道執行個體的 VPC 設定的 DHCP 選項
如果檔案閘道是在 Amazon EC2 執行個體上執行，則您必須確保 DHCP 選項集已正確設定並連接到包含閘道執行個體的 Amazon Virtual Private Cloud (VPC)。如需詳細資訊，請參閱 [Amazon VPC 中的 DHCP 選項集](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_DHCP_Options.html)。
## 透過執行 dig 查詢，確認閘道可以解析網域
如果閘道無法解析網域，則閘道無法加入網域。
**若要執行 dig 查詢：**
1. 使用 Hypervisor 管理軟體 (VMware、Hyper-V 或 KVM) 連接內部部署閘道的閘道本機主控台，或使用 ssh 連接 Amazon EC2 閘道。
1. 輸入對應的數字以選取**閘道主控台**，然後輸入 `h`以列出所有可用的命令。若要測試閘道是否可以解析網域，請執行下列命令：
`dig -d corp.domain.com`
**注意**
`corp.domain.com` 將 取代為您的 Active Directory 網域 DNS 名稱。
以下是成功回應的範例：
```
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;corp.domain.com. IN A
;; ANSWER SECTION:
corp.domain.com. 600 IN A 10.10.10.10
corp.domain.com. 600 IN A 10.10.20.10
;; Query time: 0 msec
;; SERVER: 10.10.20.228#53(10.10.20.228)
;; WHEN: Thu Jun 30 16:36:32 UTC 2022
;; MSG SIZE rcvd: 78
```
## 檢查網域控制站設定和角色
確認網域控制站未設定為唯讀，且網域控制站有足夠的角色供電腦加入。若要測試這一點，請嘗試將其他伺服器從與閘道 VM 相同的 VPC 子網路加入網域。
## 檢查閘道是否已加入最近的網域控制站
最佳實務是，建議您將閘道加入地理上靠近閘道設備的網域控制器。如果閘道設備因為網路延遲無法在 20 秒內與網域控制器通訊，則網域聯結程序可能會逾時。例如，如果閘道設備位於美國東部 （維吉尼亞北部）， AWS 區域 而網域控制站位於亞太區域 （新加坡），則程序可能會逾時。 AWS 區域
**注意**
若要增加預設逾時值 20 秒，您可以在 AWS Command Line Interface (AWS CLI) 中執行 [join-domain 命令](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html)，並包含增加時間`--timeout-in-seconds`的選項。您也可以使用 [JoinDomain API 呼叫](https://amazonaws.com/storagegateway/latest/APIReference/API_JoinDomain.html)並包含 `TimeoutInSeconds` 參數來增加時間。逾時值上限為 3，600 秒。
如果您在執行 AWS CLI 命令時收到錯誤，請確定您使用的是最新版本 AWS CLI 。
## 確認 Active Directory 在預設組織單位 (OU) 中建立新的電腦物件
請確定 Microsoft Active Directory 沒有任何群組政策物件，可在預設 OU 以外的任何位置建立新的電腦物件。您必須先在預設的 OU 中存在新的電腦物件，才能將閘道加入 Active Directory 網域。有些 Active Directory 環境會自訂為具有新建立物件的不同 OUs。若要保證閘道 VM 的新電腦物件存在於預設 OU 中，請先嘗試在網域控制器上手動建立電腦物件，再將閘道加入網域。您也可以使用 執行 [join-domain 命令](https://docs.aws.amazon.com/cli/latest/reference/storagegateway/join-domain.html) AWS CLI。然後，指定 的選項`--organizational-unit`。
**注意**
建立電腦物件的程序稱為預備。
## 檢查您的網域控制站事件日誌
如果您在嘗試前幾節所述的所有其他檢查和組態後，無法將閘道加入網域，建議您檢查網域控制站事件日誌。檢查網域控制站的事件檢視器中是否有任何錯誤。確認閘道查詢已到達網域控制站。
# 故障診斷：閘道啟用期間的內部錯誤
Storage Gateway 啟用請求會周遊兩個網路路徑。用戶端傳送的傳入啟用請求會透過連接埠 80 連線至閘道的虛擬機器 (VM) 或 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體。如果閘道成功接收啟用請求，閘道會與 Storage Gateway 端點通訊，以接收啟用金鑰。如果閘道無法連線到 Storage Gateway 端點，閘道會以內部錯誤訊息回應用戶端。
使用以下疑難排解資訊，判斷在嘗試啟用 時，如果收到內部錯誤訊息該怎麼辦 AWS Storage Gateway。
**注意**
請務必使用最新的虛擬機器映像檔案或 Amazon Machine Image (AMI) 版本部署新的閘道。如果您嘗試啟用使用過期 AMI 的閘道，將會收到內部錯誤。
下載 AMI 之前，請務必選取您要部署的正確閘道類型。每個閘道類型的 .ova 檔案和 AMIs 不同，且不可互換。
## 解決使用公有端點啟用閘道時的錯誤
若要解決使用公有端點啟用閘道時的啟用錯誤，請執行下列檢查和組態。
### 檢查所需的連接埠
對於內部部署的閘道，請檢查本機防火牆上的連接埠是否已開啟。對於部署在 Amazon EC2 執行個體上的閘道，請檢查連接埠是否在執行個體的安全群組上開啟。若要確認連接埠已開啟，請從伺服器對公有端點執行 telnet 命令。此伺服器必須與閘道位於相同的子網路中。例如，下列 telnet 命令會測試連接埠 443 的連線：
```
telnet d4kdq0yaxexbo.cloudfront.net 443
telnet storagegateway.region.amazonaws.com 443
telnet dp-1.storagegateway.region.amazonaws.com 443
telnet proxy-app.storagegateway.region.amazonaws.com 443
telnet client-cp.storagegateway.region.amazonaws.com 443
telnet anon-cp.storagegateway.region.amazonaws.com 443
```
若要確認閘道本身可以到達端點，請存取閘道的本機 VM 主控台 （適用於內部部署的閘道）。或者，您可以 SSH 到閘道的執行個體 （適用於部署在 Amazon EC2 上的閘道）。然後，執行網路連線測試。確認測試傳回 `[PASSED]`。如需詳細資訊，請參閱[測試閘道的網路連線](https://docs.aws.amazon.com/filegateway/latest/files3/manage-on-premises-fgw.html#MaintenanceTestGatewayConnectivity-fgw)。
**注意**
閘道主控台的預設登入使用者名稱為 `admin`，預設密碼為 `password`。
### 確保防火牆安全不會修改從閘道傳送至公有端點的封包
SSL 檢查、深度封包檢查或其他形式的防火牆安全可能會干擾從閘道傳送的封包。如果從啟用端點預期修改 SSL 憑證，則 SSL 交握會失敗。若要確認沒有進行中的 SSL 檢查，請在連接埠 443 的主要啟用端點 (`anon-cp.storagegateway.region.amazonaws.com`) 上執行 OpenSSL 命令。您必須從與閘道位於相同子網路的機器執行此命令：
```
$ openssl s_client -connect anon-cp.storagegateway.region.amazonaws.com:443 -servername anon-cp.storagegateway.region.amazonaws.com
```
**注意**
將*區域*取代為您的 AWS 區域。
如果沒有進行中的 SSL 檢查，則命令會傳回類似如下的回應：
```
$ openssl s_client -connect anon-cp.storagegateway.us-east-2.amazonaws.com:443 -servername anon-cp.storagegateway.us-east-2.amazonaws.com
CONNECTED(00000003)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-2.amazonaws.com
verify return:1
---
Certificate chain
0 s:/CN=anon-cp.storagegateway.us-east-2.amazonaws.com
i:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
1 s:/C=US/O=Amazon/OU=Server CA 1B/CN=Amazon
i:/C=US/O=Amazon/CN=Amazon Root CA 1
2 s:/C=US/O=Amazon/CN=Amazon Root CA 1
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
3 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2
i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority
---
```
如果有持續的 SSL 檢查，回應會顯示已變更的憑證鏈，如下所示：
```
$ openssl s_client -connect anon-cp.storagegateway.ap-southeast-1.amazonaws.com:443 -servername anon-cp.storagegateway.ap-southeast-1.amazonaws.com
CONNECTED(00000003)
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.ap-southeast-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.ap-southeast-1.amazonaws.com
i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```
啟用端點只有在識別 SSL 憑證時，才會接受 SSL 交握。這表示閘道對端點的傳出流量必須不受網路中防火牆執行的檢查。這些檢查可能是 SSL 檢查或深度封包檢查。
### 檢查閘道時間同步
時間過長可能會導致 SSL 交握錯誤。對於內部部署閘道，您可以使用閘道的本機 VM 主控台來檢查閘道的時間同步。時間扭曲不應大於 60 秒。如需詳細資訊，請參閱[同步閘道 VM TimeSynchronizing](https://docs.aws.amazon.com/filegateway/latest/files3/MaintenanceTimeSync-hyperv.html)。
**系統時間管理**選項不適用於在 Amazon EC2 執行個體上託管的閘道。為了確保 Amazon EC2 閘道可以正確同步時間，請確認 Amazon EC2 執行個體可以透過連接埠 UDP 和 TCP 123 連線至下列 NTP 伺服器集區清單：
+ time.aws.com
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org
## 解決使用 Amazon VPC 端點啟用閘道時的錯誤
若要解決使用 Amazon Virtual Private Cloud (Amazon VPC) 端點啟用閘道時的啟用錯誤，請執行下列檢查和組態。
### 檢查所需的連接埠
確定本機防火牆 （適用於內部部署的閘道） 或安全群組 （適用於 Amazon EC2 中部署的閘道） 內的必要連接埠已開啟。將閘道連線至 Storage Gateway VPC 端點所需的連接埠，與將閘道連線至公有端點時所需的連接埠不同。連線至 Storage Gateway VPC 端點需要下列連接埠：
+ TCP 443
+ TCP 1026
+ TCP 1027
+ TCP 1028
+ TCP 1031
+ TCP 2222
如需詳細資訊，請參閱[建立 Storage Gateway 的 VPC 端點](https://docs.aws.amazon.com/filegateway/latest/files3/gateway-private-link.html#create-vpc-endpoint)建立 Storage Gateway 的 VPC 端點。
此外，請檢查連接至 Storage Gateway VPC 端點的安全群組。連接至端點的預設安全群組可能不允許必要的連接埠。建立新的安全群組，允許來自閘道 IP 地址範圍的流量通過所需的連接埠。然後，將該安全群組連接到 VPC 端點。
**注意**
使用 [Amazon VPC 主控台](https://console.aws.amazon.com//vpc/)來驗證連接到 VPC 端點的安全群組。從主控台檢視 Storage Gateway VPC 端點，然後選擇**安全群組**索引標籤。
若要確認所需的連接埠已開啟，您可以在 Storage Gateway VPC 端點上執行 telnet 命令。您必須從與閘道位於相同子網路的伺服器執行這些命令。您可以在未指定可用區域的第一個 DNS 名稱上執行測試。例如，下列 telnet 命令會使用 DNS 名稱 vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 測試所需的連接埠連線：
```
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 443
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1026
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1027
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1028
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 1031
telnet vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com 2222
```
### 確保防火牆安全不會修改從閘道傳送至 Storage Gateway Amazon VPC 端點的封包
SSL 檢查、深度封包檢查或其他形式的防火牆安全可能會干擾從閘道傳送的封包。如果從啟用端點預期修改 SSL 憑證，則 SSL 交握會失敗。若要確認沒有進行中的 SSL 檢查，請在 Storage Gateway VPC 端點上執行 OpenSSL 命令。您必須從與閘道位於相同子網路的機器執行此命令。為每個必要的連接埠執行 命令：
```
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:443 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1026 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1028 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1031 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
$ openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:2222 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
```
如果沒有進行中的 SSL 檢查，則命令會傳回類似如下的回應：
```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify return:1
---
Certificate chain
0 s:CN = anon-cp.storagegateway.us-east-1.amazonaws.com
i:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
1 s:C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
i:C = US, O = Amazon, CN = Amazon Root CA 1
2 s:C = US, O = Amazon, CN = Amazon Root CA 1
i:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
3 s:C = US, ST = Arizona, L = Scottsdale, O = "Starfield Technologies, Inc.", CN = Starfield Services Root Certificate Authority - G2
i:C = US, O = "Starfield Technologies, Inc.", OU = Starfield Class 2 Certification Authority
---
```
如果有持續的 SSL 檢查，回應會顯示已變更的憑證鏈，如下所示：
```
openssl s_client -connect vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com:1027 -servername vpce-1234567e1c24a1fe9-62qntt8k.storagegateway.us-east-1.vpce.amazonaws.com
CONNECTED(00000005)
depth=2 C = US, O = Amazon, CN = Amazon Root CA 1
verify return:1
depth=1 C = US, O = Amazon, OU = Server CA 1B, CN = Amazon
verify return:1
depth=0 DC = com, DC = amazonaws, OU = AWS, CN = anon-cp.storagegateway.us-east-1.amazonaws.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/DC=com/DC=amazonaws/OU=AWS/CN=anon-cp.storagegateway.us-east-1.amazonaws.com
i:/C=IN/O=Company/CN=Admin/ST=KA/L=New town/OU=SGW/emailAddress=admin@company.com
---
```
啟用端點只有在識別 SSL 憑證時，才會接受 SSL 交握。這表示閘道透過所需連接埠傳出至 VPC 端點的流量不受網路防火牆執行的檢查影響。這些檢查可能是 SSL 檢查或深度封包檢查。
### 檢查閘道時間同步
時間過長可能會導致 SSL 交握錯誤。對於內部部署閘道，您可以使用閘道的本機 VM 主控台來檢查閘道的時間同步。時間扭曲不應大於 60 秒。如需詳細資訊，請參閱[同步閘道 VM TimeSynchronizing](https://docs.aws.amazon.com/filegateway/latest/files3/MaintenanceTimeSync-hyperv.html)。
**系統時間管理**選項不適用於在 Amazon EC2 執行個體上託管的閘道。為了確保 Amazon EC2 閘道可以正確同步時間，請確認 Amazon EC2 執行個體可以透過連接埠 UDP 和 TCP 123 連線至下列 NTP 伺服器集區清單：
+ 0.amazon.pool.ntp.org
+ 1.amazon.pool.ntp.org
+ 2.amazon.pool.ntp.org
+ 3.amazon.pool.ntp.org
### 檢查 HTTP 代理並確認相關聯的安全群組設定
啟用之前，請檢查 Amazon EC2 上的 HTTP 代理是否已在內部部署閘道 VM 上設定為連接埠 3128 上的 Squid 代理。在此情況下，請確認下列事項：
+ 連接至 Amazon EC2 上 HTTP 代理的安全群組必須具有傳入規則。此傳入規則必須允許來自閘道 VM IP 地址之連接埠 3128 上的 Squid 代理流量。
+ 連接至 Amazon EC2 VPC 端點的安全群組必須具有傳入規則。這些傳入規則必須允許連接埠 1026-1028、1031、2222 和 443 上來自 Amazon EC2 上 HTTP 代理的 IP 地址的流量。
## 解決使用公有端點啟用閘道，且相同 VPC 中有 Storage Gateway VPC 端點時的錯誤
若要解決在相同 VPC 中有 Amazon Virtual Private Cloud (Amazon VPC) 點時，使用公有端點啟用閘道時的錯誤，請執行下列檢查和組態。
### 確認 Storage Gateway VPC 端點上未啟用**啟用私有 DNS 名稱**設定
如果啟用**私有 DNS 名稱**已啟用，您就無法啟用從該 VPC 到公有端點的任何閘道。
**若要停用私有 DNS 名稱選項：**
1. 開啟 [Amazon VPC 主控台](https://console.aws.amazon.com//vpc/)。
1. 在導覽窗格中選擇**端點**。
1. 選擇 Storage Gateway VPC 端點。
1. 選擇**動作**。
1. 選擇**管理私有 DNS 名稱**。
1. 針對**啟用私有 DNS 名稱**，清除**此端點的啟用**。
1. 選擇**修改私有 DNS 名稱**以儲存設定。
# 故障診斷：內部部署閘道問題
您可以在下面找到有關使用現場部署閘道時可能遇到的典型問題的資訊，以及如何允許 支援 連接到您的閘道以協助故障診斷。
下表列出使用內部部署閘道時一般可能遇到的問題。
| 問題 | 採取動作 |
| --- | --- |
| 您找不到閘道的 IP 地址。 | 使用虛擬化管理程序用戶端連線到您的主機，尋找閘道 IP 地址。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) 如果仍找不到閘道 IP 地址： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) |
| 您有網路或防火牆的問題。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) |
| 當您在 Storage Gateway 管理主控台中按一下**繼續啟用**按鈕時，您的閘道啟用會失敗。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) |
| 您需要改善閘道與 AWS之間的頻寬。 | 您可以在與連接應用程式和閘道 VM 分開的網路轉接器 (NIC) AWS 上設定 的網際網路連線， AWS 以改善從閘道到 的頻寬。如果您與 有高頻寬連線， AWS 而且想要避免頻寬爭用，尤其是在快照還原期間，採取此方法非常有用。對於高輸送量工作負載的需求，您可以使用 [Direct Connect](https://aws.amazon.com/directconnect/) 在內部部署閘道和 AWS之間建立專用網路連線。若要測量閘道連線的頻寬 AWS，請使用閘道的 `CloudBytesDownloaded`和 `CloudBytesUploaded`指標。如需此主題的詳細資訊，請參閱[效能和最佳化](Performance.md)。提升網際網路連線能力有助於確保您的上傳緩衝區不會用盡。 |
| 閘道的出入輸送量降到零。 | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-on-premises-gateway-issues.html) 您可以從 Amazon CloudWatch 主控台檢視在您閘道出入的輸送量。如需測量閘道與 之間傳輸量的詳細資訊 AWS，請參閱 [效能和最佳化](Performance.md)。 |
| 您無法在 Microsoft Hyper-V 匯入 (部署) Storage Gateway。 | 請參閱 [故障診斷：Microsoft Hyper-V 設定](troubleshooting-hyperv-setup.md)，以了解在 Microsoft Hyper-V 部署閘道的常見問題。 |
| 您會收到以下訊息：「The data that has been written to the volume in your gateway isn't securely stored at AWS」。 | 如果您的閘道 VM 是從另一個閘道 VM 的複製或快照所建立，就會收到此訊息。如果不是這種情況，請聯絡 支援。 |
## 故障診斷：安全性掃描會顯示開放的 NFS 連接埠
某些 NFS 連接埠預設為啟用，即使在僅與 SMB 檔案共用搭配使用的閘道上也是如此。如果您使用第三方安全軟體，例如 Qualys 來掃描部署檔案閘道的網路，掃描結果可能會將這些開放的 NFS 連接埠報告為潛在的安全漏洞。如果您只將閘道與 SMB 檔案共用搭配使用，而且基於安全考量，您想要停用未使用的 NFS 連接埠，請使用下列程序：
**若要停用檔案閘道上的 NFS 連接埠：**
1. 使用 中概述的程序存取閘道本機主控台命令提示字元[在本機主控台上執行 Storage Gateway 命令](MaintenanceGatewayConsole-fgw.md)。
1. 輸入下列命令以停用 NFS 流量：
**IPv4**
```
iptables -I INPUT -p udp -m udp --dport 111 -j DROP
iptables -I INPUT -p udp -m udp --dport 2049 -j DROP
iptables -I INPUT -p udp -m udp --dport 20048 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
**IPv6**
```
ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
1. 輸入下列命令以確認封鎖的 NFS 連接埠出現在 IP 資料表中：
**IPv4**
```
iptables -n -L -v --line-numbers
```
**IPv6**
```
ip6tables -n -L -v --line-numbers
```
## 開啟 支援 存取權，以協助對內部部署託管的閘道進行故障診斷
Storage Gateway 提供本機主控台，您可以用來執行數個維護任務，包括允許 支援 存取您的閘道，以協助您疑難排解閘道問題。根據預設，對閘道的 支援 存取會關閉。您可以透過主機的本機主控台開啟此存取權。若要允許 支援 存取您的閘道，請先登入主機的本機主控台，導覽至 Storage Gateway 的主控台，然後連線至支援伺服器。
**開啟對閘道的 支援 存取**
1. 登入您主機的本機主控台。
+ VMware ESXi：如需詳細資訊，請參閱 [使用 VMware ESXi 存取閘道本機主控台](accessing-local-console.md#MaintenanceConsoleWindowVMware-common)。
+ Microsoft Hyper-V：如需詳細資訊，請參閱 [使用 Microsoft Hyper-V 存取閘道本機主控台](accessing-local-console.md#MaintenanceConsoleWindowHyperV-common)。
1. 出現提示時，輸入對應的數字以選取**閘道組態**。
1. 輸入 **h** 以開啟可用命令視窗。
1.
執行以下任意一項：
+ 如果您的閘道使用公有端點，請在**可用命令**視窗中輸入 **open-support-channel** 來連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
+ 如果您的閘道使用 VPC 端點，請在**可用命令**視窗中輸入 **open-support-channel**。如果您的閘道未啟用，請提供 VPC 端點或 IP 地址以連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
**注意**
此管道號碼不是傳輸控制通訊協定/使用者資料包通訊協定 (TCP/UDP) 連接埠號碼。反之，閘道以 Secure Shell (SSH) (TCP 22) 連線到 Storage Gateway 伺服器，並提供此連線的支援管道。
1. 建立支援管道之後，請將支援服務號碼提供給 ， 支援 以便 支援 可以提供故障診斷協助。
1. 當支援工作階段完成時，請輸入 **q** 將其結束。在 Amazon Web Services Support 通知您支援工作階段完成之前，請勿關閉工作階段。
1. 輸入 **exit** 以登出 Storage Gateway 主控台。
1. 依照提示結束本機主控台。
# 故障診斷：Microsoft Hyper-V 設定
在 Microsoft Hyper-V 平台上部署 Storage Gateway 時通常可能會遇到的問題如下表所列。
| 問題 | 採取動作 |
| --- | --- |
| 您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。在位置 【...】 下找不到虛擬機器匯入檔案。只有在使用 Hyper-V 建立和匯出虛擬機器時，才能匯入虛擬機器。」 | 此錯誤的發生原因如下： [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_tw/filegateway/latest/files3/troubleshooting-hyperv-setup.html) |
| 您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。匯入任務無法從 【...】 複製檔案：檔案存在。(0x80070050)" | 如已部署閘道，而您嘗試重複使用存放虛擬硬碟檔案和虛擬機器組態檔案的預設資料夾，則會發生此錯誤。若要修正此問題，請在 **Hyper-V 設定**對話方塊左側面板的**伺服器**下指定新位置。 |
| 您嘗試匯入閘道並收到下列錯誤訊息： 「嘗試匯入虛擬機器時發生伺服器錯誤。匯入失敗。Import failed because the virtual machine must have a new identifier. Select a new identifier and try the import again."。 | 當您匯入閘道時，請務必選取**複製虛擬機器**，並勾選**匯入虛擬機器**對話方塊中的**複製所有檔案**方塊，為虛擬機器建立新的唯一 ID。 |
| 您嘗試啟動閘道 VM 並收到下列錯誤訊息： （嘗試啟動） 選取的虛擬機器時發生錯誤。子分割區處理器設定與父分割區不相容。'AWS-Storage-Gateway' 無法初始化。（虛擬機器 ID 【...】) | 此錯誤可能是因為閘道所需 CPU 和主機可用 CPU 之間的 CPU 差異所造成。請確定基礎虛擬化管理程序支援 VM CPU 計數。 如需關於 Storage Gateway 需求的詳細資訊，請參閱 [檔案閘道設定需求](Requirements.md)。 |
| 您嘗試啟動閘道 VM 並收到下列錯誤訊息： （嘗試啟動） 選取的虛擬機器時發生錯誤。'AWS-Storage-Gateway' 無法初始化。（虛擬機器 ID 【...】) 無法建立分割區：系統資源不足，無法完成請求的服務。(0x800705AA)" | 此錯誤可能是因為閘道所需 RAM 和主機可用 RAM 之間的 RAM 差異所造成。 如需關於 Storage Gateway 需求的詳細資訊，請參閱 [檔案閘道設定需求](Requirements.md)。 |
| 您的快照和閘道軟體更新出現的次數會和預期的稍有不同。 | 閘道 VM 的時鐘可能會從實際的時間偏移，稱為時鐘飄移。請使用本機閘道主控台的時間同步選項，檢查並更正 VM 的時間。如需詳細資訊，請參閱[為您的閘道設定網路時間通訊協定 (NTP) 伺服器](MaintenanceTimeSync-fgw.md)。 |
| 您需要將解壓縮的 Microsoft Hyper-V Storage Gateway 檔案放在主機的檔案系統。 | 像您對一般 Microsoft Windows 伺服器所做的一樣，存取主機。例如，如果虛擬化管理程序主機名為 `hyperv-server`，則您可使用以下 UNC 路徑 `\\hyperv-server\c$`，其假設 `hyperv-server` 名稱可在本機主機檔案中解析或定義。 |
| 連線到虛擬化管理程序時，系統會提示您提供登入資料。 | 使用 Sconfig.cmd 工具新增您的使用者登入資料，做為虛擬化管理程序主機的本機管理員。 |
| 如果您為使用 Broadcom 網路轉接器的 Hyper-V 主機開啟虛擬機器佇列 (VMQ)，您可能會注意到網路效能不佳。 | 如需解決方法的相關資訊，請參閱 Microsoft 文件，請參閱[開啟 VMQ 時 Windows Server 2012 Hyper-V 主機上虛擬機器的網路效能不佳](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/poor-network-performance-hyper-v-host-vm)。 |
# 故障診斷：Amazon EC2 閘道問題
在下列各節中，您會發現使用部署在 Amazon EC2 的閘道時，一般可能遇到的問題。如需內部部署閘道和部署在 Amazon EC2 閘道兩者間之差異的詳細資訊，請參閱 [部署 S3 檔案閘道的預設 Amazon EC2 主機部署適用於 S3 檔案閘道的自訂 Amazon EC2 主機](ec2-gateway-file.md)。
如需使用暫時性儲存的詳細資訊，請參閱[搭配 EC2 閘道使用暫時性儲存](ephemeral-disk-cache.md)。
**Topics**
+ [您的閘道在一段時間後仍未啟用](#activation-issues)
+ [執行個體清單中找不到您的 EC2 閘道執行個體](#find-instance)
+ [使用 Amazon EC2 序列主控台連接到您的閘道執行個體](#ec2-serial-console)
+ [支援 您想要協助疑難排解 Amazon EC2 閘道](#EC2-EnableAWSSupportAccess)
## 您的閘道在一段時間後仍未啟用
在 Amazon EC2 主控台中，檢查以下項目：
+ 連接埠 80 會在您與該執行個體相關聯的安全群組中開啟。如需新增安全群組規則的詳細資訊，請參閱《*Amazon EC2 使用者指南*》中的[新增安全群組規則](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-security-groups.html#adding-security-group-rule)。
+ 閘道執行個體標示為執行中。在 Amazon EC2 主控台中，執行個體的**狀態**值應為執行中。
+ 請確保您的 Amazon EC2 執行個體類型符合最低要求，如 [儲存需求](Requirements.md#requirements-storage) 所述。
更正問題後，請嘗試再次啟動閘道。若要執行此操作，請開啟 Storage Gateway 主控台，選擇**在 Amazon EC2 上部署新的閘道**，然後重新輸入執行個體的 IP 地址。
## 執行個體清單中找不到您的 EC2 閘道執行個體
如果您並未建立執行個體的資源標籤，又有許多執行個體正在執行，要分辨您啟動了哪些執行個體會十分困難。在這種情況下，您可以執行以下動作，尋找閘道執行個體：
+ 在執行個體的**描述**標籤上檢查 Amazon Machine Image (AMI) 的名稱。以 Storage Gateway AMI 為基礎的執行個體的開頭文字應為 **aws-storage-gateway-ami**。
+ 如果您有數個以 Storage Gateway AMI 為基礎的執行個體，請檢查執行個體的啟動時間，以尋找正確的執行個體。
## 使用 Amazon EC2 序列主控台連接到您的閘道執行個體
您可以使用 Amazon EC2 序列主控台來疑難排解開機、網路設定和其他問題。如需指示和疑難排解秘訣，請參閱*《Amazon 彈性運算雲端使用者指南》*中的 [Amazon EC2 序列主控台](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html)。
## 支援 您想要協助疑難排解 Amazon EC2 閘道
Storage Gateway 提供本機主控台，您可以用來執行數個維護任務，包括允許 支援 存取您的閘道，以協助您疑難排解閘道問題。根據預設，對閘道的 支援 存取會關閉。您可以透過 Amazon EC2 本機主控台開啟此存取權。您可以透過 Secure Shell (SSH) 登入 Amazon EC2 本機主控台。若要透過 SSH 成功登入，您執行個體的安全群組必須有開啟 TCP 連接埠 22 的規則。
**注意**
如果您將新的規則新增至現有的安全群組，新的規則將套用到使用該安全群組的所有執行個體。如需安全群組以及如何新增安全群組規則的詳細資訊，請參閱《Amazon EC2 使用者指南》**中的 [Amazon EC2 安全群組](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)。
若要讓 支援 連線至您的閘道，請先登入 Amazon EC2 執行個體的本機主控台，導覽至 Storage Gateway 的主控台，然後提供存取權。
**開啟在 Amazon EC2 執行個體上部署之閘道的 支援 存取**
1. 登入 Amazon EC2 執行個體的本機主控台。如需說明，請參閱《Amazon EC2 使用者指南》**中的[連線到您的執行個體](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstances.html)。
您可以使用以下命令登入 EC2 執行個體的本機主控台。
```
ssh –i PRIVATE-KEY admin@INSTANCE-PUBLIC-DNS-NAME
```
**注意**
*PRIVATE-KEY* 是 `.pem` 檔案，其中包含 EC2 金鑰對的私有憑證，您可用來啟動 Amazon EC2 執行個體。如需詳細資訊，請參閱《Amazon EC2 使用者指南》**中的[擷取金鑰對的公有金鑰](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#retriving-the-public-key)。
*INSTANCE-PUBLIC-DNS-NAME* 是用於執行閘道之 Amazon EC2 執行個體的公有網域名稱系統 (DNS) 名稱。您可以在 EC2 主控台中選取 Amazon EC2 執行個體，然後按一下**描述**標籤以取得此公有 DNS 名稱。
1. 出現提示時，輸入 **6 - Command Prompt** 以開啟 支援 管道主控台。
1. 輸入 **h** 以開啟**可用命令**視窗。
1. 執行以下任意一項：
+ 如果您的閘道使用公有端點，請在**可用命令**視窗中輸入 **open-support-channel** 來連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
+ 如果您的閘道使用 VPC 端點，請在**可用命令**視窗中輸入 **open-support-channel**。如果您的閘道未啟用，請提供 VPC 端點或 IP 地址以連線到 Storage Gateway 的客戶支援。允許 TCP 連接埠 22，即可開啟 AWS的支援管道。當您連線到客戶支援時，Storage Gateway 會指派一個支援號碼給您。請記下您的支援號碼。
**注意**
此管道號碼不是傳輸控制通訊協定/使用者資料包通訊協定 (TCP/UDP) 連接埠號碼。反之，閘道以 Secure Shell (SSH) (TCP 22) 連線到 Storage Gateway 伺服器，並提供此連線的支援管道。
1. 建立支援管道之後，請將支援服務號碼提供給 ， 支援 以便 支援 可以提供故障診斷協助。
1. 當支援工作階段完成時，請輸入 **q** 將其結束。在 Amazon Web Services Support 通知您支援工作階段完成之前，請勿關閉工作階段。
1. 輸入 **exit** 以結束 Storage Gateway 主控台。
1. 依照主控台選單操作登出 Storage Gateway 執行個體。
# 故障診斷：硬體設備問題
**注意**
可用性終止通知：自 2025 年 5 月 12 日起，將不再提供 AWS Storage Gateway 硬體設備。硬體 AWS Storage Gateway 設備的現有客戶可以繼續使用和獲得支援，直到 2028 年 5 月為止。或者，您可以使用 AWS Storage Gateway 服務為應用程式提供現場部署和雲端存取幾乎無限制的雲端儲存。
下列主題討論您使用 AWS Storage Gateway硬體設備時可能遇到的問題，以及疑難排解這些問題的建議。
**Topics**
+ [您無法確定服務 IP 地址](#service_ip_address)
+ [如何執行重設成出廠預設值？](#factory_reset)
+ [如何執行遠端重新啟動？](#remote-restart)
+ [哪裡可以取得 Dell iDRAC 支援？](#iDRAC_support)
+ [您找不到硬體設備序號](#appliance_serial_number)
+ [在何處取得硬體設備支援](#appliance_support)
## 您無法確定服務 IP 地址
嘗試連接到服務時，請務必使用服務的 IP 地址，而非主機 IP 地址。在服務主控台中設定服務 IP 地址，並在硬體主控台設定主機 IP 地址。當您啟動硬體設備時會看到硬體主控台。若要從硬體主控台前往服務主控台，請選擇 **Open Service Console (開啟服務主控台)**。
## 如何執行重設成出廠預設值？
如果您需要在設備上執行原廠重設，請聯絡 AWS Storage Gateway硬體設備團隊以取得支援，如以下支援一節所述。
## 如何執行遠端重新啟動？
如果您需要執行裝置的遠端重新啟動，可以使用 Dell iDRAC 管理介面來執行此作業。如需詳細資訊，請參閱 Dell Technologies InfoHub 網站上的 [iDRAC9 虛擬電源重啟：遠端重啟 Dell EMC PowerEdge 伺服器電源](https://infohub.delltechnologies.com/en-us/p/idrac9-virtual-power-cycle-remotely-power-cycle-dell-emc-poweredge-servers/)。
## 哪裡可以取得 Dell iDRAC 支援？
Dell PowerEdge 伺服器隨附 Dell iDRAC 管理介面。我們建議下列作法：
+ 如果您使用 iDRAC 管理介面，則應變更預設密碼。如需關於 iDRAC 認證的詳細資訊，請參閱 [Dell PowerEdge - 什麼是 iDRAC 的預設登入憑證？](https://www.dell.com/support/article/en-us/sln306783/dell-poweredge-what-is-the-default-username-and-password-for-idrac?lang=en)
+ 請確定韌體是最新狀態，以防止安全漏洞。
+ 將 iDRAC 網路界面移到一般 (`em`) 連接埠，可能導致效能問題或阻止裝置正常運作。
## 您找不到硬體設備序號
您可以使用 AWS Storage Gateway 主控台找到Storage Gateway閘道硬體設備的序號。
**若要尋找硬體設備序號：**
1. 前往 [https://console.aws.amazon.com/storagegateway/home](https://console.aws.amazon.com/storagegateway/) 開啟 Storage Gateway 主控台。
1. 在頁面左側的導覽窗格選擇**硬體**。
1. 從清單中選擇您的硬體設備。
1. 在設備**的詳細資訊**索引標籤上尋找**序號**欄位。
## 在何處取得硬體設備支援
若要聯絡 AWS 以取得硬體設備的技術支援，請參閱 [支援](https://aws.amazon.com/contact-us)。
支援 團隊可能會要求您啟用支援管道，以遠端疑難排解您的閘道問題。不需要將此連接埠開放給閘道的正常操作使用，但進行疑難排解時需要用到。您可以從硬體主控台啟用支援管道，如以下程序所示。
**開啟 的支援管道 AWS**
1. 開啟硬體主控台。
1. 選擇硬體主控台主頁面底部的**開啟支援管道**，然後按 `Enter`。
如果沒有網路連線或防火牆問題，指派的連接埠號碼應該會在 30 秒內顯示。例如：
**狀態：在連接埠 19599 上開啟**
1. 請記下連接埠號碼並將其提供給 支援。
# 故障診斷：檔案閘道問題
您可以設定檔案閘道，將日誌項目寫入 Amazon CloudWatch 日誌群組。如果您這樣做，您會收到有關閘道運作狀態和閘道遇到之任何錯誤的通知。您可以在 CloudWatch Logs 中找到這些錯誤和運作狀態通知的相關資訊。
在下列各節，您可以找到相關資訊，協助您了解每個錯誤的原因、運作狀態通知，以及修正問題的方法。
**Topics**
+ [錯誤：1344 (0x00000540)](#troubleshoot-copying-files-to-s3)
+ [錯誤：GatewayClockOutOfSync](#troubleshoot-logging-errors-gatewayclockoutofsync)
+ [錯誤：InaccessibleStorageClass](#troubleshoot-logging-errors-inaccessiblestorageclass)
+ [錯誤：InvalidObjectState](#troubleshoot-logging-errors-invalidobjectstate)
+ [錯誤：ObjectMissing](#troubleshoot-logging-errors-objectmissing)
+ [錯誤：RoleTrustRelationshipInvalid](#misconfig-trust)
+ [錯誤：S3AccessDenied](#troubleshoot-logging-errors-s3accessdenied)
+ [錯誤：DroppedNotifications](#troubleshoot-logging-errors-droppednotifications)
+ [通知：HardReboot](#troubleshoot-hardreboot-notification)
+ [通知：重新啟動](#troubleshoot-reboot-notification)
+ [故障診斷：安全掃描會顯示開放的 NFS 連接埠](#troubleshoot-open-nfs-ports)
+ [故障診斷：使用 CloudWatch 指標](#troubleshooting-with-cw-metrics)
## 錯誤：1344 (0x00000540)
在將檔案遷移至 Amazon S3 時，`ERROR 1344 (0x00000540)`如果您嘗試將超過 10 個存取控制項目 (ACEs) 的檔案複製到 Amazon S3，您可能會遇到 。存取控制項目會列在存取控制清單 (ACL) 中。
Amazon S3 File Gateway 每個指定的檔案或資料夾只能保留 10 個 ACE 項目。
**解決錯誤 1344：將 NTFS 安全性複製到目的地目錄。**
針對包含超過 10 個項目的檔案或資料夾，減少 Windows 許可中的項目數量。常見的方法是建立包含項目完整清單的群組，然後使用該單一群組取代項目清單。一旦項目數量小於 10，您可以重試將檔案或資料夾複製到閘道。
## 錯誤：GatewayClockOutOfSync
當閘道偵測到本機系統時間和 AWS Storage Gateway伺服器報告的時間之間有 5 分鐘或更多的差異時，您可能會收到`GatewayClockOutOfSync`錯誤。時鐘同步問題可能會對閘道與 之間的連線產生負面影響 AWS。如果閘道時鐘不同步，NFS 和 SMB 連線可能會發生 I/O 錯誤，而 SMB 使用者可能會發生身分驗證錯誤。
**解決 GatewayClockOutOfSync 錯誤**
+ 檢查閘道和 NTP 伺服器之間的網路組態。如需同步閘道 VM 時間和更新 NTP 伺服器組態的詳細資訊，請參閱[為您的閘道設定網路時間協定 (NTP) 伺服器](https://docs.aws.amazon.com/filegateway/latest/files3/manage-on-premises-fgw.html#MaintenanceTimeSync-fgw)。
## 錯誤：InaccessibleStorageClass
當物件移出 Amazon S3 Standard 儲存類別時，您可能會收到`InaccessibleStorageClass`錯誤。
檔案閘道通常會在嘗試將物件上傳至 或從 Amazon S3 儲存貯體讀取物件時遇到此錯誤。一般而言，此錯誤表示物件已移至 Amazon Glacier，且位於 S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 儲存類別。
您的 S3 檔案閘道可以產生快取報告，列出閘道快取中目前因此錯誤而無法上傳至 Amazon S3 的所有檔案。此報告中的資訊可協助您使用 支援 來解決閘道、Amazon S3 或 IAM 組態的問題。如需詳細資訊，請參閱[建立快取報告](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)。
**解決 InaccessibleStorageClass 錯誤**
+ 將物件從 S3 Glacier Flexible Retrieval 或 S3 Glacier Deep Archive 儲存類別還原至 S3 中的原始儲存類別。
如果您將物件還原至 S3 儲存貯體以修正上傳錯誤，則檔案最終會上傳。如果您還原物件以修正讀取錯誤，檔案閘道的 SMB 或 NFS 用戶端即可讀取檔案。
## 錯誤：InvalidObjectState
當指定檔案閘道以外的寫入器修改指定 Amazon S3 儲存貯體中的指定檔案時，您可能會收到`InvalidObjectState`錯誤。因此，檔案閘道的檔案狀態與 Amazon S3 中的檔案狀態不相符。任何檔案後續上傳至 Amazon S3 或從 Amazon S3 擷取檔案都會失敗。
您的 S3 檔案閘道可以產生快取報告，列出閘道快取中目前因此錯誤而無法上傳至 Amazon S3 的所有檔案。此報告中的資訊可協助您使用 支援 來解決閘道、Amazon S3 或 IAM 組態的問題。如需詳細資訊，請參閱[建立快取報告](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)。
**解決 InvalidObjectState 錯誤**
如果修改檔案的操作是 `S3Upload`或 `S3GetObject`，請執行下列動作：
1. 將檔案的最新副本儲存至 SMB 或 NFS 用戶端的本機檔案系統 （您需要在步驟 4 中使用此檔案副本）。如果 Amazon S3 中的 檔案版本是最新版本，請下載該版本。您可以使用 AWS 管理主控台 或 來執行此操作 AWS CLI。
1. 使用 AWS 管理主控台 或 在 Amazon S3 中刪除 檔案 AWS CLI。
1. 使用 SMB 或 NFS 用戶端從檔案閘道刪除檔案。
1. 使用 SMB 或 NFS 用戶端，將您在步驟 1 中儲存的最新版本檔案複製到 Amazon S3。透過您的檔案閘道執行此操作。
## 錯誤：ObjectMissing
當指定檔案閘道以外的寫入器從 S3 儲存貯體刪除指定的檔案時，您可能會收到`ObjectMissing`錯誤。任何後續上傳至 Amazon S3 或從 Amazon S3 擷取物件都會失敗。
您的 S3 檔案閘道可以產生快取報告，列出閘道快取中目前因此錯誤而無法上傳至 Amazon S3 的所有檔案。此報告中的資訊可協助您使用 支援 來解決閘道、Amazon S3 或 IAM 組態的問題。如需詳細資訊，請參閱[建立快取報告](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)。
**解決 ObjectMissing 錯誤**
如果修改檔案的操作是 `S3Upload`或 `S3GetObject`，請執行下列動作：
1. 將檔案的最新副本儲存至 SMB 或 NFS 用戶端的本機檔案系統 （您需要在步驟 3 中使用此檔案副本）。
1. 使用 SMB 或 NFS 用戶端從檔案閘道刪除檔案。
1. 使用 SMB 或 NFS 用戶端複製您在步驟 1 中儲存的最新版本檔案。透過您的檔案閘道執行此操作。
## 錯誤：RoleTrustRelationshipInvalid
當檔案共享的 IAM 角色具有設定錯誤的 IAM 信任關係 （亦即，IAM 角色不信任名為 的 Storage Gateway 主體`storagegateway.amazonaws.com`) 時，您會收到此錯誤。因此，檔案閘道將無法取得登入資料，在支援檔案共用的 S3 儲存貯體上執行任何操作。
**解決 RoleTrustRelationshipInvalid 錯誤**
+ 使用 IAM 主控台或 IAM API 將 納入`storagegateway.amazonaws.com`為檔案共享 IAMrole 信任的委託人。如需 IAM 角色的資訊，請參閱[教學課程：使用 IAM 角色將存取權委派給 AWS 帳戶](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)。
## 錯誤：S3AccessDenied
您可能會收到檔案共享的 Amazon S3 儲存貯體存取 AWS Identity and Access Management (IAM) 角色的`S3AccessDenied`錯誤。在此情況下，錯誤`roleArn`中由 指定的 S3 儲存貯體存取 IAM 角色不允許涉及的操作。由於 Amazon S3 字首所指定目錄中物件的許可，因此不允許 操作。
您的 S3 檔案閘道可以產生快取報告，列出閘道快取中目前因此錯誤而無法上傳至 Amazon S3 的所有檔案。此報告中的資訊可協助您使用 支援 來解決閘道、Amazon S3 或 IAM 組態的問題。如需詳細資訊，請參閱[建立快取報告](https://docs.aws.amazon.com/filegateway/latest/files3/create-cache-report.html)。
**解決 S3AccessDenied 錯誤**
+ 修改檔案閘道運作狀態日誌`roleArn`中連接至 的 Amazon S3 存取政策，以允許 Amazon S3 操作的許可。請確認存取政策可允許導致該錯誤的操作許可。此外，請允許 `prefix` 之日誌中所指定的目錄許可。如需 Amazon S3 許可的相關資訊，請參閱《Amazon Simple Storage Service 使用者指南》中的在[政策中指定許可](https://docs.aws.amazon.com/AmazonS3/latest/dev/using-with-s3-actions.html)。 **
這些操作可能會導致 `S3AccessDenied` 錯誤發生：
+ `S3HeadObject`
+ `S3GetObject`
+ `S3ListObjects`
+ `S3DeleteObject`
+ `S3PutObject`
## 錯誤：DroppedNotifications
當閘道根磁碟上的可用儲存空間小於 1 GB，或在 1 分鐘內產生超過 100 個運作狀態通知時，您可能會看到`DroppedNotifications`錯誤，而不是其他預期的 CloudWatch 日誌項目類型。在這些情況下，閘道會停止產生詳細的 CloudWatch 日誌通知做為預防措施。
**解決 DroppedNotifications 錯誤**
1. 檢查 Storage Gateway `Root Disk Usage` 主控台中閘道的**監控**索引標籤上的指標，以判斷可用的根磁碟空間是否不足。
1. 如果可用空間小於 1 GB，請增加閘道根儲存磁碟的大小。如需說明，請參閱虛擬機器 Hypervisor 的文件。
若要增加 Amazon EC2 閘道的根磁碟大小，請參閱《*Amazon Elastic Compute Cloud 使用者指南*》中的[請求修改 EBS 磁碟區](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/requesting-ebs-volume-modifications.html)。
**注意**
無法增加 AWS Storage Gateway 硬體設備的根磁碟大小。
1. 重新啟動您的閘道。
## 通知：HardReboot
當閘道 VM 意外重新啟動時，您可能會收到 `HardReboot` 通知。這種重新啟動可能是因為電源中斷、硬體故障或其他事件。對於 VMware 閘道，vSphere 高可用性應用程式監控重設可能會導致此事件。
當閘道在這種環境中執行時，請檢查 `HealthCheckFailure` 通知是否存在，並參閱 VM 的 VMware 事件記錄。
## 通知：重新啟動
當閘道 VM 重新啟動時，您可能會收到重新啟動通知。您可以使用 VM Hypervisor Management 主控台或 Storage Gateway 主控台來重新啟動閘道 VM。您也可以在閘道維護週期期間使用閘道軟體來重新啟動。
如果重新啟動的時間在閘道所設定之[維護開始時間](MaintenanceManagingUpdate-common.md)的 10 分鐘以內，此重新啟動可能是正常的情況，而不是任何問題的徵兆。如果重新啟動很常在維護時段外發生，請檢查閘道是否已手動重新啟動。
## 故障診斷：安全掃描會顯示開放的 NFS 連接埠
某些 NFS 連接埠預設為啟用，即使在僅與 SMB 檔案共用搭配使用的閘道上也是如此。如果您使用第三方安全軟體，例如 Qualys 來掃描部署檔案閘道的網路，掃描結果可能會將這些開放的 NFS 連接埠報告為潛在的安全漏洞。如果您只將閘道與 SMB 檔案共用搭配使用，而且基於安全考量而想要停用未使用的 NFS 連接埠，請使用下列程序：
**若要停用檔案閘道上的 NFS 連接埠：**
1. 使用 中概述的程序存取閘道本機主控台命令提示[在本機主控台上執行 Storage Gateway 命令](MaintenanceGatewayConsole-fgw.md)。
1. 輸入下列命令以停用 NFS 流量：
**IPv4**
```
iptables -I INPUT -p udp -m udp --dport 111 -j DROP
iptables -I INPUT -p udp -m udp --dport 2049 -j DROP
iptables -I INPUT -p udp -m udp --dport 20048 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 111 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
iptables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
**IPv6**
```
ip6tables -I INPUT -p udp -m udp --dport 111 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 2049 -j DROP
ip6tables -I INPUT -p udp -m udp --dport 20048 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 111 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 2049 -j DROP
ip6tables -I INPUT -p tcp -m tcp --dport 20048 -j DROP
```
1. 輸入下列命令以確認封鎖的 NFS 連接埠出現在 IP 資料表中：
**IPv4**
```
iptables -n -L -v --line-numbers
```
**IPv6**
```
ip6tables -n -L -v --line-numbers
```
## 故障診斷：使用 CloudWatch 指標
您可以在下面找到使用 Amazon CloudWatch 指標搭配 Storage Gateway 處理問題之動作的相關資訊。
**Topics**
+ [瀏覽目錄時，您的閘道反應緩慢](#slow-gateway)
+ [您的閘道未回應](#gateway-not-responding)
+ [您的閘道將資料傳輸到 Amazon S3 的速度緩慢](#slow-data-transfer-to-S3)
+ [您的閘道執行的 Amazon S3 操作超過預期](#gateway-performing-more-s3-operations)
+ [您在 Amazon S3 儲存貯體中看不到檔案](#files-missing-s3-bucket)
+ [您的閘道備份任務失敗，或寫入閘道時發生錯誤](#backup-job-fails)
### 瀏覽目錄時，您的閘道反應緩慢
如果您的檔案閘道在執行**ls**命令或瀏覽目錄時反應緩慢，請檢查 `IndexFetch`和 `IndexEviction` CloudWatch 指標：
+ 當您執行`ls`命令或瀏覽目錄時，如果`IndexFetch`指標大於 0，您的 File Gateway 會啟動，但不提供有關受影響目錄內容的資訊，且必須存取 Amazon S3。後續列出該目錄內容的動作應會更快完成。
+ 如果`IndexEviction`指標大於 0，表示您的檔案閘道已達到當時可在其快取中管理的限制。在這種情況下，您的檔案閘道必須從最近最少存取的目錄釋放一些儲存空間，以列出新的目錄。如果經常發生這種情況且效能受到影響，請聯絡 支援。
與相關 S3 儲存貯體 支援 的內容和建議討論，以根據您的使用案例改善效能。
### 您的閘道未回應
如果您的檔案閘道沒有回應，請執行下列動作：
+ 如果有最近的重新開機或軟體更新，則請查看 `IOWaitPercent` 指標。此指標會顯示在有未完成磁碟 I/O 請求時 CPU 閒置時間的百分比。在某些情況下，百分比可能偏高 (10 或以上)，而且可能已在伺服器重新啟動或更新後上升。在這些情況下，檔案閘道可能會在重建索引快取至 RAM 時，受到慢速根磁碟的瓶頸。您可以將速度較快的實體磁碟用於根磁碟來解決此問題。
+ 如果`MemUsedBytes`指標與`MemTotalBytes`指標等於或幾乎相同，則檔案閘道會用盡可用的 RAM。請確定您的檔案閘道至少具有所需的 RAM 下限。如果已經這麼做，請考慮根據您的工作負載和使用案例，將更多 RAM 新增至您的檔案閘道。
如果檔案共享是 SMB，此問題也可能是因為連線到檔案共享的 SMB 用戶端數目所造成。若要查看在任何指定時間連線的用戶端數目，請檢查 `SMBV(1/2/3)Sessions` 指標。如果連接了許多用戶端，您可能需要將更多 RAM 新增至檔案閘道。
### 您的閘道將資料傳輸到 Amazon S3 的速度緩慢
如果您的檔案閘道將資料傳輸到 Amazon S3 的速度緩慢，請執行下列動作：
+ 如果`CachePercentDirty`指標為 80 或更高，您的檔案閘道將資料寫入磁碟的速度會比將資料上傳至 Amazon S3 的速度更快。考慮增加從檔案閘道上傳的頻寬、新增一或多個快取磁碟，或減慢用戶端寫入速度。
+ 如果`CachePercentDirty`指標很低，請檢查`IoWaitPercent`指標。如果 `IoWaitPercent` 大於 10，您的檔案閘道可能會因為本機快取磁碟的速度而遇到瓶頸。建議將本機固態硬碟 (SSD) 磁碟用於快取，最好是 NVM Express (NVMe)。如果無法取得這種磁碟，請嘗試使用來自個別實體磁碟的多個快取磁碟，以提升效能。
+ 如果 `S3PutObjectRequestTime`、 `S3UploadPartRequestTime`或 `S3GetObjectRequestTime` 很高，可能有網路瓶頸。請嘗試分析您的網路，以確認閘道具有預期的頻寬。
### 您的閘道執行的 Amazon S3 操作超過預期
如果您的檔案閘道執行的 Amazon S3 操作超過預期，請檢查 `FilesRenamed` 指標。重新命名操作在 Amazon S3 中執行非常昂貴。最佳化您的工作流程，將重新命名操作的數量降至最低。
### 您在 Amazon S3 儲存貯體中看不到檔案
如果您注意到閘道上的檔案未反映在 Amazon S3 儲存貯體中，請檢查 `FilesFailingUpload` 指標。如果指標報告某些檔案上傳失敗，請檢查您的運作狀態通知。當檔案上傳失敗時，閘道會產生運作狀態通知，其中包含問題的詳細資訊。
### 您的閘道備份任務失敗，或寫入閘道時發生錯誤
如果您的檔案閘道備份任務失敗，或寫入檔案閘道時發生錯誤，請執行下列動作：
+ 如果`CachePercentDirty`指標是 90% 或更高，您的檔案閘道就無法接受對磁碟的新寫入，因為快取磁碟上沒有足夠的可用空間。若要查看 File Gateway 上傳至 Amazon S3 的速度，請檢視 `CloudBytesUploaded` 指標。將該指標與 `WriteBytes` 指標進行比較，該指標顯示用戶端將檔案寫入檔案閘道的速度。如果 SMB 用戶端寫入檔案閘道的速度比上傳至 Amazon S3 的速度快，請新增更多快取磁碟，以至少涵蓋備份任務的大小。或者，增加上傳頻寬。
+ 如果備份任務等大型檔案副本失敗，但`CachePercentDirty`指標低於 80%，您的檔案閘道可能會達到用戶端工作階段逾時。若是 SMB，您可使用 PowerShell 命令 `Set-SmbClientConfiguration -SessionTimeout 300` 來增加此逾時設定。執行此命令會將逾時設為 300 秒。
若是 NFS，請確認用戶端是採用硬性掛載的方式掛載，而非是軟性掛載。
# 故障診斷：檔案共用問題
如果您的檔案共享發生非預期問題，您可在下列資訊中找到應採取的動作。
**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 檔案閘道會以遞迴方式將繼承套用至儲存貯體中的所有物件。這類操作可能會導致閘道的效能下降。
## 高可用性運作狀態通知
在 VMware vSphere High Availability (HA) 平台上執行閘道時，您可能會收到運作狀態通知。如需運作狀態通知的詳細資訊，請參閱[故障診斷：高可用性問題](troubleshooting-ha-issues.md)。
# 故障診斷：高可用性問題
如果發生可用性問題，您可在下列資訊中找到應採取的動作。
**Topics**
+ [運作狀態通知](#ha-health-notifications)
+ [指標](#ha-health-notification-metrics)
## 運作狀態通知
在 VMware vSphere HA 上執行閘道時，所有閘道都會對您設定的 Amazon CloudWatch 日誌群組產生下列運作狀態通知。這些通知會進入名為 `AvailabilityMonitor` 的日誌串流。
**Topics**
+ [通知：重新啟動](#troubleshoot-reboot-notification)
+ [通知：HardReboot](#troubleshoot-hardreboot-notification)
+ [通知：HealthCheckFailure](#troubleshoot-healthcheckfailure-notification)
+ [通知：AvailabilityMonitorTest](#troubleshoot-availabilitymonitortest-notification)
### 通知：重新啟動
當閘道 VM 重新啟動時，您可能會收到重新啟動通知。您可以使用 VM Hypervisor Management 主控台或 Storage Gateway 主控台來重新啟動閘道 VM。您也可以在閘道維護週期期間使用閘道軟體來重新啟動。
**採取動作**
如果重新啟動的時間在閘道所設定之[維護開始時間](MaintenanceManagingUpdate-common.md)的 10 分鐘以內，這可能是正常的情況，而不是任何問題的徵兆。如果重新啟動很常在維護時段外發生，請檢查閘道是否已手動重新啟動。
### 通知：HardReboot
當閘道 VM 意外重新啟動時，您可能會收到 `HardReboot` 通知。這種重新啟動可能是因為電源中斷、硬體故障或其他事件。對於 VMware 閘道，vSphere 高可用性應用程式監控重設可能會導致此事件。
**採取動作**
當閘道在這種環境中執行時，請檢查 `HealthCheckFailure` 通知是否存在，並參閱 VM 的 VMware 事件記錄。
### 通知：HealthCheckFailure
若是 VMware vSphere HA 上的閘道，當運作狀態檢查失敗且請求 VM 重新啟動時，您可能會收到 `HealthCheckFailure` 通知。此事件也會在監控可用性的測試期間發生，並顯示於 `AvailabilityMonitorTest` 通知中。在此情況下，則預期會收到`HealthCheckFailure` 通知。
**注意**
此通知僅適用於 VMware 閘道。
**採取動作**
如果此事件在沒有 `AvailabilityMonitorTest` 通知的情況下重複發生，請檢查您的 VM 基礎設施是否有問題 (儲存空間、記憶體等)。如果您需要其他協助，請聯絡 支援。
### 通知：AvailabilityMonitorTest
對於 VMware vSphere HA 上的閘道，您可以在 VMware 中[執行](vmware-ha.md#vmware-ha-test-failover)[可用性和應用程式監控](https://docs.aws.amazon.com/storagegateway/latest/APIReference/API_StartAvailabilityMonitorTest.html)系統的測試時收到 `AvailabilityMonitorTest` 通知。
## 指標
`AvailabilityNotifications` 指標可在所有閘道上使用。此指標會計算閘道產生的可用相關運作狀態通知數目。使用 `Sum` 統計資料，即可觀察閘道是否發生任何可用性相關事件。如需事件的詳細資訊，請參閱您設定的 CloudWatch 日誌群組。