Issues backing up to S3 Storage

[DelusionalAI]

I'm trying to add a backup to S3 storage, but unable to get it to work for both MinIO self hosted and Wasabi Cloud S3 Storage.
I am able to backup directly to these S3 if I use restic commands myself, but unable to though Backrest.

When I add the repo it appears add it just fine. Backrest gives no errors, I can see files in the buckets, and if I manually run a backup (restic CLI) or command like ls in backrest it works fine.

But when I go to run the backup plan it errors out like its trying to create a new repo or something.

Below is the repo and plan config, with passwords redacted

{
  "id": "F3",
  "uri": "s3:http://192.168.1.131:9000/restic-backup",
  "password": "REDACTED",
  "env": [
    "AWS_ACCESS_KEY_ID=REDACTED",
    "AWS_SECRET_ACCESS_KEY=REDACTED"
  ],
  "prunePolicy": {
    "maxUnusedPercent": 25,
    "schedule": {
      "maxFrequencyDays": 30
    }
  },
  "checkPolicy": {
    "readDataSubsetPercent": 0,
    "schedule": {
      "maxFrequencyDays": 30
    }
  },
  "commandPrefix": {}
}

And the plan

{
  "id": "Podman-F3",
  "repo": "F3",
  "paths": [
    "/userdata"
  ],
  "excludes": [],
  "iexcludes": [],
  "retention": {
    "policyKeepLastN": 30
  }
}

and the error I get when I try to run the backup

error: failed to initialize repo: init failed: command "/bin/restic-0.16.4 init --json -o sftp.args=-oBatchMode=yes" failed: command "/bin/restic-0.16.4 init --json -o sftp.args=-oBatchMode=yes" failed: exit status 1
Output:
Fatal: create repository at s3:http://192.168.1.131:9000/restic-backup failed: client.BucketExists: The Access Key Id you provided does not exist in our records.

I do have other backup plans to STFP/Rclone storage that is working fine, it's just these S3 ones that dont work. I thought it was an issue with the way I setup MinIO until I tired it with Wasabi and restic command manually.

[garethgeorge]

Following up with a quick summary of our findings in the other thread here --

Backrest propagates environment variables from the container's env when spawning restic commands. In this case we found there were some inadvertent AWS credential related env vars getting propagated to the container which were breaking the command.

For future users, this was possible to debug by execing the env command inside the container to inspect what environment variables were being set.

See #354 for full context.