First I tried to run Discourse with semi-default settings and it worked quite fine, I was able to upload files as well as do other stuff.
Then I realized the path in app.yml was /var/discourse and I updated it to /var/www/discourse, stopped and destroyed the container, removed the previous folder completely. And I have it up and running again… but I noticed now I cannot upload files any more.
What kind of permissions does uploads folder need? I can do some changes manually, but I’d like to know what exactly and whether it’s fine in general (shouldn’t the launcher take care of setting right permissions, especially when launched from scratch?)
The /var/www/discourse path is the path to discourse inside the container. /var/discourse is the normal path for Discourse_docker outside the container.
Since you just started, I would likely recommend that you just start over and don’t rename anything this time.
My guess is that you didn’t update the path in your app.yml and so it’s trying to access something that doesn’t exist.
I have many other projects on this server and they’re all are nicely located in my /var/www folder, so I prefer to keep it like this And I don’t care how it is inside the container.
But I did update it? In mounts, or where else should it go?
Okay, nothing worked, so I ended up changing permissions for uploads folder to 755 and it’s fine now. After rebuild it seems the uploads themselves were okay (from the engine side), however nginx was not able to read those.
I don’t totally understand why you are doing all this. It is your choise to put container in the path that will be wordwide visible if you do a small mistake, but that is your choise. But everything else… why?
To have a reverse proxy front of Discourse is really trivial and otherwise your setup would be a standard install without all that hazzle. Sure, if you want to play and that is your hobby, but quite soon someone will pop-up and say you can get support only for standard install and the biggest issue is anyone actually doesn’t know what you have done. Or why.
You are fixing an issue you got when you started to do something else what a standard one needs. Even with reverse proxy.
That’s why you are quite far away standard Because there is two options
you have a bug in your hands that no one else has
you did something funny
Perhaps it is a bug. And you have confirmed it making a standard install using safe (in so many ways) path and at same time connecting your reverse proxy proper way. Because if it is still broken I can bet the issue is in virtual host and/or ports. But if it works… then we are back on option ”funny” — where no one knows what you did.
Do you see the problem here?
Either way — using a reverse proxy leads to no support… that’s policy here. But yet another users can and quite often will help,
And I don’t care how it is inside the container.
Situation is same with docker container.
