翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
トラブルシューティング: ファイル共有に関する問題
このセクションでは、ファイル共有で想定外の問題が発生した場合に行うアクションについて説明します。
トピック
ファイル共有が CREATING ステータスのまま止まる
ファイル共有を作成している間、そのステータスは作成中となります。このステータスは、ファイル共有の作成後に使用可能ステータスに変わります。ファイル共有が作成中ステータスのまま止まってしまったら、以下を実行します。
Amazon S3 コンソール (https://console.aws.amazon.com/s3/
) を開きます。 -
ファイル共有をマッピングした S3 バケットが存在することを確認します。バケットが存在しない場合には、バケットを作成します。バケットを作成すると、ファイル共有ステータスは使用可能に変わります。S3 バケットの作成方法の詳細については、「Amazon Simple Storage Service ユーザーガイド」の「バケットの作成」を参照してください。
-
バケット名が Amazon S3 のバケット命名ルールに準拠していることを確認します。詳細については、「Amazon Simple Storage Service ユーザーガイド」の「バケットの制約と制限」を参照してください。
注記
S3 ファイルゲートウェイは、バケット名にピリオド (
.) を使った Amazon S3 バケットをサポートしていません。 -
S3 バケットにアクセスするために使用した IAM ロールに正しいアクセス許可があることを確認し、S3 バケットが IAM ポリシーのリソースとしてリストされていることを確認します。詳細については、「Amazon S3 バケットに対するアクセス権限の付与」を参照してください。
ファイル共有を作成できない
-
ファイル共有が CREATING ステータスのまま止まっているためにファイル共有を作成できない場合には、ファイル共有をマッピングした S3 バケットが存在することを確認します。これを行う方法については、「ファイル共有が CREATING ステータスのまま止まる」を参照してください。
-
S3 バケットが存在する場合は、ファイル共有を作成するリージョンで AWS Security Token Service がアクティブ化されていることを確認します。セキュリティトークンが有効になっていない場合は、有効にする必要があります。を使用してトークンをアクティブ化する方法については AWS Security Token Service、IAM ユーザーガイドの「 AWS リージョンでの AWS STS のアクティブ化と非アクティブ化」を参照してください。
SMB ファイル共有で複数の異なるアクセス方法が使えない
SMB ファイル共有には、以下の制約があります。
-
同じクライアントが 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. -
Windows ユーザーは、2 つのゲストアクセスの SMB ファイル共有に接続することはできません。新しいゲストアクセス接続が確立されると切断される場合があります。
-
Windows クライアントは、同じゲートウェイによってエクスポートされた、ゲストアクセスと Active Directory の SMB ファイル共有の両方をマウントすることはできません。
マッピングされた S3 バケットに複数のファイル共有を書き込めない
1 つの S3 バケットに複数のファイル共有を書き込むことを許可するよう S3 バケットを設定することは推奨されません。このやり方では、想定外の結果を引き起こす場合があります。
代わりに、各 S3 バケットに 1 つのファイル共有のみ書き込めるようにすることが推奨されます。ファイル共有に関連付けられた 1 つのロールのみがバケットに書き込めるようにするバケットポリシーを作成します。詳細については、「ファイルゲートウェイのベストプラクティス」を参照してください。
監査ログを使用する場合の削除済みロググループの通知
ロググループが存在しない場合、ユーザーはそのメッセージの下にあるロググループリンクを選択して、新しいロググループを作成するか、または既存のロググループを使用して、監査ログの対象として利用できます。
S3 バケットにファイルをアップロードできない
S3 バケットにファイルをアップロードできない場合には、以下を行います。
-
S3 バケットにファイルをアップロードする Amazon S3 ファイルゲートウェイに必要なアクセス権限があることを確認します。詳細については、「Amazon S3 バケットに対するアクセス権限の付与」を参照してください。
-
バケットを作成したロールに S3 バケットに書き込みを行う許可があることを確認します。詳細については、「ファイルゲートウェイのベストプラクティス」を参照してください。
-
ファイルゲートウェイが暗号化に 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を使用してキャッシュを更新するには次の手順を実行します。
-
コマンド
aws storagegateway list-file-sharesを実行します -
更新するキャッシュとのファイル共有の Amazon リソースナンバー (ARN) をコピーします。
-
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 ファイルゲートウェイは、バケット内のすべてのオブジェクトに継承を再帰的に適用します。このようなオペレーションは、ゲートウェイの実行が拒否される要因となることがあります。