[Workaround available] Updater.phar stalls on Backup

edit: since I run backups of the vm and database externally I can use the --no-backup flag

Nextcloud version (eg, 20.0.5): 25.0.2
Operating system and version (eg, Ubuntu 20.04): Alpine Linux 3.17
Apache or nginx version (eg, Apache 2.4.25): nginx/1.22.1
PHP version (eg, 7.4): 8.1

Nextcloud Updater version: v25.0.1-4-g5649b58
docker image: lscr.io/linuxserver/docker-nextcloud:latest 1cac8b193de6
container host: alpine linux 3.17
hypervisor: proxmox 7.3.4

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

  1. pull the latest image, docker-compose pull
  2. redeploy container, docker-compose down && docker-compose up -d
  3. 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-

The other logs don’t seem relevant.

Maybe you do not use the backup function.

sudo -u www-data php /path/to/nextcloud/updater/updater.phar --no-backup

docker exec -it nextcloud updater.phar --no-backup

Make your own backup. :grinning:


I got the same issue as the requestor, but as I do backups differently as well as using ZFS with daily sanpshot and 14 days rotation, I use the no backup flag. And as I do it in a script, I also use the no interaction:

/nextcloud/updater/updater.phar --no-backup --no-interaction

So maybe this could be a free inspiration for some:

#! /bin/bash
rm tmp.txt
SQLFILE="/path/to/desired/backupfolder/sqldumps/nc-$(date +"%Y-%m-%d_%M-%H")"

mysqldump --opt --user='ncdbuser' --password='ncdbpassword' 'ncdatabase' > "$SQLFILE.sql"
gzip -c "$SQLFILE.sql" > "$SQLFILE.gz"

sudo -u www-data php8.1 /var/www/nextcloud/occ maintenance:mode --on
gzip -r /var/www/nextcloud/data/* "/path/to/desired/backupfolder/ncbackup-$(date +"%Y-%m-%d_%M-%H").gz"

apt-get update -y
apt-get upgrade -y

PHPCOMMAND="sudo -u www-data php8.1" #Keep PHP version up to date!!
commands[0]="/var/www/nextcloud/updater/updater.phar --no-backup --no-interaction"
commands[1]="/var/www/nextcloud/occ db:add-missing-indices"
commands[2]="/var/www/nextcloud/occ maintenance:mode --off"
commands[3]="/var/www/nextcloud/occ maintenance:data-fingerprint"
commands[4]="/var/www/nextcloud/occ app:update --all"

for i in "${commands[@]}"; do eval $PHPCOMMAND $i; done

systemctl restart php8.1-fpm #Keep PHP version up to date!!
systemctl restart apache2

1 Like

Which backup function?

I backup the VM weekly and use snapshots of it between updates.

Last time I used updater.phar it made it past the backup stage and I found a folder in the data location with what seemed like a backup?

This is great!

I have a similar setup, except I use a postgres database, but I will run updater.phar with those flags in the future c:


No worries.

The above script is doing much more ofc. The interesting one for excactly your question is only:

sudo -u www-data php8.1 /var/www/nextcloud/updater/updater.phar --no-backup --no-interaction

However use the script with your own modifications as you see fit, or just parts of it.

  • I use it like that because I first backup database to a location I controls.
  • I do backup of all the data (this is very big if many users and if you offsite backup in other ways, no need for this).
  • Then I do OS package upgrades jsut in case, which you can probably remove as well.

Then I do the Nextcloud upgrade routine:

  • Upgrade
  • Missing indices (just to be sure).
  • Then regenerate file fingerprints.
  • Update all apps.
  • Restart PHP-FPM and apache.

The bullet points above is recommended to do after each upgrade, if you also do OS package upgrades. And with my small user base, it is not noticed, so better safe than sorry. :slight_smile:


1 Like

That’s great, thanks.

For this setup the data lives on an NFS server that is backed up differently.

For the database I’m working on setting up another backup database that with live sync and for both of them to do a database dump weekly.

Package updates come with pulling the new containers so I need to keep an eye on the release notes from linuxserver.io for breaking changes c:

1 Like

You can also read the documentation Backup and Restore.