

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# トラブルシューティング: ファイルゲートウェイに関する問題
<a name="troubleshooting-file-gateway-issues"></a>

Amazon CloudWatch ロググループにログエントリを書き込むようにファイルゲートウェイを設定できます。その場合は、ファイルゲートウェイのヘルスステータスと、ゲートウェイで発生したエラーに関する通知が表示されます。CloudWatch ログで、これらのエラーおよびヘルス通知に関する情報を参照できます。

以下のセクションでは、各エラーとヘルス通知の原因、およびその問題の修正方法を理解するのに役立つ情報が見つかります。

**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)
<a name="troubleshoot-copying-files-to-s3"></a>

Amazon S3 へのファイルの移行中に、10 を超えたアクセスコントロールエントリ (ACEs) を持つファイルを Amazon S3 にコピーしようとすると、`ERROR 1344 (0x00000540)` が発生することがあります。アクセスコントロールエントリは、アクセスコントロールリスト (ACL) に記載されています。

 Amazon S3 ファイルゲートウェイは、特定のファイルまたはフォルダごとに 10 個の ACE エントリのみを保持できます。

**エラー 1344 を解決するには: NTFS セキュリティを送信先ディレクトリにコピーします。**

10 を超えるエントリのあるファイルまたはフォルダの Windows アクセス許可のエントリの数を減らします。一般的な方法は、エントリの完全なリストを備えたグループを作成し、エントリのリストをその単一のグループに置き換えることです。エントリ数が 10 未満になったら、ファイルまたはフォルダのゲートウェイへのコピーを再試行できます。

## エラー: GatewayClockOutOfSync
<a name="troubleshoot-logging-errors-gatewayclockoutofsync"></a>

ゲートウェイがローカルシステム時刻と 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
<a name="troubleshoot-logging-errors-inaccessiblestorageclass"></a>

オブジェクトを 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
<a name="troubleshoot-logging-errors-invalidobjectstate"></a>

指定されたファイルゲートウェイ以外のライターが、指定された 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
<a name="troubleshoot-logging-errors-objectmissing"></a>

指定されたファイルゲートウェイ以外のライターが、指定されたファイルを 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
<a name="misconfig-trust"></a>

このエラーは、ファイル共有の IAM ロールで IAM の信頼関係が正しく設定されていない (つまり IAM ロールで `storagegateway.amazonaws.com` という名前の Storage Gateway プリンシパルが信頼されていない) 場合に発生します。その結果、ファイルゲートウェイでは、ファイル共有をバックアップする S3 バケットでオペレーションを実行するための認証情報を取得できなくなります。

**RoleTrustRelationshipInvalid エラーを解決するには**
+ ファイル共有の IAMrole によって信頼されるプリンシパルとして `storagegateway.amazonaws.com` を含めるには、IAM コンソールまたは IAM API を使用します。IAM ロールの詳細については、[「チュートリアル: IAM ロールを使用して AWS アカウント間でアクセスを委任](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html)する」を参照してください。

## エラー: S3AccessDenied
<a name="troubleshoot-logging-errors-s3accessdenied"></a>

ファイル共有の 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
<a name="troubleshoot-logging-errors-droppednotifications"></a>

ゲートウェイのルートディスクの空きストレージ容量が 1 GB 未満の場合や、1 分以内に 100 件を超えるヘルス通知が生成された場合、他の予想されるタイプの CloudWatch Log エントリの代わりに`DroppedNotifications` エラーが表示されることがあります。このような状況では、ゲートウェイは予防策として、詳細な CloudWatch ログ通知の生成を停止します。

**DroppedNotifications エラーを解決するには**

1. Storage Gateway コンソールのゲートウェイの **[モニタリング]** タブの `Root Disk Usage` メトリクスを確認して、使用可能なルートディスク容量が少ないかどうかを確認します。

1. 使用可能な容量が 1 GB 未満の場合は、ゲートウェイのルートストレージディスクのサイズを増やします。手順については、仮想マシンハイパーバイザーのドキュメントを参照してください。

   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
<a name="troubleshoot-hardreboot-notification"></a>

