Hi,
PBS 4.1.8, S3 datastore on DreamHost DreamObjects. Backups stopped working after proxmox-backup-server was upgraded from 4.1.6 to 4.1.7-2 (April 22) and then 4.1.8 (April 23). I did no changes to configuration — same bucket, same keys, same everything.
PVE backup jobs all failing with EACCES: Permission denied. PBS GUI Content tab shows Bad Request (400) EACCES: Permission denied. Thought it was S3 permissions but s3 check and list-buckets both work fine.
Spent a while digging and found the datastore was stuck in "S3 refresh maintenance mode" under Datastore → Options. This mode was introduced in the 4.1.7-2 release. Not sure if the upgrade triggered this automatically or a background job got stuck. Clearing it and restarting PBS fixed everything.
Posting details below for forum posterity in case others hit the same — the error message is completely misleading.
Summary from Claude chat:
PBS 4.1.8 S3 datastore inaccessible: "Bad Request (400) EACCES: Permission denied"
Environment: Proxmox Backup Server 4.1.8, S3 datastore backed by DreamHost DreamObjects, backups initiated from Proxmox VE.
Symptom: After upgrading proxmox-backup-server to 4.1.7-2 (April 22) and 4.1.8 (April 23), all PVE backup jobs to the S3-backed datastore failed with EACCES: Permission denied. The PBS GUI showed Bad Request (400) EACCES: Permission denied on the Content tab. S3 connectivity was fine — proxmox-backup-manager s3 check and s3 endpoint list-buckets both succeeded.
Likely trigger: The 4.1.7-2 changelog includes this S3-related change:
Finding: The datastore was in S3 refresh maintenance mode (visible under Datastore → Options). This mode was introduced in the 4.1.7-2 release. It is unclear whether the upgrade triggered this automatically or whether it was set by a failed background job.
Fix:
Note: The EACCES: Permission denied error message is misleading — it has nothing to do with S3 credentials or bucket permissions
PBS 4.1.8, S3 datastore on DreamHost DreamObjects. Backups stopped working after proxmox-backup-server was upgraded from 4.1.6 to 4.1.7-2 (April 22) and then 4.1.8 (April 23). I did no changes to configuration — same bucket, same keys, same everything.
PVE backup jobs all failing with EACCES: Permission denied. PBS GUI Content tab shows Bad Request (400) EACCES: Permission denied. Thought it was S3 permissions but s3 check and list-buckets both work fine.
Spent a while digging and found the datastore was stuck in "S3 refresh maintenance mode" under Datastore → Options. This mode was introduced in the 4.1.7-2 release. Not sure if the upgrade triggered this automatically or a background job got stuck. Clearing it and restarting PBS fixed everything.
Posting details below for forum posterity in case others hit the same — the error message is completely misleading.
Summary from Claude chat:
PBS 4.1.8 S3 datastore inaccessible: "Bad Request (400) EACCES: Permission denied"
Environment: Proxmox Backup Server 4.1.8, S3 datastore backed by DreamHost DreamObjects, backups initiated from Proxmox VE.
Symptom: After upgrading proxmox-backup-server to 4.1.7-2 (April 22) and 4.1.8 (April 23), all PVE backup jobs to the S3-backed datastore failed with EACCES: Permission denied. The PBS GUI showed Bad Request (400) EACCES: Permission denied on the Content tab. S3 connectivity was fine — proxmox-backup-manager s3 check and s3 endpoint list-buckets both succeeded.
Likely trigger: The 4.1.7-2 changelog includes this S3-related change:
Code:
s3: bump proxmox-s3-client to 1.4.0, fixing the Content-Type for object
upload and copy requests to `application/octet-stream` instead of the
non-standard `binary/octet`
Finding: The datastore was in S3 refresh maintenance mode (visible under Datastore → Options). This mode was introduced in the 4.1.7-2 release. It is unclear whether the upgrade triggered this automatically or whether it was set by a failed background job.
Fix:
- Datastore → Options → Edit → Maintenance Mode → set to None → Save
- systemctl restart proxmox-backup
Note: The EACCES: Permission denied error message is misleading — it has nothing to do with S3 credentials or bucket permissions
Last edited: