Fma965
14 september 2025 om 10:42
1
I have a bucket set but it seems to be trying to use default?
I use GarageHQ as a lightweight MinIO alternative.
I’m on 3.6.0.beta1-dev ed6beea336 )
[2025-09-14 10:40:34] Removing tmp ‘/var/www/discourse/tmp/backups/default/2025-09-14-104012’ directory…
[2025-09-14 10:40:35] /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/raise_response_errors.rb:17:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/sse_cpk.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/dualstack.rb:21:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/plugins/accelerate.rb:43:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/checksum_algorithm.rb:169:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/jsonvalue_converter.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/invocation_id.rb:16:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/idempotency_token.rb:19:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/param_converter.rb:26:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/request_callback.rb:89:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/response_paging.rb:12:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/plugins/response_target.rb:24:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `block in call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/telemetry/no_op.rb:29:in `in_span'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:53:in `span_wrapper'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/telemetry.rb:39:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/seahorse/client/request.rb:72:in `send_request'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/client.rb:3710:in `create_multipart_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:67:in `initiate_upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/multipart_file_uploader.rb:58:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:42:in `block in upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/file_uploader.rb:40:in `upload'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:477:in `block in upload_file'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-core-3.227.0/lib/aws-sdk-core/plugins/user_agent.rb:90:in `metric'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/aws-sdk-s3-1.182.0/lib/aws-sdk-s3/customizations/object.rb:476:in `upload_file'
/var/www/discourse/lib/backup_restore/s3_backup_store.rb:48:in `upload_file'
/var/www/discourse/lib/backup_restore/backuper.rb:351:in `upload_archive'
/var/www/discourse/lib/backup_restore/backuper.rb:41:in `run'
/var/www/discourse/script/spawn_backup_restore.rb:9:in `backup'
/var/www/discourse/script/spawn_backup_restore.rb:31:in `block in <main>'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `fork'
/var/www/discourse/script/spawn_backup_restore.rb:4:in `<main>'
The last backup was yesterday but now it’s not longer working, other services can backup to my local S3 without issue still
Anyone know how i can fix this?
pfaffman
14 september 2025 om 15:07
2
Yeah. AWS broke the S3 library for lots of other services.
Can't rebuild due to AWS SDK gem bump and new AWS Data Integrity Protections has some work-arounds.
I created this aws-revert-template.yml to revert to an older version. I don’t know if it works anymore; my file is dated 2025-08-06T05:00:00Z
But I did for a site that’s using Backblaze. I created a template I put in /root/aws-revert-template.yml with this:
# This template reverts aws-sdk-s3 to a version that works with backblaze
params:
home: /var/www/discourse
hooks:
after_bundle_exec:
- exec:
cd: $home
cmd:
- bundle config set frozen false
- "sed -i 's/gem \"aws-sdk-s3\", require: false/gem \"aws-sdk-s3\", \"1.177.0\", require: false/' Gemfile"
- bundle update aws-sdk-s3
…
Fma965
15 september 2025 om 15:42
3
Hmm, i’m not fully convinced the is the problem though
unless i’m mistaken i was on 3.6 for longer than 2 days, and yet i got a backup 2 days and 10 days ago.
pfaffman
15 september 2025 om 15:50
4
Not much more. I’m thinking that you’re mistaken.
Here’s the commit you’re on:UX: control event display through a site setting (#34795) · discourse/discourse@ed6beea · GitHub
But also:
Is your bucket named “default”?
Fma965
15 september 2025 om 18:41
5
Ja, ik ben nu bij de commit. Dat was ik in eerste instantie niet toen ik dit probleem plaatste. Ik heb geüpdatet om een bug uit te sluiten.
Fma965
15 september 2025 om 18:43
6
no, as stated in the OP this is why I don’t believe it’s the same issue you are referring to, my bucket is specified , ive tried both in the UI settings of the backup section and via env vars in the yaml, it still tries to use default regardless
to clarify nothing has changed on the discourse or garage end since it stopped working except for an update to 3.5 and then to 3.6
1 like
Fma965
15 september 2025 om 23:35
7
Misschien kan iemand met daadwerkelijke S3 controleren of deze correct een bucket selecteert? Hetzelfde geldt voor andere externe partijen zoals Backblaze, R2, etc.?
Fma965
18 september 2025 om 17:08
8
Dus ik heb een bucket aangemaakt met de naam “Default” en deze werkt zoals bedoeld, dus nee, hij pikt de bucketnaam die ik hem vertel niet correct op.
pfaffman
18 september 2025 om 17:25
9
Except thousands of people and CDCK hosting would also likely be affected and they are not. It’s much more likely that you deleted or added a character to a line in your app.yml.
You can do stuff like this:
grep -i S3 /var/discourse/containers/*
docker exec -it app bash -c 'grep s3 /var/www/discourse/config/discourse.conf
And if you configured s3 in settings instead of with ENV variables, then you can have a look at Configure an S3 compatible object storage provider for uploads to see what those look like.
Fma965
18 september 2025 om 20:43
10
nothing is wrong with my setup nothing was changed except the discourse update. Ive tried configuration in the yaml and configuration in the UI, the UI settings literally show it as “cyanlabs-community” and yet the backup still tries to save to “default”
despite having s3 configured in the UI the discourse.conf file does not contain any s3 references as per your second command
sam
22 september 2025 om 00:23
11
This though means the bucket is not there, can you try creating a brand new bucket and creds and see if uploading there works?
1 like
Fma965
22 september 2025 om 15:06
12
Thanks but I feel like i am going around in circles here.
the bucket default did not exist at the start of this conversation, i have since created it and it uses that bucket despite having the bucket cyanlabs-community set in the settings.
Fma965:
So i created a bucket named “default” and it works as intended, so yes, it’s not correctly picking the bucket name i tell it.
So this seems like a bug in Discourse.
both cyanlabs-community and default exist in the s3 instance, but Discourse will not use cyanlabs-community no matter what i try
new bucket cyanlabsdiscourse
result of backup
[2025-09-22 15:14:59] Finalizing backup...
[2025-09-22 15:14:59] Finalizing database dump file: cyanlabs-official-community-2025-09-22-151437-v20250916082012.sql.gz
[2025-09-22 15:14:59] Removing tmp '/var/www/discourse/tmp/backups/default/2025-09-22-151437' directory...
[2025-09-22 15:14:59] Uploading archive...
[2025-09-22 15:15:37] Executing the after_create_hook for the backup...
[2025-09-22 15:15:37] Deleting old backups...
[2025-09-22 15:15:37] Cleaning stuff up...
[2025-09-22 15:15:37] Removing archive from local storage...
[2025-09-22 15:15:37] Removing '.tar' leftovers...
[2025-09-22 15:15:37] Marking backup as finished...
[2025-09-22 15:15:37] Refreshing disk stats...
[2025-09-22 15:15:37] Notifying 'CyanLabs' of the end of the backup...
[2025-09-22 15:15:40] Finished!
Whats interesting is it still attempts to make the connection at bucketname.s3.domain.tld, e.g cyanlabsdiscourse.s3.domain.tld as without adding a DNS record it wouldn’t work at that sub sub domain. so the setting is being honoured for the url but it seems to be ignored by the bucket selection
Fma965
26 september 2025 om 10:10
13
Ik heb het gevoel dat ik alles heb geprobeerd, voor nu gebruik ik denk ik maar de standaard bucket
AWS kan mysterieus zijn! Jammer dat je je voorkeursbucketnaam niet werkend kreeg. Moeilijk te helpen zonder het te kunnen repliceren, dus ik denk dat je moet leven met het gebruik van de standaard als bucketnaam.