ゲートウェイ VM が予期せず再起動された場合、`HardReboot` 通知が表示されることがあります。このような再起動の原因としては、電源の喪失、ハードウェア障害、またはその他のイベントが考えられます。VMware ゲートウェイの場合、vSphere High Availability のアプリケーションの監視によるリセットにより、このイベントが引き起こされることがあります。

ゲートウェイがこのような環境で実行されている場合は、`HealthCheckFailure` 通知の有無を確認し、VM の VMware イベントログを調べます。

## 通知: リブート
<a name="troubleshoot-reboot-notification"></a>

ゲートウェイ VM の再起動時に、再起動通知が表示される場合があります。VM ハイパーバイザーの管理コンソールまたは Storage Gateway コンソールを使用して、ゲートウェイ VM を再起動できます。また、ゲートウェイのメンテナンスサイクル中にゲートウェイソフトウェアを使用して再起動することもできます。

再起動の時刻がゲートウェイで設定された[メンテナンス開始時刻](MaintenanceManagingUpdate-common.md)から 10 分以内である場合、この再起動の発生はおそらく正常であり、問題の兆候ではありません。メンテナンスの大幅な期間外に再起動が発生した場合は、ゲートウェイを手動で再起動したかどうかを確認します。

## トラブルシューティング: セキュリティスキャンで NFS ポートの開放が検出される
<a name="troubleshoot-open-nfs-ports"></a>

特定の 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 メトリクスの使用
<a name="troubleshooting-with-cw-metrics"></a>

Storage Gateway で Amazon CloudWatch メトリクスを使用する際の問題に対処するためのアクションについては、次を参照してください。

**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)

### ディレクトリの閲覧時にゲートウェイの反応が遅い
<a name="slow-gateway"></a>

**ls** コマンドの実行時またはディレクトリの閲覧時にファイルゲートウェイの反応が遅い場合は、`IndexFetch` および `IndexEviction` の CloudWatch メトリクスを確認します。
+ `ls` コマンドの実行時またはディレクトリの閲覧時に `IndexFetch` メトリクスが 0 を超えている場合、ファイルゲートウェイは影響を受けるディレクトリの内容に関する情報なしで起動し、Amazon S3 にアクセスする必要がありました。今後そのディレクトリの内容をリストする作業の速度は上がるはずです。
+ `IndexEviction` メトリクスが 0 を超えている場合は、ファイルゲートウェイがその時点でキャッシュとして管理できる上限に達していることを意味します。この場合、ファイルゲートウェイでは、最近最もアクセスしていないディレクトリから一部のストレージ領域を解放して、新しいディレクトリをリストする必要があります。この問題が頻繁に発生し、パフォーマンスへの影響がある場合は、 にお問い合わせください サポート。

  関連する S3 バケット サポート の内容と、ユースケースに基づいてパフォーマンスを向上させるための推奨事項について説明します。

### ゲートウェイが応答しない
<a name="gateway-not-responding"></a>

ファイルゲートウェイが応答しない場合は、次の操作を行います。
+  最近再起動またはソフトウェアの更新を行った場合は、`IOWaitPercent` メトリクスを確認します。このメトリクスは、未処理のディスク I/O リクエストがある場合に、CPU がアイドル状態の時間の割合を示します。場合によっては、この値が高く (10 以上)、サーバーの再起動または更新後に増えていることがあります。このような場合、ファイルゲートウェイによりインデックスのキャッシュが RAM に再構築されるため、低速のルートディスクがゲートウェイのボトルネックになっている可能性があります。より高速な物理ディスクをルートディスクに使用することにより、この問題に対処できます。
+ `MemUsedBytes` メトリクスが `MemTotalBytes` メトリクスと同じか、ほぼ同じ場合、ファイルゲートウェイで使用可能な RAM が不足しています。ファイルゲートウェイに最低限必要な RAM があることを確認してください。既にある場合は、ワークロードとユースケースに基づいて、ファイルゲートウェイに RAM を追加することを検討してください。

  ファイル共有が SMB の場合は、ファイル共有に接続されている SMB クライアントの数が問題の原因である可能性もあります。任意の時点で接続しているクライアントの数を確認するには、`SMBV(1/2/3)Sessions` メトリクスをチェックします。多くのクライアントが接続されている場合、ファイルゲートウェイに RAM の追加が必要になることがあります。

