Fails during the backup step.
If I go back to settings and start the update again, then a green checkmark magically appears next to backup. But then it gets errors at basically every step after, but somehow finishes anyway. Sometimes it gets stuck in maintenance mode.
Integrity checks I run in between updates are fine.
This has been an issue for many years… It seems there is no interest in doing anything about it. It might have something to do with remotely mounted data directory and / or apache/proxy/php.
The answer from staff and others is 99 percent of the time: Use manual CLI update.
The truth is, that the updater actually runs fine en the background, it is the frontend that is assuming it is not… The way to get around it is: When ever you get the “parsing error”, just let it sit, and imagine it is doing its thing in the background, then refresh the page (dont click on retry) when the page refreshes it will give you a continue update. You will have to do this a couple of times if it has not finished(it will tell you that it isn’t done), and continue to do this for every step.
The parsing response error, which only occurs in very specific environments, was recently fixed but that’s an older version of NC you won’t see that until you get more up-to-date.
The rest of the situation is going to be easier to debug if you look at the Updater specific log file, which by default goes into your configured datadirectory and is called updater.log. It has details of what is going on behind the scenes.
It’s possible/likely you’re just hitting a timeout. The web-mode of Updater is impacted by things like web server request timeouts. In general, the most reliable method of running Updater is from the command-line (see the Admin Manual for instructions on doing that) since it’ll be immune to web server/HTTP path matters.
Nothing really pops out at me in the log.
Thanks guys. I guess I’ll just increase php execution time and push onwards.
It’s been stuck on this message since last night
“Step 6 is currently in process. Please reload this page later.”
How do I restart the process.
log:
2023-12-05T04:39:33-0800 R4RBfmJIZv [info] Step 5 is in state "end".
2023-12-05T04:39:33-0800 R4RBfmJIZv [info] POST request for step "6"
2023-12-05T04:39:33-0800 R4RBfmJIZv [info] startStep("6")
2023-12-05T04:39:33-0800 R4RBfmJIZv [info] extractDownload()
2023-12-05T04:39:33-0800 R4RBfmJIZv [info] storage location: /home/mountain/public_html/cloud/data/updater-oc20leygohzu/downloads/
2023-12-05T20:33:00-0800 Bhchuie30N [info] request to updater
2023-12-05T20:33:00-0800 Bhchuie30N [info] currentStep()
2023-12-05T20:33:00-0800 Bhchuie30N [info] Step 6 is in state "start".
2023-12-05T20:33:17-0800 3HqPg4MCTe [info] request to updater
2023-12-05T20:33:17-0800 3HqPg4MCTe [info] currentStep()
2023-12-05T20:33:17-0800 3HqPg4MCTe [info] Step 6 is in state "start".
2023-12-05T20:34:44-0800 ZKu7JdQidP [info] request to updater
2023-12-05T20:34:44-0800 ZKu7JdQidP [info] currentStep()
2023-12-05T20:34:44-0800 ZKu7JdQidP [info] Step 6 is in state "start".
EDIT: found the solution in the forum. Delete .step files in the updater directory.
This is a stupid “answer” . The CLI uprade command isn’t even available to use until you’re at the “blue background” stage of the process, which is mildly annoying, but only fails once.
It’s the “white background” phase which has to be constantly baby sat and reloaded multiple times. If you attempt to run a CLI upgrade at this stage, it will simply tell you:
Nextcloud is already latest version
“fixed” when? I just upgraded all the way from version 20 to 27, and at no point did it get better.
there’s nothing in the log
You’re confusing different things here.
If you are advised to carry out the update with CLI, then the file
updater/updater.phar
to be called from the commandline with a command like
NC_DIR=/path/to/your/nextcloud
sudo -u www-data php $NC_DIR/updater/updater.phar
is meant.
(The web updater does it with the file updater/index.php)
You’re talking about the occ command
occ upgrade
which must be executed AFTER the update process (either web or cli).
All of what I just explained is thoroughly described in the manual:
I understand that it can often get confusing, but to not make yourself unnecessarily unpopular, I can warmly recommend that you read the manual on the topic in question carefully next time before labeling answers as “stupid”.
Much luck,
ernolf
well that’s egg on my face. Thank you for clearing that up.
thank you very much for this hint!
“refresh the page and don’t click on retry”, that’s the clue!
I have stumbled over this issue so many times and didn’t imagine the solution would be so easy.
I had the exact parsing error when updating from 29.0.RC3 to 29.0.RC4. ended up refreshing the page around 20 times, since I had no clue what was happening, but in the end, the update completed just fine.
Hi all,
New poster here.
It may not belong exactly to this thread but is the closest I could find.
I’m having a similar issue updating manually (and web interface, for that matter).
Looking at the updater.log i find a double slash between the data/ and the /updater-randomcharacterschain (something like this: /path/to/data/data//updater-ocdl7b532hux/backups/nextcloud-27.1.3.2-1714290930/
) and gets stuck there. For hours. The directory is not even created.
Are you using the updatedirectory parameter by chance? That’s the first thing that comes to mind. Note this parameter should not be set unless you’re doing something special.
Thanks jtr.
No, I’m not using it, that I’m aware of. Not in the config.php file, not in the command launched.
I realised that I had a trailing slash in the datadirectory config as per [Solved] 12.0.2 to 12.0.3 Update Failes at "Create Backup"
I fixed it and now the log shows the correct path.
Copy is created, but it still get’s stuck there.
One possibility - particularly if you have a larger file count / folder depth (or higher latency filesystem) - is you’re getting hit by #507.
As a workaround, you can skip the backup by running the Updater from the command line and specifying --no-backup.
Thank you jtr.
Yes, it looks like I may be hit by the bug you point out and/or misconfigurations on my server.
Running the update with no backup looks a bit risky to me, but I appreciate the help.
The Updater managed backup is only used internally by Updater. It’s not meant to be used in place of whatever backup mechanism you have in place. It doesn’t cover your data. It’s just a backup of the Server/app code for the version being updated + config (you should be backing up your config too already!).
In the future it might be used for additional rollback/undo flexibility in the Updater, but by then #507 will also likely be addressed…