Skip to main content

Error message

This error can appear when using the following components: Data Transfer, Run Orchestration, S3 Load, and S3 Unload.

Explanation

AWS refused a request from the identity your Maia runner uses. Your pipeline logic is fine. The identity doesn’t have the permission named in the message.

Potential causes

  • The AWS Identity and Access Management (IAM) policy attached to the Maia runner‘s role or user doesn’t allow the action (for example s3:PutObject) on that bucket or path.
  • A bucket policy, service control policy, or permissions boundary blocks the action, even if the IAM policy allows it.
  • The data is encrypted with an AWS Key Management Service (KMS) key and the role isn’t allowed to use the key (kms:Decrypt to read, kms:GenerateDataKey to write).
  • The Maia runner is running under a different role than you expected.

Resolve the error

  1. Read the message and note three things: the identity, which is the Amazon Resource Name (ARN) after User:, the action after perform:, and the resource after on resource:.
  2. In AWS IAM, open that role or user and confirm a policy allows the action on the full resource ARN, including the folder prefix and /*. Here is an example policy statement. Replace the placeholders with your own values:
  3. Check the bucket policy and any organization-level policies for an explicit Deny that matches the identity or path.
  4. If the message names kms: actions, add them to the role’s policy and to the key policy of the KMS key that encrypts the bucket.
  5. Wait a few minutes for IAM changes to propagate, then re-run the pipeline.
  6. If you still need help, contact Maia Support and include the items listed below.
    • The full error text, including the role ARN.
    • The bucket, path, and KMS key involved (if any).
If a component transfers many files in a loop, every file fails with its own copy of this error. They all share one cause, so you only need to fix the permission once.

Prevent future errors

To prevent this error occurring again:
  • Scope permissions to the exact bucket and prefix the pipeline uses, and keep the policy in version control. For more information, read Cloud provider credentials.
  • Test a new role with a pipeline that moves a single file before running the full load.