Troubleshooting S3 connectivity
Symptom-first troubleshooting for Amazon S3 connectivity - ListAllMyBuckets 403s, the empty-AKID trap, AssumeRole denials, explicit denies, KMS, region mismatches, and inventory issues.
Resolve common Amazon S3 connectivity issues when integrating S3 with Atlan. Find the symptom you're seeing in the quick index - every error string below is a real signature (identifiers scrubbed).
Quick index
| You see | Most likely cause | Jump to |
|---|---|---|
Test connection 403: not authorized to perform: s3:ListAllMyBuckets | Missing/mis-scoped ListAllMyBuckets | ListAllMyBuckets |
AuthorizationHeaderMalformed ... non-empty Access Key (AKID) | Atlan-side allowlist missing - AssumeRole silently failed | Empty AKID |
AccessDenied when calling the AssumeRole operation | Trust policy or Atlan-side grant | AssumeRole |
Test passes; crawl fails on GetObjectTagging / HeadObject 403 | Permission policy trimmed below the full action list | Object permissions |
... with an explicit deny in a resource-based policy | Bucket policy Deny overrides your Allows | Explicit deny |
| Listing OK, object reads 403 on an encrypted bucket | KMS key policy missing Atlan's role | KMS |
PermanentRedirect ... must be addressed using the specified endpoint | Region mismatch (or hidden region field) | Region |
inventory_extract: No buckets name folders found | Inventory structure/permissions | Inventory |
| Connection ingested buckets you don't recognize | Atlan's ARN pasted into the IAM Role field | Wrong ARN |
Test connection fails: ListAllMyBuckets 403
Symptom. The most common S3 failure:
operation error S3: ListBuckets, https response error StatusCode: 403,
api error AccessDenied: User: arn:aws:sts::111122223333:assumed-role/
AtlanS3CrawlerRole/atlan-test-credential-helper is not authorized to
perform: s3:ListAllMyBuckets because no identity-based policy allows
the s3:ListAllMyBuckets action
Why. Test connection calls ListBuckets, which needs s3:ListAllMyBuckets - and that action only works with "Resource": "*". Scoping it to your bucket ARN (a natural security instinct) makes AWS ignore it.
Fix. Add the standalone statement from Phase 2 of the role guide. Reassure your security team: it reveals bucket names only. And atlan-test-credential-helper in the message is Atlan's own test session, not an intruder.
"AuthorizationHeaderMalformed" - the empty-AKID trap
Symptom. Test connection fails with Not able to authenticate your credentials and logs show:
operation error S3: ListBuckets, https response error StatusCode: 400,
api error AuthorizationHeaderMalformed: The authorization header is
malformed; a non-empty Access Key (AKID) must be provided in the credential.
Why. This is not a malformed key you typed. Atlan tried to assume your role, the borrow failed silently (role not yet allowlisted on Atlan's side, wrong tenant configured, or External ID mismatch), and the S3 call went out with empty credentials.
Fix. Confirm Phase 4 of the role guide actually happened: reply on your ticket and ask support to verify your exact role ARN is allowlisted for your exact tenant, and that the External ID on file matches your trust policy. Nothing on the AWS side needs changing if the trust policy is right.
AssumeRole is denied outright
An error occurred (AccessDenied) when calling the AssumeRole operation:
User: arn:aws:sts::999988887777:assumed-role/example-tenant-nodeinstance-role/i-0abc...
is not authorized to perform: sts:AssumeRole on resource:
arn:aws:iam::111122223333:role/AtlanS3CrawlerRole
Check in order:
- Trust policy: does it name the exact Node Instance Role ARN from your ticket as Principal? Copy-paste, don't retype.
- External ID: if the trust policy has an
sts:ExternalIdcondition, does the connection form carry the identical string? Remember some package workflows can't send one at all (Special cases). - Atlan side: ask support to confirm the AssumeRole grant for your role ARN - platform migrations have dropped role/External-ID settings from existing connections before.
- Using access keys, not a role? Then no AssumeRole should happen at all - a past Azure-tenant platform bug caused exactly this; cite the symptom on a support ticket.
Test passes, crawl fails on object permissions
Symptom. Test Authentication and preflight are green; the crawl then logs errors like:
... is not authorized to perform: s3:GetObjectTagging / s3:GetObjectRetention
/ s3:GetObjectLegalHold because no identity-based policy allows the action
-- or, from object detail fetches:
An error occurred (403) when calling the HeadObject operation: Forbidden
-- or, from miner/offline S3 access checks:
fatal error: An error occurred (AccessDenied) when calling the
ListObjectsV2 operation: Access Denied
Why. Test connection validates less than a crawl uses - it doesn't exercise the GetObject* actions.
Fix. Diff your policy against the full action table for your ingestion scope. Objects scope needs all four GetObject* actions on bucket/* resources.
Explicit deny in bucket policy
... is not authorized to perform: s3:ListBucket on resource:
"arn:aws:s3:::example-data-bucket" with an explicit deny in a
resource-based policy
Why. The bucket's own policy contains a Deny that matches Atlan, and in AWS one Deny beats any number of Allows. Common in "deny all except our VPC / except principals X" setups.
Fix. Your AWS admin adds Atlan's role to the exception (NotPrincipal / condition) list of each matching Deny - including on the inventory destination bucket if you use inventory ingestion. The phrase "resource-based policy" in the error is the tell that the fix is on the bucket, not your role.
Encrypted bucket: Listing works, reading doesn't
Symptom. Buckets and folders appear; object detail fetches or file downloads fail with 403 AccessDenied. In package/import flows the signature looks like:
software.amazon.awssdk.services.s3.model.S3Exception: Access Denied
(Service: S3, Status Code: 403, Request ID: ...)
at com.atlan.pkg.objectstore.S3Sync.downloadFrom(S3Sync.kt:198)
Why. SSE-KMS objects need kms:Decrypt + kms:DescribeKey on the key policy, separate from every S3 permission. Writes additionally need kms:GenerateDataKey.
Fix. The key-policy statement in Bucket policies, KMS keys, and prefix scoping. Note the same 403 also appears when the Atlan-side allowlist for your bucket is missing - if KMS is ruled out, ask support to verify their side.
PermanentRedirect - wrong region
Bucket credentials check failed ... With error code: PermanentRedirect -
The bucket you are attempting to access must be addressed using the
specified endpoint.
Why. The configured region doesn't match the bucket's home region. In offline/S3 extraction flows for other connectors, the region field can be hidden or mislabeled in the UI, silently defaulting to us-east-1.
Fix. S3 crawler: correct the region dropdown. Offline flows with no visible region field: raise a support ticket describing the missing field - the fix is applied tenant-side by engineering.
Inventory ingestion finds nothing
inventory_extract: No buckets name folders found in the account.
Error extracting bucket names with error: No active exception to reraise
Check: the destination bucket/prefix in the crawler form matches AWS exactly; the first report has actually been delivered (up to 48 h after enabling); the required folder structure is intact (source-bucket folder → config folder → timestamp folder → manifest.json + data); the role has s3:SelectObjectContent on the destination bucket; reports are CSV/Parquet, unencrypted, current-version-only.
Connection cataloged buckets you don't recognize
Symptom. Assets appear for buckets that aren't yours.
Why. Atlan's Node Instance Role ARN was entered in the crawler's "IAM Role" field, so the crawl ran as Atlan's own identity against Atlan's account.
Fix. Stop the workflow, delete the connection (removing the mis-crawled assets), and recreate it with your role's ARN. Report it on a ticket so Atlan can verify cleanup on their side.
Opening ticket that gets solved fast
Include these six things - they turn a multi-day exchange into one reply:
- Your Atlan tenant URL and the failing workflow run link
- Auth method (IAM role or access keys) and, for roles, your role ARN and whether the trust policy uses an External ID
- The exact error text from the workflow logs (the strings on this page are all distinct signatures)
- Bucket region(s), and whether buckets use SSE-KMS
- Whether Test Authentication passes, and whether a small-scope crawl works
- Whether it ever worked, and if so when it stopped (platform migrations matter - see Special cases)