### ゲートウェイを介した Amazon S3 へのデータ転送速度が遅い
<a name="slow-data-transfer-to-S3"></a>

ファイルゲートウェイを介した Amazon S3 へのデータ転送速度が遅い場合は、次の操作を行います。
+ `CachePercentDirty` メトリクスが 80 以上の場合、ファイルゲートウェイでは、データが Amazon S3 にアップロードされる速度よりも速いペースでデータがディスクに書き込まれています。ファイルゲートウェイからのアップロードの帯域幅を増やす、1 つ以上のキャッシュディスクを追加する、またはクライアントの書き込み速度を遅くすることを検討してください。
+ `CachePercentDirty` メトリクスが低い場合は、`IoWaitPercent` メトリクスを確認します。`IoWaitPercent` が 10 を超える場合、ファイルゲートウェイでローカルキャッシュディスクの速度がボトルネックになっている可能性があります。キャッシュには、ローカルソリッドステートドライブ (SSD) ディスク (できれば NVM Express (NVMe)) をお勧めします。このようなディスクが使用できない場合は、パフォーマンスを向上させるために、別々の物理ディスクから複数のキャッシュディスクを使用してみてください。
+ `S3PutObjectRequestTime`、`S3UploadPartRequestTime`、または `S3GetObjectRequestTime` が高い場合、ネットワークにボトルネックが発生している可能性があります。ネットワークを分析して、ゲートウェイに想定どおりの帯域幅が確保されていることを確認してください。

### ゲートウェイが想定よりも多くの Amazon S3 オペレーションを実行している
<a name="gateway-performing-more-s3-operations"></a>

ファイルゲートウェイが想定よりも多くの Amazon S3 オペレーションを実行している場合は、`FilesRenamed` メトリクスを確認します。名前変更オペレーションはAmazon S3で実行するとコストがかかります。ワークフローを最適化して、名前変更オペレーションの数を最小限に抑えます。

### Amazon S3 バケットにファイルが表示されない
<a name="files-missing-s3-bucket"></a>

ゲートウェイ上のファイルが Amazon S3 バケットに反映されていない場合は、`FilesFailingUpload` メトリクスを確認してください。メトリクスが一部のファイルのアップロードに失敗したことを報告している場合は、ヘルス通知を確認します。ファイルのアップロードに失敗すると、ゲートウェイは問題の詳細を示したヘルス通知を生成します。

### ゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する
<a name="backup-job-fails"></a>

ファイルゲートウェイへの書き込み時にゲートウェイのバックアップジョブが失敗する、またはエラーが発生する場合は、次の操作を行います。
+ `CachePercentDirty` メトリクスが 90 パーセント以上の場合、キャッシュディスクに十分な空き領域がないため、ファイルゲートウェイではディスクへの新しい書き込みを受け付けることができません。ファイルゲートウェイでの Amazon S3 へのアップロード速度を確認するには、`CloudBytesUploaded` メトリクスを表示します。そのメトリクスと、クライアントによるファイルゲートウェイへのファイルの書き込みの速さを示す `WriteBytes` メトリクスを比較します。SMB クライアントがファイルゲートウェイが、Amazon S3 にアップロードできる速度よりも速く書き込みを行っている場合は、少なくともバックアップジョブのサイズに対応できるキャッシュディスクを追加します。または、アップロード帯域幅を増やします。
+ バックアップジョブが失敗しているにもかかわらず、`CachePercentDirty` メトリクスが 80 パーセント未満の場合は、ファイルゲートウェイでクライアント側のセッションがタイムアウトしている可能性があります。SMB の場合は、PowerShell コマンド `Set-SmbClientConfiguration -SessionTimeout 300` を使用してこのタイムアウトを増やすことができます。このコマンドを実行すると、タイムアウトが 300 秒に設定されます。

  NFS の場合は、クライアントがソフトマウントではなくハードマウントを使用してマウントされていることを確認してください。