View a markdown version of this page

トラブルシューティング: ファイル共有に関する問題 - AWS Storage Gateway
ファイル共有が移行状態でスタックするファイル共有を作成できないSMB ファイル共有で複数の異なるアクセス方法が使えないマッピングされた S3 バケットに複数のファイル共有を書き込めない監査ログを使用する場合の削除済みロググループの通知S3 バケットにファイルをアップロードできないデフォルトの暗号化を SSE-KMS に変更できないオブジェクトのバージョニングが有効になっている S3 バケットで直接行われた変更は、ファイル共有で表示される内容に影響することがあります。オブジェクトのバージョニングを有効にして S3 バケットに書き込む場合、Amazon S3 ファイルゲートウェイは S3 オブジェクトの複数のバージョンを作成することがあります。S3 バケットに対する変更が Storage Gateway に反映されないACL のアクセス許可が予期する動作を行わない再帰的なオペレーション後に、ゲートウェイのパフォーマンスが低下した

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

トラブルシューティング: ファイル共有に関する問題

このセクションでは、ファイル共有で想定外の問題が発生した場合に行うアクションについて説明します。

ファイル共有が CREATING、UPDATING、または DELETING 状態でスタックする

ファイル共有ステータスは、ファイル共有の状態をまとめたものです。S3 File Gateway ファイル共有が CREATING、、UPDATINGまたは DELETING状態でスタックしている場合は、次のトラブルシューティングステップを使用して問題を特定して解決します。

IAM ロールのアクセス許可と信頼関係を確認する

ファイル共有に関連付けられた AWS Identity and Access Management (IAM) ロールには、Amazon S3 バケットにアクセスするための十分なアクセス許可が必要です。さらに、ロールの信頼ポリシーは、ロールを引き受けるアクセス許可を Storage Gateway サービスに付与する必要があります。

