Running Nextcloud web part in a Ubuntu VM in ESXi and the backend is mounted from a FreeNAS server using NFS. FreeNAS is squashing all user access to the same www-data uid.
Running Nextcloud v12.0.5 ; forced it to the beta channel and tried to update to 13.0.0 (can’t wait for Talk
Update failed at step 4.
Did some research and the common solution did not fixed my case (deleting the .step file).
Error is about a directory that can not be removed. Even if I remove it manually using the shell and re-try the process, it does not help. The directory is updater-GARBAGE/backups/nextcloud-12.0.5.3
Before trying the update, I shutdown the VM and took a snapshot of it. FreeNAS is also taking snapshots all the time.
After a few failures, I restored the VM. I was surprise when the VM still noticed that it was at step 4 of the update process. I restored the FreeNAS server as well and that got rid of the temp files.
I can easily rollback both the VM and the FreeNAS to the previous state before my upgrade, so I can do as many test as I wish.
Nextcloud version from 12.0.5 to 13.0.0
Operating system and version ESXi 6.5 ; Ubuntu 16.4.3
Apache or nginx version : Apache 2.4.18
PHP version : 7.0
The issue you are facing: Update blocks at step 4
Is this the first time you’ve seen this error? : No. Update from 12.0.4 to 12.0.5 ended up problematic too, but deleting the .step file and other tricks mentioned in other posts did it.
Steps to replicate it:
Start the updater from the Admin section of Nextcloud 12.0.5
Have the process stop at step 4
Delete the .step file to go a little further
Receive the error message about not being able to rmdir the backup directory
The output of your Nextcloud log in Admin > Logging:
So after another round, here is what I noticed :
–When updater stops with an error message at step 4, it is actually still working under the hood
–Some mechanism piles up the directories under the backup directory (updater-GARBAGE/backups/nextcloud-12.0.5.3)
–I used next command to see the progress :
find ./backups/nextcloud-12.0.5.3/ -type d -print | wc -l
–It maxed out a little above 3000 directories
–Should I delete the .step after this and hit Retry, number of directory drops to either 0 or vey low (can not confirm…) and start to pile up again up to 3000+
–Should I delete the content of ./backups/nextcloud-12.0.5.3 myself before removing the .step file and click Retry, it does not improve and again, directories start to pile up in the backup dir up to 3000+
–Should I remove the .step file before the directories are all added in the backup dir, the update stop and complains that it can not rmdir the backup dir (normal because while it tried to delete it, something else keeps adding more stuff in it…)
For now, I will rollback both my FreeNAS and VM to their previous state, v12.0.5 before trying to update.
Any help on how to get pass that step would be nice…
Ok… No idea from others and I gave up. I did a manual update instead.
The web updater is very problematic, not only for me, but according to many other posts. Last thing I can say is that it looks like it needs a serious review.
Jep I also saw someone else having connecting issue to nextcloud downloads yesterday. Worked for me as well. Seemed to be a temporary issue, so try again now.
Thanks for the idea. During the update, I did not check specifically for that. It is true that the server is behind a proxy but that proxy is allowing everything in the domain nextcloud.com. The question is, does that updater uses the proxy or not ?
I should remember this next time I will try the updater. Either the need to open a direct, non-proxy access or to ensure the updater is using the proxy properly. In all cases, this should be an error easy to catch and an explicit error message should be returned for that. No matter the environment, the updater did detect the new version on the beta channel, so clearly did connect to some Nextcloud resources on the Internet despite the proxy.
