The path fo the user_avatars_controller.rb file is actually /var/discourse/user_avatars_controller.rb. Could that be causing the problem?
I think your install is broken in some way.
Thanks for the feedback but that does not help much. We’re not noticing any other issues with the installation and followed your installation guide to the letter. What steps do you recommend we take to resolve this issue? If your answer is a complete removal and re installation, do you have a tutorial on how to achieve that while preserving the data in our DB? Also, we have not performed any modifications to the core code, so if we followed your own installation guide to begin with, what’s to say this issue won’t repeat itself?
How would the path as outlined above become “corrupt”?
Can you confirm whether or not someone is at least looking into this issue? Thanks.
So this isn’t a default Docker install ?
We installed Discourse per the following:
When troubleshooting the behavior we’re experiencing relative to the avatar(s), I decided to search for the path Discourse was referencing to the avatar (which was causing the 500 error described earlier in this thread). That’s when I noticed the that the potential path issue.
That file in that location is not the expected result of a standard installation procedure. Given the large number of Discourse installations that complete successfully using the instructions provided, hopefully you can understand why we have to assume, prima facie, that the problem is at your end, until there’s some tangible information to the contrary.
I understand what you are saying, but like we stated above, we installed Discourse per Beginner Docker Installation Guide and never modified any of the core code (nor would we have any reason to do so).
As requested of @codinghorror above, what steps do you recommend we take to resolve this issue? If your answer is a complete removal and re installation, do you have a tutorial on how to achieve that while preserving the data in our DB? Also, as we have not performed any modifications to the core code, so if we followed your own installation guide to begin with, what’s to say this issue won’t repeat itself?
Just do a backup from the admin section. That file has the database and all uploads. You can restore it to your new install.
A simple way to go would be to move /var/discourse to some other name, and start again with cloning discourse.
10-4 Jay. We’ll give it a shot and I’ll report back for the benefit of the community. Thanks to all for their support up to this point.
Upon reinstall then, the correct directory is /var/www/discourse in lieu of /var/discourse? Maybe I did that incorrectly upon initial installation when setting up the directory structure?
No. You want to clone discourse_docker into /var/discourse. (Inside the container, there is a /var/www/discourse, but that’s not important now.)
Sorry for asking what I’m sure is a very fundamental question, but if the goal here is for use to completely remove our current installation and start over, I’m not sure how the “cloning” process works. Aside from backing up before beginning, I was headed down this path:
sudo apt-get remove docker* sudo apt-get autoremove sudo apt-get autoclean sudo rm -rf /var/www/discourse -R
If this is incorrect and/or if there is a different recommended best practice, i.e., clone, are there instructions on how to perform that step by step? I want to ensure that if we did somehow improperly install Discourse on the first go-around (albeit we did follow the Beginner Docker Installation Guide), we don’t repeat that error again.
/var/www/discourse only exists inside the docker container. If you can see /var/www/discourse then docker is running and you’re inside the discourse container (via
./launcher enter app)
./launcher stop app mv /var/discourse /var/baddiscourse
Then follow the 30 min install (contrary to the warning, nothing breaks if you curl docker in when it’s already there - at least not on Ubuntu 16.04). If you’re not on Ubuntu 16.04 with the latest updates and patches, then I would highly recommend changing to that.
Once you get the new discourse up and running you can check if you’ve any problems with avatars and updates etc, and if everything is tickety boo, you can copy the backup from
and run the restore.
My best guess is that when you installed Discourse, you enabled ssh access to the container and now you’re in the container where you can’t upgrade Discourse. If you’re that confused, then you would probably be well served to start with a whole new OS installation. If you were to pay me to fix this for you, I would likely insist that you start with a clean OS.
In the install-cloud document, that you claim to have seen before, it includes this:
sudo -s mkdir /var/discourse git clone https://github.com/discourse/discourse_docker.git /var/discourse cd /var/discourse
when I refer to “cloning” this is what I’m talking about, downloading the current version of discourse_docker from github.
@pfaffman, I don’t think we’ll need to perform a complete OS re-installation. I never said we could NOT upgrade Discourse, nor did we enable SSH access to the container. As stated originally, the 500 error on the avatar’s that we’re getting ONLY when uploading a custom avatar is as follows:
NoMethodError (undefined method `path' for nil:NilClass) /var/www/discourse/app/controllers/user_avatars_controller.rb:144:in `proxy_avatar'
As of this date, nobody here as been able to advise on what that error means other than, “… you must have screwed something up …” which, since we installed per INSTALL.md, and have in no way touched the core code base, makes absolutely no sense to us.
Be that as it may, we’re going to reinstall AGAIN per INSTALL.md and hope this issue goes away (albeit it’s a shot in the dark since the original 500 error is still left unknown/unanswered).
I understand your frustration.
Here’s the thing: If you followed the install directions that you say you followed, there would not be a /var/www/discourse directory. We cannot guess what you might have done to make there be a /var/www/discourse directory on your server. One guess was that you were inadvertently logging in to the container rather that the server. You think my guess was wrong, which it may well be.
Perhaps someone somehow, installed NGINX on your server and that installation is what you are seeing instead of the docker install that we think you’re seeing.
If your server has a /var/www/discourse, it is likely that merely re removing /var/discourse (if you have one) and re-installing per the docs won’t solve the problem.
Does your server have a /etc/nginx or /etc/apache2 directory?
It’s frustrating. But as Jay notes, the fact that you seem to have a /var/www/discourse/ directory outside of the docker container indicates pretty clearly that something went wrong, possibly during your install, possibly later.
I’ve only done about 20 discourse installs, and I’ve tried to break them in various new and novel ways. It’s possible to copy stuff from inside the container out to the OS level, but a standard discourse install doesn’t break itself like that without human intervention.
We don’t have a /var/www/discourse directory outside of the docker container. I simply stated above that the path, when searched via CLI, to the /user_avatars_controller.rb file was /var/discourse/user_avatars_controller.rb. I was trying to figure out what the “undefined method `path’” error message was pointing to.
It shouldn’t take too long to perform the reinstall, so I’ll report back then and if the problem is still there, I’d be interested to know what is going on.
@pfaffman, we have a /etc/nginx directory and are not running Apache.