I’ve got this message pop up when I try and upgrade via the UI: [image] After several git pulls and rebuilds I’m still getting the same message. Any tips? I wonder if I need to do this: [image]Manually update Discourse and Docker image to latest Due to the way docker packaging has changed you may also have to update your docker from lxc-docker or docker-engine packages. One way to do that is via the Docker script here (it will warn about an existing install but should upgrade ok): wget -qO- https://get.docker.com/ | sh This will now use the docker-ce main versions. This is for an old, well established forum. Cc @pacharanero

[image] nathank: How likely is that on so many instances? How many are we talking? There are thousands of Discourse out there, and I don’t see dozens of reports of this problem. At least not yet :sweat_smile: If someone has a server that is currently reproducing this bug and can keep it that way for another day, please reply here so we can investigate further.

[image] nathank: This is for an old, well established forum Was this a standard install? Could it be something like running the upgrade on the wrong server? Did the rebuild fail and you restarted the old container? I don’t have any better guesses. You should keep your os to date as recommended in the topic you linked, but that’s unrelated to the problem you describe.

It has puzzled me on occasion when the GUI update doesn’t seem to be reset and it directs us to SSH in, even when this has just literally been done. It was a standard install, but the original install was way back in 2014, in the very early days when Discourse was not long out of public beta. user@server:/var/discourse$ docker -v Docker version 19.03.13, build 4484c46d9d There is a more recent version of Docker, but it’s common for the version in Ubuntu to lag a little behind the latest. OS is fully and regularly updated.

[image] pacharanero: It has puzzled me on occasion when the GUI update doesn’t seem to be reset and it directs us to SSH in, even when this has just literally been done. Hmm. There is a lag after update before Discourse checks to see if the container has been rebuilt, though I have never known it to affect docker-manager. You could try this: docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats But it’s been long enough now, that I don’t think this is your problem. It can’t hurt, though. I can’t remember the minimum version of docker supported, but I don’t think that’s the issue either, at least if you’re not on Ubuntu 16.04.

Is there any way it could be about the branch we’re running? In containers/app.yml we are explicitly selecting tests-passed But of course that’s what’s running INSIDE the container. Would it matter what the default branch is outside the container? user@server:/var/discourse# git status On branch master Your branch is up to date with 'origin/master'.

Back in the day master was the default in GitHub. Now it’s main.

RIght. I guess you could try cd /var/discourse git checkout main But I didn’t think you needed to do that explicitly. What about cd /var/discourse ./launcher enter app cd /var/www/discourse git status

[image] pacharanero: user@server:/var/discourse# git status On branch master Your branch is up to date with 'origin/master'. This relates to discourse_docker, of course: :/var/discourse# git remote -v origin https://github.com/discourse/discourse_docker.git (fetch) origin https://github.com/discourse/discourse_docker.git (push) The branch was switched over in August 2021 and is 49 commits behind main at time of writing: GitHub - discourse/discourse_docker at master · GitHub So you definitely want to switch to main branch? However, I’ve agree with @pfaffman have never explicitly done that, so there must’ve been some script that did it. Perhaps it will occur with the next rebuild?

[image] pfaffman: cd /var/discourse ./launcher enter app cd /var/www/discourse git status returns user@inside-container-app:/var/www/discourse# git status Refresh index: 100% (30949/30949), done. On branch tests-passed Your branch is up to date with 'origin/tests-passed'.

That looks like you’re up to date. And you’re still getting the Upgrades Disabled page?

Yep. I had a look on another Discourse I run which dates back a bit, and is similarly on master and that also has the same Upgrades Disabled page. That said, another Discourse I set up in mid-2022 is also on master and presents the update screen as normal! If we can get any confirmation that changing the branch of discourse_docker to track main will fix it then I’m prepared to give it a go. Perhaps on a site that only I use. [image] merefield: The branch was switched over in August 2021 That would roughly coincide with when I started to get weird behaviour on some Discourses around update time. (Because of this I ended up just updating them all via SSH every time, using Ansible).

Upgrades via UI disabled - and not being re-enabled after SSH upgrade

Product Support Self-hosting

Falco (Falco) January 26, 2022, 11:45pm 15

Launcher changes the branch to main from master automatically. Sounds like something was blocking the automatic switch, like pending stash changes.

Topic		Replies	Views
Upgrades via the web UI are disabled until you run the latest image Product Support	5	1977	October 31, 2017
Updating discourse launcher gives new issue Product Support unsupported-install , docker-manager	7	265	February 26, 2026
Cannot upgrade due to old version of docker Self-hosting	4	1734	June 19, 2018
Discourse upgrade via Web UI Fails & SSH Upgrade Brings Down Discourse Instance Self-hosting	16	2491	November 26, 2021
Upgrade link no longer works Self-hosting	7	1185	November 22, 2021

Upgrades via UI disabled - and not being re-enabled after SSH upgrade

Related topics