Budibase/budibase · critical

Access denied to object store bucket.${err}

Error message

Access denied to object store bucket.${err}

What it means

createBucketIfNotExists catches errors from the S3 CreateBucket call; when the SDK reports HTTP status 403 it rethrows as 'Access denied to object store bucket.' meaning the configured credentials are not permitted to create (or access) the bucket. Other statuses fall through to promise-dedup/existence handling.

Source

Thrown at packages/backend-core/src/objectStore/objectStore.ts:186

  client: any,
  bucketName: string
): Promise<{ created: boolean; exists: boolean }> {
  bucketName = sanitizeBucket(bucketName)
  try {
    await client.headBucket({
      Bucket: bucketName,
    })
    return { created: false, exists: true }
  } catch (err: any) {
    const statusCode =
      err.statusCode ||
      err.$response?.statusCode ||
      err.$metadata?.httpStatusCode
    const promises: Record<string, Promise<any> | undefined> =
      STATE.bucketCreationPromises

    if (statusCode === 403) {
      throw new Error("Access denied to object store bucket." + err)
    }

    if (promises[bucketName]) {
      await promises[bucketName]
      return { created: false, exists: true }
    }

    // Attempt to create the bucket for any headBucket failure that is not an
    // explicit access denial. This covers 404 (not found) and non-standard
    // status codes returned by S3-compatible stores such as Ceph RadosGW.
    promises[bucketName] = client
      .createBucket({
        Bucket: bucketName,
      })
      .catch((err: any) => {
        // bucket was created in the meantime by another process
        if (
          err.Code !== "BucketAlreadyOwnedByYou" &&

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Verify AWS/MinIO credentials (access key, secret, region/endpoint) configured for the object store are current and correct
  2. Grant the credential's IAM policy permissions: s3:CreateBucket, s3:PutObject, s3:GetObject, s3:DeleteObject, s3:ListBucket on the target bucket/prefix
  3. Pre-create the bucket manually (aws s3 mb / MinIO mc mb) with correct ownership if credentials cannot create buckets
  4. Restart or re-login after any credential rotation; check MinIO container logs for auth failures

Example fix

// before (IAM policy)
{ "Effect": "Deny", "Action": "s3:CreateBucket", "Resource": "*" }
// after
{ "Effect": "Allow", "Action": ["s3:CreateBucket", "s3:PutObject", "s3:GetObject", "s3:DeleteObject", "s3:ListBucket"], "Resource": ["arn:aws:s3:::budibase-apps", "arn:aws:s3:::budibase-apps/*"] }
Defensive patterns

Strategy: try-catch

Validate before calling

async function canAccessBucket(client, bucket) {
  try {
    await client.send(new HeadBucketCommand({ Bucket: bucket }))
    return true
  } catch (e) {
    return e?.$metadata?.httpStatusCode !== 403 && e?.$response?.statusCode !== 403
  }
}

Try / catch

try {
  await createBucketIfNotExists(client, bucketName)
} catch (err) {
  if (String(err.message).startsWith("Access denied to object store bucket")) {
    // do not retry blindly — credentials/permissions must be fixed first
  }
}

Prevention

When it happens

Trigger: Any path that lazily creates a bucket (deleteFile, deleteFiles, importObjects, bucketCreated hooks) hitting an S3/MinIO API that returns 403 — wrong credentials, missing s3:CreateBucket permission, or bucket owned by another account.

Common situations: MinIO credentials changed in docker-compose but not in Budibase env; IAM user lacking CreateBucket/PutObject policies; AWS S3 bucket name already taken by another account (can surface as access issues); expired cloud credentials/keys rotated.

Understand the failure class

Related errors

AI-assisted analysis of Budibase/budibase@a81a902e9a (2026-08-29). Data as JSON: /api/errors/ca0fe187f8c97e1d. Report an issue: GitHub.