No they aren’t and they got structure internally. Just wanted to ensure that it’s okay to see only 2 folders and nothing else there.
Now that’s VERY useful information. Maybe not include Option 2 at all since it could break many things. Infact in option 1 I’d probably highlight that one shouldn’t change the bucket for the uploads since it would require a rebake etc, only change the bucket for backups.
This is exactly what was looking for, don’t touch the upload, just move Backups to a new bucket or a sub folder.
Hi,
I ran into a similar issue with a different cause. Uploads to the backup bucket worked, but the uploads bucket didn’t work.
Turns out it was because the uploads bucket was set to block all public access. (Which I think is the default now.) When I tested uploading locally, it worked fine, but Discourse was uploading with “public-read” access, and S3 rejected that. (I would have guessed that S3 would save the “public-read” status on the file, but then reject public access attempts.) I ended up having to hack in extra logging to find out what options were being used for the upload.
Perhaps Discourse could use the GetPublicAccessBlock API to check if the bucket is configured properly when setting the “s3 upload bucket” setting?
Another possibility is for us to start recommending people put a CloudFront CDN in front of their uploads bucket in the setup guide, in which case the public-read blockage should remain in place.
I’m unsure what the cost vs complexity tradeoff there should look like.