OSS エラー 403

OSS エラー 403 は、OSS から返された HTTP 状態コードが 403 であることを示しています。また、ユーザーにアクセス権がないため、サーバーが要求を受信した後、サービスの提供を拒否したことを示しています。 次のテーブルに、OSS エラー 403 とその原因を示します。

エラー メッセージ 原因 解決方法
SignatureDoesNotMatch ErrorCode: ErrorCode: SignatureDoesNotMatch ErrorMessage: 計算した署名要求と提示された署名とが一致しません。 キーと署名方法を確認してください。 クライアントの署名とサービスによって計算された署名とが一致しません。 OSS エラー 403 とトラブルシューティング
Postobject ErrorCode: AccessDenied ErrorMessage: ポリシーにより無効です。ポリシーの有効期限が切れています。 ErrorCode: AccessDenied ErrorCode: AccessDenied ErrorMessage: ポリシーにより無効です。ポリシーの条件に適合しませんでした。 PostObject に含まれるポリシーが無効です。 PostObject
Cors ErrorCode: AccessForbidden ErrorMessage: CORSResponse: この CORS 要求は許可されていません。 このエラーは、通常、リソース側の CORS の仕様で、オリジンの評価、要求メソッド / Access-Control-Request-Method または Access-Control-Request-Headers がホワイトリストに登録されていないために発生します。 CORS が設定されていない、または正しく設定されていないません。 OSS 上でドメイン間アクセスを設定します。
Refers ErrorCode: AccessDenied ErrorMessage: バケットリファラーポリシーによって拒否されています。 バケットの OSS Anti-leech のリファラー設定を確認します。 OSS Anti-leech
AccessDenied 次の「一般的なアクセス許可エラー」をご参照ください。 アクセス許可がありません。 詳しくは、以下の内容をご参照ください。

アクセス許可エラーは 403 エラーの一部です。 アクセス許可の問題に関するエラーは、AccessDenied です。 これらのエラーについては、以下で詳しく説明します。

一般的なアクセス許可エラー

アクセス許可の問題は、現在のユーザーには操作を指定するアクセス許可がないことです。 OSS から返されるエラーとその原因については、次のテーブルをご参照ください。

SN エラー 原因
1 ErrorCode: AccessDenied ErrorMessage: アクセスしようとしているバケットは、指定されたエンドポイントを使用してアドレスを指定する必要があります。 今後、すべてのリクエストはこのエンドポイントに送信してください。 バケットがエンドポイントと一致しません。
2 ErrorCode: AccessDenied ErrorMessage: バケットを一覧表示することは禁止されています。 listBuckets に対する権限がありません。
3 ErrorCode: AccessDenied ErrorMessage: このオブジェクトに対する ACL の書き込み権限がありません。 setObjectAcl に対する権限がありません。
4 ErrorCode: AccessDenied ErrorMessage: このオブジェクトに対して ACL の読み取り権限がありません。 getObjectAcl に対する権限がありません。
5 ErrorCode: AccessDenied ErrorMessage: アクセスしたバケットは別のユーザーが所有しています。 サブアカウントには、バケットを管理する権限 (getBucketAcl、CreateBucket、deleteBucket、setBucketReferer、getBucketReferer など) はありません。
6 ErrorCode: AccessDenied ErrorMessage:バケットの ACL により、このオブジェクトにアクセスする権限がありません。 サブアカウント / 一時的なアカウントには、putObject、getObject、appendObject、deleteObject、postObject などのオブジェクトにアクセスする権限はありません。
7 ErrorCode: AccessDenied ErrorMessage: 権限付与ポリシーによりアクセスが拒否されています。 一時的なアカウントにはアクセス権がありません。 この一時的なアカウントのロールを引き継ぐために指定された権限付与ポリシーには権限がありません。
8 ErrorCode: AccessDenied ErrorMessage: このオブジェクトにアクセスする権限がありません。 サブアカウント / 一時的なアカウントには、initMultipartUpload のような現在の操作に対する権限がありません。

アクセス許可エラーのトラブルシューティング

キーがプライマリユーザー、サブアカウント、または一時的なアカウントのどれに使用されているかを確認します。

  • キーがプライマリユーザー用かどうかを確認します。

    コンソールにログインして、AccessKeyID が存在するかどうかを確認します。 存在する場合、キーはプライマリユーザー用です。

  • サブアカウントの権限 (権限付与ポリシー) を確認します。

    [Resource Access Management] > [ユーザーの管理] > [管理] > [ユーザーの詳細] > [ユーザーの AccessKey] と移動して、サブアカウントの AccessKeyID とそれに対応するサブアカウントを確認します。 > > > >

    コンソールにログインし、[Resource Access Management] > [ユーザーの管理] > [管理] > [権限付与ポリシー] > [個人用権限付与ポリシー/グループ用権限付与ポリシー] に移動し、権限を確認します。 > > > >

  • 一時的なアカウントの権限を確認します。

    一時的なアカウントの AccessKeyID は、”STS” で始まるため、簡単に識別することができます (例: “STS.MpsSonrqGM8bGjR6CRKNMoHXe”)。 コンソールにログインし、[Resource Access Management] > [ロールの管理] > [管理] > [ロールの権限付与ポリシー] > [権限の閲覧] に移動し、権限を確認します。 > > > >

次の図にアクセス権のエラープロセスを示します。

権限を確認する手順:

  1. 必要な権限とリソースを一覧表示します。
  2. [Action] に必要な操作が含まれているか確認します。
  3. [Resource] が必要な操作オブジェクトであるか確認します。
  4. [Effect] が “Deny” ではなく “Allow” であることを確認します。
  5. [Condition] が正しく設定されていることを確認します。

確認してもエラーの原因を見つけることができない場合は、次の調整が必要になります。

  1. 条件が削除されていることを確認します。
  2. [Effect] の “Deny” を削除します。
  3. [Resource] を “Resource”: “*” に変更します。
  4. [Action] を “Action”: “oss:*” に変更します。