この件に関するすべてのトピックとチュートリアルを検索し、作業したと思いますが、\n\nバックアップページを開こうとすると、常にこのエラーが発生します。\n\u003e /admin/backups.json の読み込み中にエラーが発生しました\n\n/admin/backups.json を開くと、「アクセス拒否」という一般的なエラーしか表示されません。\n\n理解できないのは、EC2インスタンスで次のコマンドを実行すると正常に動作することです。\n\n\u003e aws s3 ls s3://my-bucket-name\n\nそして、./launcher enter app を使用してディスコースコンテナに入り、s3cmd をインストールした後、これも正常に実行できます。\n\n\u003e s3cmd ls s3://my-bucket-name\n\nこれらのコマンドを使用してバケットにファイルをアップロードすることもできるため、IAM ポリシーは問題ないはずであり、ディスコースがバケットにアクセスできない理由がわかりません。また、権限がきつすぎる問題を排除するために、IAM ロールに「AdministratorAccess」を追加しようとしました。\n\nディスコースでの設定：\n\nバックアップの場所：S3\ns3 バックアップバケット：my-bucket-name\ns3 IAM プロファイルを使用：true\ns3 リージョン：正しいもの。トリプルチェック済み。\n\n\n残りの s3 オプションはそのままです → そのため、ほとんどが空/無効になっています。\n\n何が間違っている可能性があるか、何かアイデアはありますか？\n\nありがとうございます！
これはS3の設定とは関係ないと思います。Discourseの内部的な権限メッセージのように聞こえます。ページとして /admin/backups を読み込むことはできますか（末尾に.jsonを付けずに）？
「いいね！」 1
このような問題をデバッグする最も簡単な方法は、Cloudtrail ログを確認することです。
これは素晴らしいヒントでした。権限エラーを特定でき、Discourse が別のユーザーを使用していることがわかりました。さて、なぜ誰もこのエラーを経験しなかったのか、その大きな理由です。
AWS SNS を介してプッシュ通知を送信するためのカスタムプラグインがあり、Aws.config.update を介してグローバルに認証情報を設定していました。そのため、S3 バックアップも、明らかに必要な権限を持っていなかった間違った認証情報を使用していたようです。
現在、プラグインを修正して、認証情報/リージョンをローカルで提供し、EC2 IAM ロールをサポートするようにします。これは現時点では好ましいです 
正しい方向へのプッシュに感謝します！
paresy
「いいね！」 2
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.