S3 image upload access denied while backups upload working fine

Installation
1

I’m getting an issue with S3 setup, wherein backups are uploading just fine to the s3 bucket but image uploads give this error

Encountered an error while migrating /uploads/default/original/1X/ea17a258eff7a95045bda914c10bac5a2de02c62.png: Aws::S3::Errors::AccessDenied: Access Denied while running rake task uploads:migrate_to_s3

Please help.

2

U sure Your S3 credentials have necessary permissions to interact with the bucket?

3 Likes
3

It’s inadvisable to use the same bucket for backups and images, there are known issues with the admin dashboard when you do this. I would strongly recommend setting up a separate bucket for your images.

4 Likes
4

I thought we added protection for this @gerhard? It comes up wayyy too much.

5

Hi,

Thanks for the reply.

I have created IAM policy like this, and I could see right read right permissions on s3 bucket permissions tab.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::bucket",
                "arn:aws:s3:::bucket/*"
            ]
        }
    ]
}

Let me know if any thing I’m missing. Strange thing is that how come backups are able to upload to the same bucket while images aren’t

Thank you

6

Hi Stephen,

Thanks for the reply. will try this

7

You need separate bucket for assets and backup.

8

Hi @itsbhanusharma

created separate bucket but still the same issue, but when the same bucket is used with backups they are uploading …

Any pointers?

9

Do You see any errors in the Logs?

10

I’m running rake task for existing uploads

I get this error /uploads/default/original/1X/eb7e7463785d0041c85688b1329c5568c75f7a12.png: Aws::S3::Errors::AccessDenied: Access Denied

11

The best that I can tell from this error is that it is a permissions issue!

I’d start diagnosing from AWS then follow it up with a thorough investigation in admin dashboard for ommission or mispelled bucket names. If none of that works, I’d also recommend upgrading to latest and doing a rebuild just in case it’s just some old code not playing nice.

12

Thanks for quick reply.

yes. it is already clear from the log that it is at AWS, bucket is given with caution following std., so couldn’t be that and discourse is latest. something is not catching my eyes at AWS :frowning:

will check again

13

In this case it seems to be a different problem.

Anyway, I’m working on preventing the dashboard from timing out by converting the storage stats into a proper report and I’ll add protection against bucket reusage too.

5 Likes
14

I see in the latest release notes that 2.2.0 BETA 7 has a new feature for backups which requires separate buckets for discourse.

Is there a topic or post that elaborates on this and what needs to be done for existing setups to ensure nothing breaks. Preferably a step by step guide on how to make changes to S3, what permissions, what to check, what to change on discourse etc.

This was more like a setup and forget it step so I don’t even recall what I had done to get it working, it’s just been working and I’m concerned that upgrading to BETA 7 will now break something.

15

I believe @gerhard can elaborate.

16

I’m currently updating our various S3 related Howto topics so that they reflect the latest changes in Discourse and S3. I’ll notify you when that’s done.

Essentially you need to either use two different buckets or a prefix for the backup bucket. For example, the following combinations will work:

  1. Different buckets
    • s3_upload_bucket: my-upload-bucket
    • s3_backup_bucket: my-backup-bucket
  2. Different prefixes
    • s3_upload_bucket: my-bucket/uploads
    • s3_backup_bucket: my-bucket/backups
  3. Prefix for backups
    • s3_upload_bucket: my-bucket
    • s3_backup_bucket: my-bucket/backups
5 Likes
17

Appreciate it, it would nice if you can highlight any special instructions/steps for existing installation to migrate to this new structure. The obvious concern is to avoid breaking something / lose data while going through this process. Can you recommend if one should make the changes first and then upgrade or vice-versa?

18

I assume both s3_upload_bucket and s3_backup_bucket currently have the same value (name-of-your-bucket) without any prefix.

The easiest solution in your case would be option 3 from above. Update the s3_backup_bucket and append a folder name to the bucket (e.g. name-of-your-bucket/backups). You can use the S3 Console to move existing backups into the new folder.

I guess changing the bucket settings before the upgrade is a good idea, but I afterwards should be fine too.

5 Likes
19

Option 3 - That was easy to move the backups to a folder within the bucket. Here are the steps I followed:

  • I created a folder in the bucket
  • moved the backup files into it and then
  • changed the s3 backup bucket setting on discourse
  • did a manual backup to test that it’s working

Thanks!

A related question about the “uploads” since this is “live” v/s the backup which is accessed once a day.

  1. I see just 2 folders Original and Optimized, nothing else - I’m guessing that how it supposed to be
  2. Using option 2, moving these 2 folders to a new folder called upload in the bucket, what’s the risk of breaking something here by doing it on the fly? What’s the right way to do it. E.g. move the folders into upload and then modify Discourse s3 upload bucket setting or vice versa or some other way?

EDIT: Or put the site into read-only mode, then move the folders in the buckets and finally update the settings on discourse upload bucket name?

20

But those folders aren’t empty, are they?

Switching to option 2 is definitely the hardest. You’d need to rebake all posts after moving the files and updating the site setting. Of course it’s up to you, but I wouldn’t change a thing. Option 3 is supported and works.

1 Like