QuickSight から S3 を参照した際に「MANIFEST_NO_FILES_FOUND」エラーになった時の対処法
2025.07.10発生した事象
QuickSight にて新規データセット作成から S3 を選び、ローカルからマニフェストファイルをアップロードすると以下のエラーが発生しました。
sourceErrorCode: MANIFEST_NO_FILES_FOUND
sourceErrorMessage: Input Manifest hogehoge does not contain any valid URIs
エラー原因として以下の観点で調査しましたが、全て問題ありませんでした。
- マニフェストファイルに構文エラーが無いか
- S3 にマニフェストで指定しているオブジェクトが実在するか
- マニフェストファイル内で指定している S3 オブジェクトパスに誤りが無いか
- QuickSight から当該 S3 バケットに対するアクセス権限があるか
結論として、本エラーは S3 バケットポリシーにて QuickSight サービスロールに対する s3:GetObject アクションが許可されていないために起こっています。
そのため、本ブログでは、実際に事象を再現させて、どのような状況だったか確認してみたいと思います。
S3 バケットの作成
S3 バケット(test-qs-error-bucket)をデフォルト設定で作成します。
適当なサンプルデータを作成し、S3 へアップロードします。
TeamID,prefecture,point
TEAM_A,okinawa,100
TEAM_A,tokyo,200
TEAM_B,osaka,300
TEAM_B,nara,400
アップロードが完了しました。
続いて、S3 のバケットポリシーにて以下のように s3:GetObject アクションを拒否する設定を入れておきます。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "test",
"Effect": "Deny",
"Principal": {
"AWS": "*"
},
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::test-qs-error-bucket",
"arn:aws:s3:::test-qs-error-bucket/*"
]
}
]
}
QuickSight でデータセットを作成する
ローカルにて S3 オブジェクトを指定するマニフェストファイルを作成します。
{
"fileLocations": [
{
"URIs": [
"s3://test-qs-error-bucket/sample_data.csv"
]
}
],
"globalUploadSettings": {
"format": "CSV",
"delimiter": ",",
"containsHeader": "true"
}
}
QuickSight でマニフェストファイルをアップロードし、新規データセットを作成してみます。
MANIFEST_NO_FILES_FOUND エラーとなり、データ読み込み接続ができませんでした。
続いて、上記エラーを解消するため S3 バケットポリシーにて指定した当初の Deny ルールを削除し、QuickSight サービスロール aws-quicksight-service-role-v0 を許可した以下の Allow ルールを設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "test",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::<アカウント ID>:role/service-role/aws-quicksight-service-role-v0"
},
"Action": "s3:GetObject",
"Resource": [
"arn:aws:s3:::test-qs-error-bucket",
"arn:aws:s3:::test-qs-error-bucket/*"
]
}
]
}
上記設定後、QuickSight で再度データセットを作成します。今度はエラーが出ず、無事データセットを作成することができました。
ちなみに検証をしていて気づいたので以下内容は蛇足ですが、S3 バケットポリシーに何も指定しない（ポリシーが空の状態）でも、データセット作成は成功します。
バケットポリシーで明示的に QuickSight からの s3:GetObject アクションを許可していないのになぜ成功するの？と思ったのですが、理由は QuickSight のデフォルトのサービスロール aws-quicksight-service-role-v0 にて、同アクションが許可されているからですね。
以下は、本ブログ検証時の IAM ロール aws-quicksight-service-role-v0 の AWSQuickSightS3Policy の抜粋になります。
{
"Version": "2012-10-17",
"Statement": [
...
{
"Action": [
"s3:ListBucket"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::test-qs-error-bucket"
]
},
{
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::test-qs-error-bucket/*"
]
}
]
}
上記より、ちゃんと GetObject が許可されていることがわかります。
S3 のバケットポリシーが未設定の状態でも上記のように IAM ポリシー側でアクションを許可していれば、アクセスは成功します。
詳細は下記ブログをご参照ください。
以上で検証は終了です！
終わりに
今回のブログでは MANIFEST_NO_FILES_FOUND エラーを実際に発生させて、解消してみました。
本エラーはパッと見 マニフェスト周りの設定内容を疑ってしまうようなエラーですが、S3 バケットポリシーの設定不備でも起きる問題だと分かりました。今後は気をつけたいと思います。
なお、MANIFEST_NO_FILES_FOUND エラーについては、下記ブログでも過去に扱っているため、お困りの方がいればこちらも併せてご確認ください。
本記事がどなたかのお役に立てば幸いです。お疲れ様でした〜
