dosya S3の認証とアクセスの問題を解決する

クライアントのプロファイルを変更する前に、S3エラーコード、メッセージ、HTTPステータス、リクエスト時刻をすべて控えてください。認証はプロトコル権限、ワークスペースの固定、メンバーシップ、フォルダーアンカー、ロール、アップロードポリシーより先に評価されるため、1つの問題を修正すると、別の理由で拒否されることがあります。

手順

連携 → S3と対応するAPIキーの行から、現在の値をコピーしてください：

クライアントの項目	必要な値
エンドポイント	https://api.dosya.dev/s3
リージョン	us-east-1
署名	AWS Signature Version 4
アドレス指定	パス形式。JavaScript AWS SDKではforcePathStyle: true
アクセスキー	DOSYAで始まる生成済みID。dos_… APIキーではありません
シークレットキー	そのアクセスIDと対になる40文字のS3シークレット
バケット	ws_exampleのような正確なワークスペースID。ワークスペース名ではありません

ホスト名にバケットを含めないでください。フォルダーに制限されたキーでもバケットはワークスペースIDのままで、オブジェクトキーはアンカーからの相対パスとして扱われます。アンカーがProjectsの場合、オブジェクトキーchecks/a.txtはProjects/checks/a.txtに到達します。Projects/を再度付けると、誤った入れ子のパスを探すことになります。

S3シークレットは後から取得できません。**（シークレットキーは取得できません。ローテーションするにはキーを無効化して再作成してください）**と表示された行で、クライアントに保存したシークレットを紛失した場合は、新しいキーと認証情報のペアが必要です。依存するクライアントを更新し、代替の動作を確認してから古いキーを失効させてください。失効は取り消せませんが、ファイルは削除されません。

実際の応答を確認する

S3の結果	確認する原因	対処
InvalidAccessKeyId / The access key ID does not exist	アクセスIDの誤り、失効または期限切れのキー、またはdos_…キーを貼り付けた	正しい行からDOSYA…アクセスIDをコピーします。その行が無効な場合は代替ペアを作成します。
SignatureDoesNotMatch / The request signature does not match	シークレットがアクセスIDと一致しない、またはクライアントが異なるエンドポイント、パス、クエリに署名した	対になるシークレット、エンドポイント、リージョン、パス形式のオプションを再入力します。失敗したリクエストを破棄し、SDKに新しいリクエストを署名させます。
AccessDenied / This API key is not permitted to use the S3 gateway	キーのプロトコル制限でS3が除外されている	Protocolsで**「S3」ゲートウェイ**を選択したキーを作成または置き換えます。
This API key is pinned to a different workspace	バケットとキーに固定されたワークスペースが一致しない	固定されたワークスペースに表示されるバケットIDを使うか、別の範囲を絞ったキーを発行します。
This role is not permitted to use the S3 gateway	メンバーのロールにS3アクセス権限がない	ワークスペースのオーナーまたは管理者にロールのS3権限の付与を依頼します。より広いキーでもロールの制限は上書きできません。
NoSuchBucket、オブジェクトが見つからない、または一覧が予想外に空	ワークスペースID、フォルダーからの相対パス、メンバーの範囲制限、非表示やロックの状態、ゴミ箱	許可されたバケットまたはルートの一覧を取得し、返された名前からパスを組み立てます。キーのオーナーのアカウントでdosyaのファイルと比較します。
Upload not allowed、Creating folders is not allowed、またはObject is locked	スコープやロールが操作を拒否している、または保存先がロックされている	許可された操作と保存先を選びます。ユーザーのロールを確認する前にキーの範囲を広げないでください。
EntityTooLarge	オブジェクトがファイルサイズポリシーまたは有効なキーやロールの制限を超えている	返されたメッセージを読み、許可されるファイルを使うか、権限のある管理者に該当する制限の変更を依頼します。
QuotaExceeded	ワークスペースの空き容量が不足している	次のマルチパートアップロードを開始する前に空き容量を確保するか、ストレージ容量を増やします。
429 XML SlowDown	明示的なリクエスト、転送、バイト数のルールが操作を拒否した	Retry-Afterがあれば従います。同時実行の制限には並列転送を減らします。バイト数の上限にはリセットを待つか、権限のある人による制限変更が必要です。
429 JSON Too many requests	フロントドアの制限でユーザーあたり毎分600件またはIPあたり毎分1,200件に達した	Retry-Afterの間待ち、ポーリングや一覧取得の頻度を下げ、同じ識別情報やアドレスを共有するクライアントの実行をずらします。

署名付きリクエストでは、X-Amz-Expiresは1〜604,800秒の整数である必要があります。Request has expiredは署名の有効期間が終了したことを示します。署名されたパラメーターを変更すると署名が無効になるため、クエリを変更せず新しいURLを生成してください。

期待される結果

1. 正確なワークスペースバケットまたは許可されたプレフィックスの一覧を取得します。バケットの検出が成功しても、確認できるのは表示範囲であり、アップロードや削除の権限ではありません。
2. 影響のない既知のオブジェクトを新しいローカルパスにダウンロードし、サイズまたはSHA-256を転送元と比較します。
3. キーとロールでアップロードが許可されている場合は、許可された使い捨てのプレフィックスに一意の名前のテストデータを送信します。HTTP 200を待ち、ファイルを更新してからオブジェクトをダウンロードして比較します。
4. 失敗したマルチパートアップロードはクライアントから中止します。ローカルでのキャンセルでは未完了のパートが残ることがあります。

一覧の1ページあたりの上限は1,000件です。クライアントは継続トークンをたどる必要があります。マルチパートのパート番号は1〜10,000で、プロトコル上のパートの最大サイズは5 GiBですが、実際のオブジェクト、ストレージ、認証情報、ロールの制限はそれより大幅に小さい場合があります。

成功後に予期しない変更があった場合

既存のdosyaパスにアップロードすると、新しいファイルバージョンが作成されます。これはAWSのバージョンIDではなく、バージョン履歴と保持のルールは引き続き適用されます。対象のオブジェクトを削除するとゴミ箱に移動し、共有リンクが失効します。オブジェクトが既になくても204が返ることがあります。ゴミ箱は完全に削除されるまでストレージを消費し続けます。完全な削除は取り消せません。

ゲートウェイはAWS IAM/ACL管理、ライフサイクルルール、レプリケーション、S3バージョニング、Object Lock/法的保留を提供しません。非対応機能の設定書き込みにはNotImplementedが返されます。ツールがこれらの保証を必要とする場合、認証情報を変更してもそのワークロードには対応できません。

認証情報を公開せずに問い合わせる

最小限の一覧取得でも失敗する場合は、クライアントとバージョン、エンドポイント、リージョン、アドレス指定方式、バケットID、メソッド、オブジェクトプレフィックス、HTTPステータス、S3コードとメッセージ、おおよその時刻とタイムゾーン、キーがワークスペースやフォルダーに制限されているかを伝えてください。ポリシーで必要な場合はアクセスIDを伏せ、シークレットキー、Authorizationヘッダー、署名付きクエリ、非公開オブジェクトの完全なパスは送信しないでください。

関連ガイド

• S3に接続する
• S3権限を制限する