In a discussion about S3 bucket policy and permission issues affecting Discourse installations, Shane_Liebling reports that while backups successfully upload to S3, image uploads and attachments fail with “Access Denied” errors—even though the IAM user has full S3 access. Despite rebuilding, creating new buckets, and testing multiple policies—including one granting s3:* on all resources—uploads remain broken. merefield suggests loosening AWS permissions, citing a similar past issue. gerhard spots a typo in the bucket ARN (“gantlet” vs “gauntlet”)—but correcting it doesn’t resolve the issue. Eventually, gerhard advises deleting the manually created uploads bucket so Discourse can recreate it automatically—this fixes the problem for Shane_Liebling. gerhard notes this is a recurring oddity with manually created buckets. zogstrip suggests AWS may have changed default S3 permissions, showing screenshots where manually created buckets have different ACL settings than those auto-created by Discourse. jidetheblogger reports similar upload failures despite matching Discourse’s permission settings; gerhard suspects CORS or policy misconfiguration, not bucket permissions, and recommends reviewing the updated S3 setup guide. dmagill confirms that carefully following the guide’s IAM policy section resolved their backup failures after an upgrade.
I have two S3 buckets, one for backups one for uploads. I have one user/policy for both with full s3 access. I have both uploads and backups set to go to s3. Strangely, I can make a backup and it will end up on s3, but any kind of image upload or attachment attempts give Access Denied errors.
I have tried rebuilding. I have created new buckets and policies. None of that has helped.
This also seems to prevent adding Gravatar images. Sidekiq has a bunch of pending tasks saying:
Is your uploads bucket empty? Delete it and let Discourse create the bucket. Also, make sure you follow the instructions in Set up file and image uploads to S3.
That’s so weird. I’ve seen that outcome a couple of times in the last few weeks. I’m not sure what’s going on with manually created buckets yet.
I had trouble getting uploads to work with digitalocean spaces yesterday, also with an error about the bucket already existing. I ran out of time before I could fully diagnose its. 'tis the season.
Are you sure? You should see an “Access Denied” error if the upload fails. I thinks it’s a problem with a policy or CORS configuration. According to your screenshot the bucket permissions seem correct (both checkboxes under the “Manage public access control lists (ACLs)” are unchecked) and you “failed to load resource” looks like the browser simply isn’t allowed to load the image.
I’ve updated the instructions in Set up file and image uploads to S3. Maybe it helps you find the difference in your S3 bucket configuration.
