Issue Station
Sign In
Tools hereToolbox

n8n - 💡(How to fix) Fix S3 binary storage with AWS IAM Roles for Service Accounts (IRSA) is broken in n8n v2.18 [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
n8n-io/n8n#29350•Fetched 2026-04-28 06:49:15
View on GitHub
Comments
1
Participants
2
Timeline
6
Reactions
0
Author
jsnellinkjsnellink
Participants
jsnellinkjsnellinkn8n-assistant[bot]n8n-assistant[bot]
Timeline (top)
labeled ×3commented ×1mentioned ×1subscribed ×1

Error Message

When upgrading from n8n version 2.16 to n8n version 2.18 in our self-hosted deployment while using S3 binary storage + IRSA for authentication, the main and worker pods fail to start with the error: The user-facing log message hides the real error. Running the same Error: [EntityReplacer] Invalid character '#' in entity name: "#xD" S3 operation. By the time S3 is mentioned in n8n's error message,

Code Example

The S3 configuration is unchanged, and rolling back to the previous n8n version fixes the problem.

See Debug information, but I believe that the underlying issue is tied to the `fast-xml-parser` in the root `package.json` which either needs to be rolled back to the previous version, or forward to `5.7.2` (which the upstream changelog says re-allows numeric character references)

### To Reproduce

1. Run **n8n 2.18.0**
2. Configure S3 binary storage
N8N_DEFAULT_BINARY_DATA_MODE=s3
N8N_EXTERNAL_STORAGE_S3_HOST=s3.<region>.amazonaws.com 
N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME=<bucketname>
N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION=<region> 
N8N_EXTERNAL_STORAGE_S3_AUTH_AUTO_DETECT=true


3. Annotate the n8n ServiceAccount for IRSA so the pod has
`AWS_ROLE_ARN` and `AWS_WEB_IDENTITY_TOKEN_FILE` set.
4. Start the pod.
The pod crashloops with the "Failed to connect to S3" message above.
The same configuration on previous n8n releases works correctly.

### Expected behavior

n8n pods connect to s3 and start successfully

### Debug Info

The user-facing log message hides the real error. Running the same
`HeadBucketCommand` directly with the AWS SDK that ships inside the
2.18.0 image produces this stack:
RAW_BUFFERClick to expand / collapse

Bug Description

When upgrading from n8n version 2.16 to n8n version 2.18 in our self-hosted deployment while using S3 binary storage + IRSA for authentication, the main and worker pods fail to start with the error: Failed to connect to S3 for binary data storage. Please check your S3 configuration.

The S3 configuration is unchanged, and rolling back to the previous n8n version fixes the problem.

See Debug information, but I believe that the underlying issue is tied to the fast-xml-parser in the root package.json which either needs to be rolled back to the previous version, or forward to 5.7.2 (which the upstream changelog says re-allows numeric character references)

To Reproduce

  1. Run n8n 2.18.0

  2. Configure S3 binary storage N8N_DEFAULT_BINARY_DATA_MODE=s3 N8N_EXTERNAL_STORAGE_S3_HOST=s3.<region>.amazonaws.com N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME=<bucketname> N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION=<region> N8N_EXTERNAL_STORAGE_S3_AUTH_AUTO_DETECT=true

  3. Annotate the n8n ServiceAccount for IRSA so the pod has AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE set.

  4. Start the pod. The pod crashloops with the "Failed to connect to S3" message above. The same configuration on previous n8n releases works correctly.

Expected behavior

n8n pods connect to s3 and start successfully

Debug Info

The user-facing log message hides the real error. Running the same HeadBucketCommand directly with the AWS SDK that ships inside the 2.18.0 image produces this stack:

Error: [EntityReplacer] Invalid character '#' in entity name: "#xD"

at [email protected]/lib/fxp.cjs at @aws-sdk/core/.../protocols/index.js at de_AssumeRoleWithWebIdentityCommand (@aws-sdk/nested-clients/.../sts/index.js)

Notes:

  • The HTTP status from AWS STS is 200 — STS replied successfully. The crash is purely on XML deserialization inside the AWS SDK.
  • The failing call is AssumeRoleWithWebIdentity (STS), not any S3 operation. By the time S3 is mentioned in n8n's error message, the SDK has already failed to obtain credentials.

the fast-xml-parser Changelogs show that "numerical external entity" was removed as a breaking change in 5.7.0 and then re-allowed in version 5.7.2: https://github.com/NaturalIntelligence/fast-xml-parser/blob/master/CHANGELOG.md

Operating System

Alpine 3.22

n8n Version

2.18.0

Node.js Version

24.14.1

Database

PostgreSQL

Execution mode

queue

Hosting

self hosted

extent analysis

TL;DR

The issue can be resolved by updating the fast-xml-parser version to 5.7.2 to re-allow numeric character references.

Guidance

  • The error is caused by the fast-xml-parser version 5.7.0 which removes support for numeric external entities, leading to a deserialization failure in the AWS SDK.
  • To fix the issue, update the fast-xml-parser version to 5.7.2 which re-allows numeric character references.
  • Verify the fix by checking the n8n pod logs for successful startup and S3 connection.
  • If updating the fast-xml-parser version is not feasible, consider rolling back to the previous n8n version as a temporary workaround.

Example

No code snippet is necessary for this issue, as the solution involves updating a dependency version.

Notes

The issue is specific to the fast-xml-parser version 5.7.0 and the AWS SDK's use of numeric character references. Updating to 5.7.2 should resolve the issue.

Recommendation

Apply the workaround by updating the fast-xml-parser version to 5.7.2, as it is a targeted fix for the specific issue caused by the version 5.7.0.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

n8n pods connect to s3 and start successfully

#response parsing#generation error#database connection#vector store#embedding generation

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

n8n - 💡(How to fix) Fix S3 binary storage with AWS IAM Roles for Service Accounts (IRSA) is broken in n8n v2.18 [1 comments, 2 participants]