Attachments saved in Amazon S3 broken in

(Steve Baer) #1

I just updated our discourse from to at and now all attachments are not working. We are getting the following error message

(hmm… at least attachments are currently working at meta.discourse :smile:

Should I update to HEAD on git or is there a configuration setting I need to change. Attachments have been working for months for us and I haven’t really changed anything with respect to our discourse configuration; only updating when a new release is available.

(Régis Hanol) #2

Do you have any errors in the logs?

(Steve Baer) #3

Where are the logs stored? I can take a look.

(Régis Hanol) #4

Standard rails location. Something like /var/www/discourse/log/.

(Steve Baer) #5

Heading off to the office right now. I’ll check when I get in and let you know. It should also be mentioned that I upgraded from to (I was on vacation the last couple of weeks so I fell a little behind.)

(Brian Gillespie) #6

Error is:
hostname “” does not match the server certificate (OpenSSL::SSL::SSLError)

Looks like Discourse recently either:
a) switched to HTTPS for uploading to S3
b) started paying attention to cert errors.

If you visit you can see that the AWS wildcard SSL cert isn’t valid for the sub-sub-sub-subdomain we’ve provided.

We have been hoping all along that using a vanity domain like would be supported in Discourse so that the links to S3 images could be… - this hasn’t happened yet, but we’re still holding out hope.

The reason is that for many big companies http://* is blocked as a generalized file sharing or source of malware, while our own domains seem to work.

Thanks for looking into this.

(Régis Hanol) #7

I recently updated the fog gem we use to communicate with S3. That might be the issue…

This is still on my TODO list. It will help some of your users, but will not solve the problem…

(Brian Gillespie) #8

Thanks, can you please elaborate? Why doesn’t it solve the problem? Or is the problem you are trying to solve different from the one I stated?

(Régis Hanol) #9

Well, your problem right now is that you can’t upload files to S3. Vanity domain is only a client-side feature.

(Brian Gillespie) #10

Sure. But vanity domains solve the problem that some of our users can’t view attachments, that’s all.

I wanted to mention vanity domains here as it’s directly related to the choice we made to name our bucket “” instead of “mcneeldiscourseusercontent” or some such. While it might be possible to work around the current problem by changing our bucket to one without dots, it isn’t in the spirit of hoping for vanity domains to work some day.

Sorry, that probably just muddied the waters.

(Steve Baer) #11

Does anyone have advice on an action to take? We used to be able to upload attachments and now with the discourse upgrade we can’t. I would like to try and remedy this as soon as possible. Thanks.

(Régis Hanol) #12

I’ll have a look tonight or tomorrow. In the meantime, try downgrading the fog gem to 1.14.0.

For the record: it’s working just fine on other forums that are using S3.

(Steve Baer) #13

Sorry, by no means a ruby/rails pro. What is the best way to downgrade fog to 1.18.0 for testing?

(Régis Hanol) #14

I don’t know an easy way to test it… Also, downgrading the gem requires a restart of the rails app.

If you want to downgrade, you’ll need to edit the Gemfile file and replace:

gem 'fog', '1.18.0', require: false


gem 'fog', '1.14.0', require: false

and then run: bundle install

(Steve Baer) #15

Great, thanks I’ll try that. We just bring up clones of our server to test things like this.

(Steve Baer) #16

Rolling back fog to 1.14.0 worked. Thanks!

(Steve Baer) #17

I just upgraded to and noticed that fog is still at 1.18.0 which breaks our attachments. Is this going to change or should I just tweak my upgrade process to always switch fog to 1.14.0? Just checking

(Sam Saffron) #18

No this will not always be a problem, @zogstrip will sort this asap, ideally we can find the issue in fog and fix it.

(Régis Hanol) #19

This is now fixed :wink:

The issue was that dots in the bucket name were not compatible with ssl (which is the default). So I enforced the scheme depending on the use_ssl site setting and made sure we use the path_style format for the url when ssl is enabled.

(Steve Baer) #20

Thanks! I’ll try this out the next time we upgrade.