remotion-dev/remotion · error · Error

Bucket owner mismatch: Expected the bucket ${bucketName} to

Error message

Bucket owner mismatch: Expected the bucket ${bucketName} to be owned by you (AWS Account ID: ${expectedBucketOwner}) but it's not the case. Did you accidentially specify the wrong bucket?

What it means

Thrown by list-objects after a two-step probe: the initial list call fails with AccessDenied, then the code retries the same ListObjectsV2 with customCredentials=null (using the account's default credentials). If that retry succeeds, it proves the bucket exists and is reachable but is NOT owned by the account you expected, so the original AccessDenied was an ownership mismatch rather than a missing permission.

Source

Thrown at packages/lambda-client/src/list-objects.ts:80

		} catch (err) {
			if (!expectedBucketOwner) {
				throw err;
			}

			// Prevent from accessing a foreign bucket, retry without ExpectedBucketOwner and see if it works. If it works then it's an owner mismatch.
			if ((err as Error).stack?.includes('AccessDenied')) {
				await getS3Client({
					region,
					customCredentials: null,
					forcePathStyle,
					requestHandler,
				}).send(
					new ListObjectsV2Command({
						Bucket: bucketName,
						Prefix: prefix,
					}),
				);
				throw new Error(
					`Bucket owner mismatch: Expected the bucket ${bucketName} to be owned by you (AWS Account ID: ${expectedBucketOwner}) but it's not the case. Did you accidentially specify the wrong bucket?`,
				);
			}

			throw err;
		}
	};

View on GitHub (pinned to 78fe4bb3fd)

Solutions

Verify the bucket name spelling and confirm it is the one created by your Remotion deploy in the current account/region.
Check that expectedBucketOwner matches the AWS account ID that actually owns the bucket.
If the bucket is intentionally cross-account, configure proper cross-account bucket policy + bucket-owner-enforced ACLs instead of relying on a mismatch.
Re-run npx remotion lambda regions and npx remotion lambda buckets to confirm the correct bucket.

Example fix

// before
renderMediaOnLambda({ bucketName: 'remotionlambda- Prod', ... }) // typo / wrong owner

// after
renderMediaOnLambda({ bucketName: 'remotionlambda-us-east-1-1234567890', ... }) // correct bucket for this account

Defensive patterns

Strategy: validation

Validate before calling

// Confirm the bucket belongs to the expected account before rendering
const owner = await getBucketOwnerName(bucketName); // via s3:GetBucketLocation + sts
if (owner !== expectedAccountName) {
  throw new Error(`Bucket ${bucketName} is owned by ${owner}, aborting render`);
}

Try / catch

try {
  await listObjects({ bucketName, region, expectedBucketOwner });
} catch (e) {
  if (e instanceof Error && /Bucket owner mismatch/.test(e.message)) {
    // surface a config error, do not retry blindly
    throw new Error('Configuration error: wrong bucket for this AWS account');
  }
  throw e;
}

Prevention

Keep the bucket name and AWS account in a single source of truth (e.g., deploy manifest).
Verify bucket ownership with aws s3api list-buckets after account switches.
Use unique bucket names per environment to avoid cross-account confusion.

When it happens

Trigger: listObjects receives AccessDenied on the first attempt, then a fallback ListObjectsV2 with customCredentials:null succeeds. This combination is interpreted as the bucket belonging to a different AWS account than expectedBucketOwner.

Common situations: Typo or copy/paste error in the bucket name passed to render/simulation APIs; pointing render at a bucket created by a different AWS account or a different region's deploy; AWS account switch without updating the bucket reference; cross-account access where the bucket name was reused.

Related errors

AI-assisted analysis of remotion-dev/remotion@78fe4bb3fd (2026-08-12). Data as JSON: /api/errors/036c8162b81e7a4a. Report an issue: GitHub.