Budibase/budibase · critical

Unable to access MinIO/S3 - check environment config.

Error message

Unable to access MinIO/S3 - check environment config.

What it means

exportObjects in the Budibase CLI backs up app data by listing objects in each MinIO/S3 bucket via the S3 client. It counts buckets whose list call failed; if every bucket failed to list, it concludes the object store is unreachable or misconfigured and throws this error so the backup aborts before downloading objects.

Source

Thrown at packages/cli/src/backups/objectStore.ts:63

export async function exportObjects() {
  const path = join(TEMP_DIR, MINIO_DIR)
  fs.mkdirSync(path, { recursive: true })
  let fullList: BackupObject[] = []
  let errorCount = 0
  for (let bucket of bucketList) {
    const client = ObjectStore()
    try {
      await client.headBucket({
        Bucket: bucket,
      })
    } catch (err) {
      errorCount++
      continue
    }
    fullList = fullList.concat(await listBucketObjects(client, bucket))
  }
  if (errorCount === bucketList.length) {
    throw new Error("Unable to access MinIO/S3 - check environment config.")
  }
  const bar = progressBar(fullList.length)
  let count = 0
  for (let object of fullList) {
    const filename = object.Key
    const data = await retrieve(object.bucket, filename)
    const possiblePath = filename.split("/")
    const destination = join(path, object.bucket, ...possiblePath)
    fs.mkdirSync(dirname(destination), { recursive: true })
    if (data instanceof stream.Readable) {
      await pipeline(data, fs.createWriteStream(destination))
    } else {
      fs.writeFileSync(destination, data)
    }
    bar.update(++count)
  }
  bar.stop()
}

View on GitHub (pinned to a81a902e9a)

Solutions

  1. Verify the MinIO/S3 service is running: `docker ps` for the minio container, or `curl` the S3 health endpoint
  2. Check the object-store env vars (MINIO_URL/MINIO_ACCESS_KEY/MINIO_SECRET_KEY or AWS equivalents) in the CLI environment match the running store
  3. Test credentials with an S3 client, e.g. `aws s3 ls s3://<bucket> --endpoint-url <url>`
  4. Confirm network reachability/DNS to the endpoint from the machine running the CLI
  5. Retain at least one reachable bucket or empty the bucket list if you intend to skip object data

Example fix

# before
MINIO_URL=http://localhost:9002  # MinIO container not started
# after
docker compose up -d minio  # then rerun export with correct MINIO_URL/keys
Defensive patterns

Strategy: retry

Validate before calling

import { S3Client, HeadBucket } from "@aws-sdk/client-s3"
async function assertObjectStoreReachable(client: S3Client, buckets: string[]) {
  for (const bucket of buckets) {
    await client.send(new HeadBucket({ Bucket: bucket })) // throws if unreachable
  }
}

Try / catch

try {
  await exportBackup(config)
} catch (err) {
  if ((err as Error).message.includes("Unable to access MinIO/S3")) {
    console.error("Object store unreachable: check MinIO container and MINIO_* env vars")
    // optionally retry with backoff after checking the service
  }
  throw err
}

Prevention

When it happens

Trigger: Running `budi backups export` (exportBackup -> exportObjects) when MinIO/S3 is not running, MINIO/S3 env vars (URL, access key, secret key) are wrong, credentials don't match, the bucket list is non-empty but every listBucketObjects call errors, or network/DNS blocks the S3 endpoint.

Common situations: Self-hosting where the Docker MinIO container is stopped; switching from MinIO to AWS S3 (or vice versa) without updating env config; expired/rotated access keys; typo'd MINIO_URL port; firewalled/offline environment.

Related errors


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