edit: since I run backups of the vm and database externally I can use the
Nextcloud version (eg, 20.0.5):
Operating system and version (eg, Ubuntu 20.04):
Alpine Linux 3.17
Apache or nginx version (eg, Apache 2.4.25):
PHP version (eg, 7.4):
Nextcloud Updater version:
alpine linux 3.17
The issue you are facing:
docker exec -it nextcloud updater.phar stalls on the third step, Create Backup.
Is this the first time you’ve seen this error? (Y/N): N
Steps to replicate it:
Follow the update instructions on docs.linuxserver.io/docker-nextcloud
- pull the latest image,
- redeploy container,
docker-compose down && docker-compose up -d
- run updater.phar,
docker exec -it nextcloud updater.phar
Update stalls on step 3, create backup. This step is supposed to just make a backup of the code base so shouldn’t take very long as database or data are not included. I have left this step over night, nothing.
Inspecting the process in
htop shows the php process in uninterruptible sleep, with 10 sleeping child processes, I/0 shows nothing going on.
Reading up on D suggests the problem might stem from having the data drive mounted in through NFS. I feel like this is a pretty common way to set it up so would be nice if updater.phar wouldn’t die from this. The NFS server shows no activity either and is working fine for other VMs using it.
2023-02-26T00:07:44+0000 9klOnLUheC [info] endStep("1") 2023-02-26T00:08:04+0000 9klOnLUheC [info] executeStep request for step "2" 2023-02-26T00:08:11+0000 9klOnLUheC [info] startStep("2") 2023-02-26T00:08:29+0000 9klOnLUheC [info] checkWritePermissions() 2023-02-26T00:08:36+0000 9klOnLUheC [info] end of checkWritePermissions() 2023-02-26T00:08:42+0000 9klOnLUheC [info] endStep("2") 2023-02-26T00:09:00+0000 9klOnLUheC [info] executeStep request for step "3" 2023-02-26T00:09:06+0000 9klOnLUheC [info] startStep("3") 2023-02-26T00:09:26+0000 9klOnLUheC [info] createBackup() 2023-02-26T00:09:33+0000 9klOnLUheC [info] backup folder location: /data/updater-ocxvj5o6uwxx/backups/nextcloud-188.8.131.52-1677370173/
The other logs don’t seem relevant.