No, only the download fails.
Just delete the updater-xxxxxxxxx folder and try the update later.
Letâs say in 2 days? 
After a couple slow failures I got through the update this way:
- deleted the .step file
- deleted partial zip download
- cd into data/updater-ocxxxxxxxxxx/downloads
- wget the update zip (took 48 minutes)
- repeated the update from the Overview page (took about a minute)
This was for getting to 30.0.7. Now thereâs an update offer for 31.0.1. Maybe later when more apps are ready.
For me this does not work. I wrote an issue for that feature. If it works a documentation would be nice.
Connectivity has been restored and the update is now working again.
But only if you delete the updater-xxxxxxxxx folder before the update process.
Maybe they build a function in the administrator interface of Nextcloud that does this? Instead of deleting the folder on the console because not everyone has ssh access?
I miss this function with wget or other copy functions Does it really exists?
If the wget command isnât found itâs probably not installed. As root user run apt-get install wget or dnf install wget or whatever package manager youâre using.
Download the update as the web server user (www-data, apache, or whoever owns Nextcloud).
wget https://download.nextcloud.com/server/releases/nextcloud-30.0.7.zip
Same problem again for 30.0.8âŚ
Again for 31.0.1
Hopefully solved with Nextcloud 32:
feat(updater): download resume w/ transfer statistics #571
Maybe you can copy manually the zip file in the downloads folder and set in .step:
{"state":"end","step":4}. Read here (sorry german).
Looking good!
And what about load balancing the zip file across multiple data centers, mirrors, servers, etc.?
Since obviously the problem is indeed when everybody is receiving a notification and try to upgrade Nextcloud at the same time.
In some cases this scenario would be catastrophic, especially when Nextcloud would release a new update to fix a critical 10/10 vulnerability, where all servers will most likely cause this issue across the world.
Maybe as a follow up PR; The problem would also be way less severe, if the download would happen before putting Nextcloud into maintenance mode.
I donât care that the overwhelmed server needs 5h to upload an update. I care that if it takes 5 hours, my instance is in maintenance mode for the whole time.
It would also be nice to simply have an optional parameter in config.php for downloading the ZIP file. This could be either a URL or a local file. It could also minimise the load on the download server in the case of multiple installations.
That wouldnât be difficult to implement, would it? Maybe a developer is reading along. It will soon be Christmas again. Itâs time to make a wish.
This is already how the updater functions today.
Maintenance mode isnât activated until after the download completes (and only after the archive is verified and extracted).
Can you elaborate where youâre seeing differently?
Well⌠To be honest I have the feeling that since some months the admins of the download.nextcloud.com implemented a rate limit.
And no, its not my link, nor my routing.
It does not matter if I use the webupdater, curl or wget. All Downloads are extremely slow. As well that the integrity check fails, I have to reload Nextcloud, do it again, integrity check works then it can be finally updated.
Not to mention that I have to initiate the update again and again because the download fails.
To be absolutely honest. In case of a CRITICAL update. I do NOT want to try over and over again to install an update.
As I have this speed issue from Links all over the world, I guess itâs quite obvious, that the speed is limited. Before it took seconds to download an update and as well to upgrade my machines.
Sorry, my fault. I misremembered it, because of my workflow.
I put the VM into maintenance, shutdown, take a snapshot in case anything goes south, boot, start the updater in cli. I could simply disable maintenance mode before starting the cli updater. My bad.