[BUG] Bucket browser signs S3 requests against console base path behind reverse proxy

[michaelbrusegard]

Bug Report

Description

When the RustFS console is served behind a path-based reverse proxy at /rustfs/console/, the bucket browser appears to use that console path as the S3 endpoint.

This makes signed S3 requests fail with SignatureDoesNotMatch.

Steps to Reproduce

1. Serve the RustFS console at https://rustfs.example.com/rustfs/console/
2. Expose the RustFS S3/API endpoint at the same host root: https://rustfs.example.com/
3. Log in to the console with valid credentials.
4. Open the bucket browser.

Expected Behavior

The bucket browser should send S3 requests to the API root, for example:
https://rustfs.example.com/?x-id=ListBuckets

Actual Behavior

The bucket browser sends the request under the console base path:
https://rustfs.example.com/rustfs/console/?x-id=ListBuckets

This returns 403 SignatureDoesNotMatch, and the UI shows “No Buckets”.

Environment

• RustFS version: 1.0.0-alpha.99
• Deployment: Kubernetes
• Install method: official RustFS Helm chart
• Reverse proxy / ingress: Kubernetes Gateway API with Cilium Gateway
• RustFS API/S3 route: https://rustfs.example.com/ → RustFS service port 9000
• RustFS console route: https://rustfs.example.com/rustfs/console/ → RustFS service port 9001
• Client OS: macOS
• Client browser: Firefox

Error Details

Failed to fetch buckets: SignatureDoesNotMatch: The request signature we calculated does not match the signature you provided. Check your key and signing method.

GET https://rustfs.example.com/rustfs/console/?x-id=ListBuckets
HTTP/2 403

Additional Context

The API and console are routed separately because RustFS exposes them on different service ports: 9000 for S3/API and 9001 for the console. The console is also served under its built-in /rustfs/console/ base path. That routing works for loading the UI and for direct S3/API calls, but the bucket browser seems to sign S3 requests against the console base path instead of the API root.

The same credentials work against the S3 API directly:

aws --endpoint-url https://rustfs.example.com s3 ls

A reverse proxy cannot safely rewrite /rustfs/console/?x-id=ListBuckets to /?x-id=ListBuckets, because S3 signatures include the request path.

It would help if the console allowed the S3 endpoint to be configured separately from the console base path.

Checklist

• I have searched existing issues to ensure this is not a duplicate
• I have included steps to reproduce
• I have tested in the latest version

[michaelbrusegard]

If it helps, I have my cluster managed declaratively via fluxcd gitops in an open source repo and the rustfs part is here: https://github.com/michaelbrusegard/nix-config/tree/main/gitops/espresso/infrastructure/controllers/rustfs. But I am still completely new to rustfs and I have less than a month of experience with kubernetes so it may be that I have made a mistake ofc. Thank you for your amazing work on this btw!

[thijs-s]

Same deployment shape here (console at /rustfs/console/, S3 elsewhere behind a reverse proxy). As an immediate workaround you can set NEXT_PUBLIC_S3_ENDPOINT=https://rustfs.example.com (or NEXT_PUBLIC_SERVER_HOST=https://rustfs.example.com) at build time, that pins the S3 endpoint independently of the console basePath and should make ListBuckets sign against / again. For a configuration where S3 lives at a different path prefix on the same origin (not at root), I opened a feature request that proposes a separate NEXT_PUBLIC_API_PREFIX knob plus a SigV4 path-strip: #108 . Slightly different symptom from yours, but adjacent enough that the maintainer fix may want to consider both.

[michaelbrusegard]

The only annoying part is that I would have to set "NEXT_PUBLIC_S3_ENDPOINT" before building the image, which works poorly when I use a prebuilt image

[thijs-s]

true, this is my pain as well, but as for now I don't see any quick workaround. try to check this #109 if its anyhow helpful