Uploaded file not available for download after restoring multisite installation

(Felix Freiberger) #1

Recently, one of the Discourse instances I’m maintaining migrated from being a standalone installation to being a multisite tenant, through backup-and-restore on a new host. In this process, the hostname also changed to a subdomain of the original one.

During this process, something went wrong with the attachments. While old images load fine, non-image attachments seem to be broken.

One of the broken files is linked in the post as https://ws1617.■■■■■.■■■■■/uploads/prog1-ws1617/original/1X/3e5103b67bd6911bda0666be6d1aecb615f6ce38.exe. (This is the correct new hostname.)

Visiting this URL, while being logged in as an admin, yields a 404 error.

However, the file does exist in the file system, at the expected path /var/discourse/shared/standalone# ls -al uploads/prog1-ws1617/original/1X/3e5103b67bd6911bda0666be6d1aecb615f6ce38.exe.

The file also seems to have a healthy record in the uploads table:

The Rails log file states that this is a problem of no route matching:

[prog1-ws1617] Started GET "/uploads/prog1-ws1617/original/1X/3e5103b67bd6911bda0666be6d1aecb615f6ce38.exe" for ■■■.■■■.■■.■■■ at 2017-07-29 12:24:24 +0000
[prog1-ws1617] ActionController::RoutingError (No route matches [GET] "/uploads/prog1-ws1617/original/1X/3e5103b67bd6911bda0666be6d1aecb615f6ce38.exe")
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/actionpack-4.2.8/lib/action_dispatch/middleware/debug_exceptions.rb:21:in `call'
[prog1-ws1617] Processing by ExceptionsController#not_found as HTML
[prog1-ws1617]   Rendered exceptions/not_found.html.erb within layouts/no_ember (34.0ms)
[prog1-ws1617]   Rendered layouts/_head.html.erb (0.4ms)
[prog1-ws1617]   Rendered common/_special_font_face.html.erb (0.3ms)
[prog1-ws1617]   Rendered common/_discourse_stylesheet.html.erb (0.3ms)
[prog1-ws1617]   Rendered application/_header.html.erb (0.1ms)
[prog1-ws1617]   Rendered html template (0.0ms)
[prog1-ws1617] Completed 404 Not Found in 64ms (Views: 0.5ms | ActiveRecord: 24.5ms)

What could be going on here?

(Michael - DiscourseHosting.com) #2

Did you change the name of the database?

(Felix Freiberger) #3

I’m not 100% sure what you mean by that; but before, it was a standard standalone install, and now, my multisite configuration file defines database: prog1-ws1617. Does this answer your question (probably with Yes)?

(Felix Freiberger) #4

Sorry to bump this, but does anyone have an idea how to debug this?

(Sam Saffron) #5

I would start by searching for the file on disk.

(Felix Freiberger) #6

The file is there, and I didn’t notice anything special about it:

(Sam Saffron) #7

What is this, the multisite name? Is the new restored multisite name any different?

(Felix Freiberger) #8

Yes, this is the multisite name. Before the backup and restore process, the site was a normal, non-multisite installation.

(Sam Saffron) #9

When you upload a new file on said site where does it go?

Also … my guess is that you need to remap the “uploads” table changing “default” to “prog-ws1617”, these kind of moves are not trivial.

(Felix Freiberger) #10

A new test upload went to /uploads/prog1-ws1617/original/1X/a94a8fe5ccb19ba61c4c0873d391e987982fbbd3.sml.

Hm, but if you look at my screenshot in the original post, it looks like this has been taken care of by the restore already?

(Sam Saffron) #11

I doubt it fixed the record in the uploads table, search for it there and see what path it thinks it has.

(Felix Freiberger) #12

Hm, isn’t this what you are looking for? There’s no default in there.

(Sam Saffron) #13

Yeah, can you compare that row to a different row you create just now uploading an .exe keep in mind its going to have to be an attachment to exhibit the issue.

(Felix Freiberger) #14

Okay, I just did that. The rows looks the same, except for extension being NULL on the old upload.
And surprise: The newly uploaded .exe files returns a 404, too! :thinking:

(Sam Saffron) #15

well then … sorting that out is step one, do any other authorized extensions you have going work?

(Felix Freiberger) #16

Very weird – it looks like all non-image uploads (i.e. attachments) are broken.

Do you have any idea what could cause these RoutingErrors?

(Sam Saffron) #17

Not sure, do you have intermediate proxies at play?

(Felix Freiberger) #18

Yes, there is an SSL-terminating nginx in front, but nothing fancy.

(Sam Saffron) #19

Maybe this layer of indirection is causing the problem … I would try without it.

(Felix Freiberger) #20

Hm, this is a bit difficult for me because there’s important other stuff running behind nginx on that machine. However, the nginx configuration for this domain is basically identical to the one on the old, dedicated host, so I don’t really how it could be causing this…