Even if you put it before to update to your dowload folder?
Downloading: downloads the code in the version it should update to. This is also shown in the web UI before the update is started. This archive is downloaded to /updater-INSTANCEID/downloads/ .
I strongly believe if you download archive manually e.g. via torrents and put it into downloads folder, the automatic updater will simply skip this step and proceed to “Extracting” step. Maybe it will calculate some checksum before
There are existing repos for open source software (https://www.gnu.org/server/mirror.html), either use one of them or set up something similar. Setting up a similar mirror with rsync shouldn’t be a that difficult either.
I don’t think so. I care about updates with updater.phar not about new installations. And there’ s no nc.zipin the code. This is the reason why I created this issue.
Tonight the apps.nextcloud.com site literally was unreachable (independent of DNS provider) nextcloud.log gave me the clou.
To make sure, you can try to reach the url from server as well as typing the url directly in your browser. If DNS is broken only one should fail and the other one succeed. If it is the site, both will fail.
I noticed the same behavior on multiple nextcloud instances.
In our forums (nethserver) we also had members that noticed the issue. Glad it has been solved.
Nextcloud 20 has been officially been published at the weekend so that many users are currently downloading the latest version. Therefore it is very likely that the servers are a little bit overloaded at the moment
That is a reasonable explanation, indeed. I was aware of the update but expected Nextcloud to have better bandwidth, therefore the only explanation I thought of was a technical problem.
This leads to Errors while updating though. I am permanently stuck at Step 4. Each time I restart the update (with the button that appears if an error e.g. due to NGINX timeout), the perfectly fine file sitting in updater…/download is discarded (although I verified that it’s complete and fine using sha2556sum). Therefore, the updater app should be enhanced – this would save bandwidth on the server for all users that do retry!
I can confirm this behavior: The download indeed finishes successfully, but takes way longer than the updater is willing to wait (times out). The downloaded file is still perfectly fine, matching checksums and all. So, being stuck at Step 4 (or occassionally even Step 5, when apparently the checksum file is not reachable for download), the perfectly fine update file gets deleted and downloaded anew.
So, the overloaded download servers are the update script’s own naïve fault. Something like this should be avoidable so easily.
1- Find into folder data “updater-{user}”
2- Upload file nextcloud-xxxx.zip into downloads
3- return to root directory updater-{user}
4- Create new file “.step” and put this object: {“state”:“end”,“step”:4}
5- run from cli sudo -u {user} updater/updater.phar
if Verify integrity failed return to 4 point and put {“state”:“end”,“step”:5}
There is another topic No apps to install about connectivity issues to nextcloud.com infrastructure. Is someone looking into it? What is the procedure to let the right people know, that something could be wrong?