[Bug]: Updater fails deleting old files as core/shipped.json couldn't be deleted

[skyynet]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• Nextcloud Server is running on 64bit capable CPU, PHP and OS.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

Performing the web updater of nextcloud, I experience the same problem since years.
The updater fails, deleting core/shipped.json as this file was already deleted by the updater.
My remedy is, to re-create a folder core and copy shipped.json into it and hit "Retry update" a couple of times.
If file doesn't exist, updater shouldn't try to delete it or ignore it, when it doesn't exist.
Should be pretty easy to fix.

Steps to reproduce

1. Start web updater

Expected behavior

Updater finishes without errors

Installation method

Official All-in-One appliance

Operating system

Debian/Ubuntu

PHP engine version

PHP 7.4

Web server

Apache (supported)

Database engine version

MySQL

Is this bug present after an update or on a fresh install?

Updated from a minor version (ex. 22.2.3 to 22.2.4)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

./.

List of activated Apps

only standard apps from clean install

Nextcloud Signing status

No errors have been found.

Nextcloud Logs

This is the updater log from 24.0.4 to 24.0.5

2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] request to updater
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] currentStep()
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] POST request for step "9"
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] startStep("9")
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] deleteOldFiles()
2022-09-18T14:42:26+0200 ocEQ4fZtbD [error] POST request failed with other exception
2022-09-18T14:42:26+0200 ocEQ4fZtbD [error] Exception: Exception
Message: core/shipped.json is not available
Code:0
Trace:
#0 /home/www/07/74/ihskyynd/skyycloud/updater/index.php(1386): Updater->deleteOldFiles()
nextcloud/server#1 {main}
File:/home/www/07/74/ihskyynd/skyycloud/updater/index.php
Line:926

2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] rollbackChanges("9")
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] unlink .step
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] rollbackChanges - step >= 7
2022-09-18T14:42:26+0200 ocEQ4fZtbD [info] end of  rollbackChanges()

Additional info

When I managed to pass the "Delete old files" section, I have a minor problem at "move files to new place" where I have to click "Retry update" a couple of times. In the log, I see some rmdir failed for the apps directory. Seems to be related as updater hangs when deletion of files or directories fails when they are not present (anymore).
I suggest either adding some "file/directory, which should be deleted, does not exist. Continue?" prompt or simply ignoring this issue while updating.

[skyynet]

bug stil persists while updating from 24.0.5 to 24.0.6.

I suggest either adding some "file/directory, which should be deleted, does not exist. Continue?" prompt or simply ignoring this issue while updating.

[joshtrichards]

The updater fails, deleting core/shipped.json as this file was already deleted by the updater.

While this is occurring within the deleteOldFiles() step, this particular error isn't while attempting to delete <installation_folder>/core/shipped.json. It's when loading the one from your existing installation in order to compare it to the one from the about to be deployed version. This is a critical part for handling updates of shipped apps.

updater/index.php

Lines 924 to 927 in bd6a411

	$shippedAppsFile = $this->baseDir . '/../core/shipped.json';
	if(!file_exists($shippedAppsFile)) {
	throw new \Exception('core/shipped.json is not available');
	}

My remedy is, to re-create a folder core and copy shipped.json into it and hit "Retry update" a couple of times.
If file doesn't exist, updater shouldn't try to delete it or ignore it, when it doesn't exist.

That file should definitely still be there. So should the core folder for that matter.

Can you provide the full updater log as well as your config (occ config:list system)?

Is your updater folder (/home/www/07/74/ihskyynd/skyycloud/updater) located outside your installation folder or anything unusual you can think of (like some symbolic links in place or something)?

[joshtrichards]

Related:

• Update failed with core/shipped.json is not available #131
• NC updater 15.0.2 still fails on Delete old files (core/shipped.json is not available) #222

[skyynet]

Thanks for reply. As described, the mentioned workaround is, what I do for years, now. I have to open an ftp client and copy core/shipped.json about 30 times and click retry in updater, to have it continuing, while updated wants to delete old files. I also have to hit retry about 15 times while updater is moving files, but no copy & paste in ftp needed for this.

My updater folder is located as subdirectory in the nextcloud folder, so nothing special, I'm aware of.

You wrote "It's when loading the one from your existing installation in order to compare it to the one from the about to be deployed version. This is a critical part for handling updates of shipped apps."

In my case, the shipped.json and it's folder core seems no longer present, when comparison happens.
My suggestion would be, to ignore this error or at least offer user in web updater to continue anyway, when old shipped.json is not present.

Attached is the updater log and the config with x-ed pwds.
updater.log
config.txt

[joshtrichards]

Next time you attempt an Updater run, can you run it from the command-line? It's possible there are additional clues surrounding the rmdir() failures and whatnot, that aren't making it into the logs.

Also:

• what is the underlying filesystem? It looks like you may be in a shared hosting environment or something. Perhaps it's NFS?

Btw, you specified "Official All-in-One appliance" but I assume that's wrong? This isn't how you'd update AIO.

[skyynet]

I don't want to experiment with the uncomfortable but working way via the web updater.
Yesterday, I upgraded 28.0.5 to 28.0.6 and today 28.0.6 to 29.0.1.
Same behavior. Log attached. Maybe something may be seen inside.
updater.log