Cannot backup to SeaweedFS objectstore

[rhorvath77]

When creating ObjectStore CR that points to SeaweedFS s3 objectstore it starts uploading the wal archives, makes a .upload directory, but then I got the error:
{"level":"error","ts":"2025-12-16T10:46:23.075022375Z","msg":"Error while handling GRPC request","logging_pod":"postgresql-1","info":{"Server":{"Client":{"Client":{}},"InstanceName":"postgresql-1","SpoolDirectory":"/controller/wal-restore-spool","PGDataPath":"/var/lib/postgresql/data/pgdata","PGWALPath":"/var/lib/postgresql/data/pgdata/pg_wal"},"FullMethod":"/cnpgi.wal.v1.WAL/Archive"},"error":"unexpected failure invoking barman-cloud-wal-archive: exit status 4","stacktrace":"github.com/cloudnative-pg/machinery/pkg/log.(*logger).Error\n\t/go/pkg/mod/github.com/cloudnative-pg/machinery@v0.3.1/pkg/log/log.go:125\ngithub.com/cloudnative-pg/cnpg-i-machinery/pkg/pluginhelper/http.(*Server).Start.logFailedRequestsUnaryServerInterceptor.func2\n\t/go/pkg/mod/github.com/cloudnative-pg/cnpg-i-machinery@v0.4.1/pkg/pluginhelper/http/grpc.go:53\ngoogle.golang.org/grpc.NewServer.chainUnaryServerInterceptors.chainUnaryInterceptors.func1\n\t/go/pkg/mod/google.golang.org/grpc@v1.76.0/server.go:1234\ngithub.com/cloudnative-pg/cnpg-i/pkg/wal._WAL_Archive_Handler\n\t/go/pkg/mod/github.com/cloudnative-pg/cnpg-i@v0.3.0/pkg/wal/wal_grpc.pb.go:196\ngoogle.golang.org/grpc.(*Server).processUnaryRPC\n\t/go/pkg/mod/google.golang.org/grpc@v1.76.0/server.go:1431\ngoogle.golang.org/grpc.(*Server).handleStream\n\t/go/pkg/mod/google.golang.org/grpc@v1.76.0/server.go:1842\ngoogle.golang.org/grpc.(*Server).serveStreams.func2.1\n\t/go/pkg/mod/google.golang.org/grpc@v1.76.0/server.go:1061"}

However, with awscli I can reach the bucket and can upload objects

Objectstore definition
`
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
name: azure-backup-store
namespace: postgres
spec:

Base configuration for Barman Cloud to connect to Azure

configuration:
destinationPath: "s3://backups"
endpointURL: "http://seaweedfs-s3.seaweedfs.svc.cluster.local:8333"
s3Credentials:
accessKeyId:
name: aws-creds
key: ACCESS_KEY_ID
secretAccessKey:
name: aws-creds
key: ACCESS_SECRET_KEY
wal:
compression: gzip
data:
jobs: 2
`

Cluster definition:
`
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: postgresql
namespace: postgres
spec:
instances: 1
storage:
size: 2Gi

plugins:

• name: barman-cloud.cloudnative-pg.io
  isWALArchiver: true
  parameters:
  barmanObjectName: azure-backup-store
  serverName: postgresql

bootstrap:
initdb:
database: authentik
owner: authentik
secret:
name: authentik-secret

enableSuperuserAccess: true
superuserSecret:
name: pgsuperuser
`

I also tried other options, and all of them worked except for the Barman Cloud Plugin, which drops an error.

[dosubot]

Hi @rhorvath77! I'm Dosu and I’m helping the plugin-barman-cloud team.

This error is common when using the Barman Cloud Plugin with S3-compatible storage like SeaweedFS. Even if awscli works, the plugin may hit S3 API quirks or compatibility issues. The most effective workarounds are:

• Add these environment variables to your ObjectStore's instanceSidecarConfiguration.env:

  - name: AWS_REQUEST_CHECKSUM_CALCULATION
    value: when_required
  - name: AWS_RESPONSE_CHECKSUM_VALIDATION
    value: when_required

  This resolves checksum header issues seen with many S3-compatible backends, including MinIO, Ceph, and Hitachi HCP. Source

• If you see signature version errors in logs, try also setting:

  - name: AWS_S3_SIGNATURE_VERSION
    value: s3

  or

  - name: AWS_S3_SIGNATURE_VERSION
    value: s3v4

  Some S3-compatible providers require explicit signature version configuration. Source

• Increase WAL backup verbosity to get more detailed logs:

  wal:
    archiveAdditionalCommandArgs:
      - "-vv"

  This can help spot malformed headers or subtle credential issues. Source

• Double-check your secrets for whitespace or formatting errors, as these can break S3 authentication. Source

• If you still see errors, some users have resolved S3 compatibility by downgrading the boto3 library in the plugin sidecar to version <1.36 (e.g., 1.35.99). Source

SeaweedFS is not officially listed as a supported backend, but these steps have resolved similar issues for other S3-compatible services. If you try these and still get exit status 4, check the plugin logs for S3 API error messages (like InvalidArgument, Unknown signature version, or checksum mismatch) to further narrow down the cause.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}