IAM ロールのアクセス許可を確認するには:

  1. IAM コンソール (https://console.aws.amazon.com/iam/) を開きます。

  2. ナビゲーションペインで Roles (ロール) を選択してください。

  3. ファイル共有に関連付けられている IAM ロールを選択します。

  4. [信頼関係] タブを選択します。

  5. Storage Gateway が信頼されたエンティティとしてリストされていることを確認します。Storage Gateway が信頼されたエンティティでない場合は、信頼関係の編集を選択し、次のポリシーを追加します。

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

  6. IAM ロールに正しいアクセス許可があり、Amazon S3 バケットが IAM ポリシーにリソースとしてリストされていることを確認します。詳細については、「Amazon S3 バケットに対するアクセス権限の付与」を参照してください。

注記

サービス間の混乱した代理防止の問題を回避するには、条件コンテキストキーを含む信頼関係ポリシーを使用します。詳細については、「サービス間の混乱した代理の防止」を参照してください。

リージョンで AWS STS がアクティブ化されていることを確認します。

AWS リージョンで AWS Security Token Service (AWS STS) が非アクティブ化されている場合、ファイル共有は CREATINGまたは UPDATING状態でスタックする可能性があります。

AWS STS ステータスを確認するには:

  1. https://console.aws.amazon.com/iam/ で AWS Identity and Access Management コンソールを開きます。

  2. ナビゲーションペインで [アカウント設定] を選択します。

  3. Security Token Service (STS) セクションで、ファイル共有を作成する AWS リージョンのステータスがアクティブであることを確認します。

  4. ステータスが非アクティブの場合は、アクティブ化を選択してそのリージョン AWS STS で を有効にします。

S3 バケットが存在し、命名規則に従っていることを確認する

ファイル共有には、Amazon S3 の命名規則に従った有効な Amazon S3 バケットが必要です。

S3 バケットを確認するには:

  1. Amazon S3 コンソール (https://console.aws.amazon.com/s3/) を開きます。

  2. ファイル共有にマッピングされた Amazon S3 バケットが存在することを確認します。バケットが存在しない場合は、作成します。バケットを作成すると、ファイル共有ステータスは に変わりますAVAILABLE。詳細については、Amazon Simple Storage Service ユーザーガイドの「バケットの作成」を参照してください。

  3. バケット名が Amazon Simple Storage Service ユーザーガイドのバケット命名規則に準拠していることを確認します。

    注記

    S3 File Gateway は、バケット名にピリオド (.) を含む Amazon S3 バケットをサポートしていません。

ファイル共有を DELETING 状態で強制的に削除する

ファイル共有を削除すると、ゲートウェイは関連付けられた Amazon S3 バケットから共有を削除します。ただし、現在アップロード中のデータは、削除が完了する前に引き続きアップロードされます。このプロセス中に、ファイル共有のステータスが表示されますDELETING。

重要

ゲートウェイCachePercentDirtyの Amazon CloudWatch メトリクスをチェックして、アップロード保留中のデータの量を確認します。Storage Gateway メトリクスの詳細については、「」を参照してくださいS3 ファイルゲートウェイのモニタリング。

進行中のすべてのアップロードが完了するまで待機しない場合は、ファイル共有を強制的に削除できます。

ファイル共有を強制的に削除するには:

  1. https://console.aws.amazon.com/storagegateway/ で Storage Gateway コンソールを開きます。

  2. ナビゲーションペインで、ファイル共有を選択します。

  3. 削除するファイル共有を選択します。

  4. 詳細タブを選択し、このファイル共有は削除中ですというメッセージを確認します。

  5. メッセージ内のファイル共有の ID を確認し、確認ボックスを選択します。

    注記

    強制削除オペレーションを元に戻すことはできません。

  6. 今すぐ強制削除を選択します。

または、 AWS CLI delete-file-share コマンドを使用して、 --force-deleteパラメータを に設定することもできますtrue。

重要

ファイル共有を強制的に削除する前に、ゲートウェイが OFFLINE状態になっていないことを確認してください。ゲートウェイがオフラインの場合は、まずオフラインの問題を解決します。詳細については、「トラブルシューティング: Storage Gateway コンソールでゲートウェイがオフラインとなる」を参照してください。

ゲートウェイ仮想マシン (VM) がすでに削除されている場合は、Storage Gateway コンソールからゲートウェイを削除して、 DELETING状態でスタックしているファイル共有を含む、関連するすべてのファイル共有を削除する必要があります。詳細については、「ゲートウェイおよび関連リソースの削除」を参照してください。

ネットワーク接続に関する問題のトラブルシューティングを行う

ネットワークの問題により、ファイル共有が CREATING、、UPDATINGまたは DELETING状態から移行できなくなる可能性があります。一般的なネットワークの問題は次のとおりです。

  • ゲートウェイがオフラインであるか、ゲートウェイ VM が削除されます。

  • Storage Gateway と Amazon S3 サービスエンドポイント間のネットワークアクセスはブロックされます。

  • ゲートウェイが Amazon S3 との通信に使用する Amazon S3 Amazon VPC エンドポイントが削除されました。

  • 必要なネットワークポートが開いていないか、ネットワークルーティングが正しく設定されていません。

ゲートウェイローカルコンソールから S3 接続をテストする

S3 接続をテストするには:

  1. ゲートウェイのローカルコンソールにログインします。詳細については、「ファイルゲートウェイローカルコンソールへのログイン」を参照してください。

  2. Storage Gateway - 設定のメインメニューに、テスト S3 接続に対応する番号を入力します。

  3. Amazon S3 エンドポイントタイプを選択します。

    • インターネットゲートウェイ、NAT ゲートウェイ、トランジットゲートウェイ、または Amazon S3 ゲートウェイの Amazon VPC エンドポイントを通過する Amazon S3 トラフィックの場合は、「パブリック」を選択します。

    • Amazon S3 インターフェイス Amazon VPC エンドポイントを通過する Amazon S3 トラフィックの場合は、VPC (PrivateLink) を選択します。

    • FIPS エンドポイントの場合は、FIPS オプションを選択します。

  4. Amazon S3 バケットリージョンを入力します。

  5. Amazon VPC エンドポイントを使用する場合は、Amazon S3 Amazon VPC エンドポイントの DNS 名 (例: ) を入力しますvpce-0329c2790456f2d01-0at85l34。

ゲートウェイは、ネットワーク接続と SSL 接続の両方を検証する接続テストを自動的に実行します。テストが失敗した場合:

  • ネットワークテストの失敗 - 通常、ファイアウォールルール、セキュリティグループ設定、不適切なネットワークルーティングが原因で発生します。必要なポートが開いていて、ネットワークルーティングが正しく設定されていることを確認します。

  • SSL テストの失敗 - ゲートウェイ VM と Amazon S3 サービスエンドポイントの間で SSL 検査またはディープパケット検査が発生していることを示します。Storage Gateway トラフィックの SSL およびディープパケットインスペクションを無効にします。

プロキシ設定の確認

ゲートウェイがプロキシサーバーを使用している場合は、プロキシがネットワーク通信をブロックしていないことを確認します。

プロキシ設定を確認するには:

  1. Storage Gateway - Configuration メインメニューで、HTTP/SOCKS Proxy Configuration に対応する番号を入力します。

  2. 現在のネットワークプロキシ設定を表示するオプションを選択します。

  3. プロキシが設定されている場合は、Amazon S3 トラフィックが Storage Gateway からポート 3128 (または設定されたリスナーポート) 経由でプロキシサーバーに流れ、ポート 443 経由で Amazon S3 エンドポイントに流れることを確認します。

  4. プロキシまたはファイアウォールが、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 バケットが存在することを確認します。これを行う方法については、「ファイル共有が CREATING、UPDATING、または DELETING 状態でスタックする」を参照してください。

  2. S3 バケットが存在する場合は、ファイル共有を作成するリージョンで AWS Security Token Service がアクティブ化されていることを確認します。セキュリティトークンが有効になっていない場合は、有効にする必要があります。を使用してトークンをアクティブ化する方法については AWS Security Token Service、IAM ユーザーガイドの「 AWS リージョンでの AWS STS のアクティブ化と非アクティブ化」を参照してください。

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.

  2. Windows ユーザーは、2 つのゲストアクセスの SMB ファイル共有に接続することはできません。新しいゲストアクセス接続が確立されると切断される場合があります。

  3. Windows クライアントは、同じゲートウェイによってエクスポートされた、ゲストアクセスと Active Directory の SMB ファイル共有の両方をマウントすることはできません。

マッピングされた S3 バケットに複数のファイル共有を書き込めない

1 つの S3 バケットに複数のファイル共有を書き込むことを許可するよう S3 バケットを設定することは推奨されません。このやり方では、想定外の結果を引き起こす場合があります。

代わりに、各 S3 バケットに 1 つのファイル共有のみ書き込めるようにすることが推奨されます。ファイル共有に関連付けられた 1 つのロールのみがバケットに書き込めるようにするバケットポリシーを作成します。詳細については、「ファイルゲートウェイのベストプラクティス」を参照してください。

監査ログを使用する場合の削除済みロググループの通知

ロググループが存在しない場合、ユーザーはそのメッセージの下にあるロググループリンクを選択して、新しいロググループを作成するか、または既存のロググループを使用して、監査ログの対象として利用できます。

S3 バケットにファイルをアップロードできない

S3 バケットにファイルをアップロードできない場合には、以下を行います。

  1. S3 バケットにファイルをアップロードする Amazon S3 ファイルゲートウェイに必要なアクセス権限があることを確認します。詳細については、「Amazon S3 バケットに対するアクセス権限の付与」を参照してください。

  2. バケットを作成したロールに S3 バケットに書き込みを行う許可があることを確認します。詳細については、「ファイルゲートウェイのベストプラクティス」を参照してください。

  3. ファイルゲートウェイが暗号化に SSE-KMS または DSSE-KMS を使用している場合は、ファイル共有に関連付けられた IAM ロールに kms:Encrypt、kms:Decrypt、kms:ReEncrypt*、kms:GenerateDataKey、および kms:DescribeKey のアクセス許可が含まれていることを確認してください。詳細については、「Storage Gateway でアイデンティティベースのポリシー (IAM ポリシー) を使用する」を参照してください。

SSE-KMS を使用して、S3 バケットに保存されたオブジェクトを暗号化するように、デフォルトの暗号化を変更できない

デフォルトの暗号化を変更して SSE-KMS ( AWS KMS– マネージドキーを使用したサーバー側の暗号化) を S3 バケットのデフォルトにすると、Amazon S3 ファイルゲートウェイがバケットに保存するオブジェクトは SSE-KMS で暗号化されません。デフォルトでは、S3 ファイルゲートウェイで S3 バケットにデータを書き込む際、Amazon S3 で管理されるサーバー側の暗号化 (SSE-S3) が使用されます。デフォルトを変更しても、暗号化は自動的に変更されません。

独自の AWS KMS キーで SSE-KMS を使用するように暗号化を変更するには、SSE-KMS 暗号化を有効にする必要があります。これを行うには、ファイル共有を作成するときに KMS キーの Amazon リソースネーム (ARN) を指定します。ファイル共有の KMS 設定は、UpdateNFSFileShare または UpdateSMBFileShare API オペレーションを使用して更新することもできます。この更新は、更新後に S3 バケットに保存されているオブジェクトに適用されます。詳細については、「を使用したデータ暗号化 AWS KMS」を参照してください。

オブジェクトのバージョニングが有効になっている S3 バケットで直接行われた変更は、ファイル共有で表示される内容に影響することがあります。

S3 バケットのオブジェクトが別のクライアントから書き込まれている場合、S3 バケットオブジェクトのバージョニングの結果として S3 バケットのビューが最新でなくなる可能性があります。目的のファイルを調べる前に必ずキャッシュを更新してください。

オブジェクトのバージョニングは、同じ名前のオブジェクトの複数のコピーを保存することによりデータを保護するためのオプションの S3 バケット機能です。各コピーには、個別の ID 値があります (file1.jpg: ID="xxx" および file1.jpg: ID="yyy" など)。同じ名前のオブジェクトの数とその存続期間は、Amazon S3 ライフサイクルポリシーによって制御されます。これらの Amazon S3 の概念の詳細については、「Amazon S3 開発者ガイド」の「バージョニングの使用」と「オブジェクトのライフサイクルの管理」を参照してください。

バージョニングされたオブジェクトを削除すると、そのオブジェクトには削除マーカーのフラグが付けられますが保持されます。バージョニングがオンになっているオブジェクトは、S3 バケット所有者のみが完全に削除することができます。

S3 ファイルゲートウェイでは、表示されるファイルは、オブジェクトが取得されたかキャッシュが更新された時点の S3 バケットにおけるオブジェクトの最新バージョンです。S3 ファイルゲートウェイは、古いバージョン、または削除対象としてマークされたすべてのオブジェクトを無視します。ファイルを読み込むとき、最新バージョンからデータを読み取ります。ファイル共有にファイルを書き込むと、S3 ファイルゲートウェイにより、指定オブジェクトの新しいバージョンが変更を適用して作成され、そのバージョンが最新バージョンになります。

S3 ファイルゲートウェイは、以前のバージョンから読み取りを続けます。アプリケーション外で S3 バケットに新しいバージョンが追加された場合、ゲートウェイによる更新は以前のバージョンに基づいて行われます。オブジェクトの最新バージョンを読み取るには、「Amazon S3 バケットのオブジェクトキャッシュの更新」で説明されているように、RefreshCache API アクションを使用するか、コンソールから更新します。

重要

ファイル共有以外の経路から、S3 ファイルゲートウェイの S3 バケットにオブジェクトまたはファイルを書き込むことは推奨されません。

オブジェクトのバージョニングを有効にして S3 バケットに書き込む場合、Amazon S3 ファイルゲートウェイは S3 オブジェクトの複数のバージョンを作成することがあります。

オブジェクトのバージョニングを有効にすると、NFS または SMB クライアントからファイルを更新するたびに、Amazon S3 でオブジェクトの複数のバージョンが作成されることがあります。S3 バケットにオブジェクトの複数のバージョンが作成される可能性があるシナリオを次に示します。

  • Amazon S3 にアップロードされたファイルが、NFS または SMB クライアントによってAmazon S3 ファイルゲートウェイ内で変更されると、S3 ファイルゲートウェイはファイル全体をアップロードするのではなく、新しいデータまたは変更されたデータのみをアップロードします。ファイルを変更すると、Amazon S3 オブジェクトの新しいバージョンが作成されます。

  • NFS または SMB クライアントによってファイルゲートウェイにファイルが書き込まれると、S3 ファイルゲートウェイによりファイルデータが Amazon S3 にアップロードされます。その後、メタデータ (所有権、タイムスタンプなど) がアップロードされます。ファイルデータをアップロードすると Amazon S3 オブジェクトが作成され、ファイルのメタデータをアップロードすると、Amazon S3 オブジェクトのメタデータが更新されます。このプロセスにより、別のバージョンのオブジェクトが作成され、オブジェクトのバーションが 2 つになります。

  • S3 ファイルゲートウェイが大きなファイルをアップロードする場合、クライアントがファイルゲートウェイへの書き込みを完了する前に、ファイルを小さく分けてアップロードする必要がある場合があります。その理由には、キャッシュ領域の解放や、ファイルへの書き込み率が高いことなどが挙げられます。この処理では、S3 バケットで複数バージョンのオブジェクトが作成されることがあります。

オブジェクトを異なるストレージクラスに移動するライフサイクルポリシーを設定する前に、S3 バケットをモニタリングして、オブジェクトのバージョン数を確認する必要があります。S3 バケット内のオブジェクトのバージョン数を最小限に抑えるには、過去のバージョンのライフサイクルに有効期限を設定する必要があります。S3 バケット間で、同一リージョンでのレプリケーション (SRR) またはクロスリージョンでのレプリケーション (CRR) を使用すると、使用されるストレージが増加します。レプリケーションの詳細については、「レプリケーション」を参照してください。

重要

オブジェクトのバージョニングが有効になっているときに使用されているストレージの量を把握するまで、S3 バケット間のレプリケーションを設定しないでください。

バージョニングされた S3 バケットを使用すると、ファイルを変更するたびに S3 オブジェクトの新しいバージョンが作成されるため、Amazon 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 を実行します

    2. 更新するキャッシュとのファイル共有の Amazon リソースナンバー (ARN) をコピーします。

    3. ARN を --file-share-arn の値として refresh-cache コマンドを次のように実行します。

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

RefreshCache オペレーションを自動化するには、「Storage Gateway で RefreshCache 操作を自動化する方法」を参照してください。

ACL のアクセス許可が予期する動作を行わない

アクセスコントロールリスト (ACL) 権限が SMB ファイル共有で所定の動作を行わない場合は、テストを実行できます。

これを行うには、まず、Microsoft Windows ファイルサーバーあるいはローカル Windows ファイル共有でアクセス権限をテストします。次に、ゲートウェイのファイル共有と動作を比較します。

再帰的なオペレーションを実行すると、ゲートウェイのパフォーマンスが低下した

一部のケースでは、ディレクトリの名前変更や ACL での継承を有効にするなどの再帰的なオペレーションを実行し、その変更をツリー全体に強制的に適用することがあります。これを行った場合、S3 ファイルゲートウェイはこのオペレーションを再帰的にファイル共有のすべてのオブジェクトに適用します。

例えば、S3 バケット内の既存のオブジェクトに継承を適用するとします。S3 ファイルゲートウェイは、バケット内のすべてのオブジェクトに継承を再帰的に適用します。このようなオペレーションは、ゲートウェイの実行が拒否される要因となることがあります。