Skip to main content

​
Access

Cause: The bucket policy (or your role’s read policy) doesn’t grant the Auxia role read access, or it names the wrong bucket.Fix:
  • Confirm the policy’s Principal is the role ARN shown in the wizard for this Auxia project.
  • Confirm Resource lists both arn:aws:s3:::your-bucket-name and arn:aws:s3:::your-bucket-name/* — listing needs the first, reading files needs the second.
  • Confirm both actions are present: s3:GetObject and s3:ListBucket.
  • If the bucket already had a policy, confirm the Auxia statement was added to it and didn’t replace another statement your team relies on (or vice versa).
The wizard names the missing permission — “Missing s3:ListBucket” (the bucket ARN is missing from Resource) or “Missing s3:GetObject” (the /* object ARN is missing). Re-apply the policy from the wizard and click Check Access again.
Cause: The bucket is encrypted with a KMS key that the Auxia role can’t use.Fix: Add kms:Decrypt and kms:DescribeKey for the role to the KMS key policy. See the KMS step in the setup guide.
Cause: Customer-provided encryption keys (SSE-C) aren’t supported by the transfer service.Fix: Re-encrypt the data with SSE-S3 or SSE-KMS.
Cause: The role’s trust policy doesn’t match the one the wizard generated, or the wrong role ARN was pasted back.Fix: Re-run the wizard’s create-role command — it’s safe to run again and resets the trust policy to the correct value. Then paste the ARN of that role.
Cause: The bucket is empty at the top level, or access was granted on a different bucket.Fix: The wizard says so explicitly rather than showing an empty screen. Check the bucket name, and type a prefix to jump to the folder that holds your data.

​
Files and folders

Cause: The file isn’t comma-separated (semicolon, tab, or pipe). The wizard refuses these and shows the header it read.Fix: Re-export the data comma-separated with a header row, or as Parquet.
Cause: The file is a single JSON array ([{...}, {...}]), not newline-delimited JSON.Fix: Re-export as newline-delimited JSON — one object per line, with a .ndjson or .jsonl extension — or as Parquet.
Cause: Auxia couldn’t tell what format the files are in — often whole-file compression (.csv.gz, .parquet.gz), archives, or mixed formats in one folder. Compressed files aren’t read.Fix: Use uncompressed Parquet (with its built-in block compression), CSV, or newline-delimited JSON, one format per folder. For archives or PGP-encrypted files, contact your Auxia point of contact.
Cause: A parent folder holding several tables was selected, so everything under it was read as one table.Fix: Set up the connection again and select each table’s own folder. See One folder per table.
Cause: Your folder names read two ways — 03-04-2026 could be 3 April or 4 March.Fix: Pick the format that matches how your folders are written. Choosing wrong doesn’t error later; it reads the wrong day every day.
Cause: Auxia couldn’t identify what the table holds or which columns carry the required fields.Fix: On the Map step, set the table type (events or user attributes) and mark the user ID and timestamp columns. Without a schema type, rows are ingested as events.
Cause: Going back to the Map step and forward again creates a second, inactive copy.Fix: Enable only the configuration you reviewed. The other stays switched off.

​
After the connection is live

Cause: Setup completed, but enabling ingestion failed.Fix: Contact your Auxia point of contact before trying again — retrying creates duplicate configurations.
Cause: The folder layout was misread — compact date folders such as dt=20261002 are the most common case.Fix: On the Schedule step, set the Partition folder prefix and Date format yourself. If the configuration is already live, contact your Auxia point of contact to correct it and backfill the affected days.
Cause: The lookup table that resolves the user ID wasn’t selected in the same setup, or its key doesn’t match the events table’s key.Fix: Set up the events table and its lookup table together, joined on the shared key, and check that the key values actually overlap.
Cause: The run found no new data. Usually the partition folder prefix or date format doesn’t match your folder names, so Auxia looks for a folder that doesn’t exist.Fix: Compare a real folder name (for example dt=2026-10-02) with the prefix and format on the configuration. Contact your Auxia point of contact to correct them, then request a backfill for the missed days.
Cause: Your files land after the daily run starts. A run that finds nothing reports success, not failure.Fix: Tell your Auxia contact when your files typically land so the data delay can be set to match, then request a backfill for the missed days.
Cause: Files were overwritten in place. Sources must be append-only.Fix: Write corrected data as a new file with a new name, then ask your Auxia contact to backfill the affected day.

​
Still stuck?

Contact support@auxia.io or your Auxia point of contact. Include your connection name, the folder path, and a screenshot of the error.