Upgrade from Nextcloud 32.0.6~ynh2 to 34.0.2~ynh1 consistently fails on YunoHost 12.1.40.1

Support apps
, ,
1

What app is this about, and its version: 32.0.6~ynh2
What YunoHost version are you running: 12.1.40.1
What type of hardware are you using: Old laptop or computer

Describe your issue

Environment
YunoHost: 12.1.40.1
Debian: Bookworm
Nextcloud: 32.0.6~ynh2
Upgrade target: 34.0.2~ynh1
PHP: 8.3
Problem

Upgrading Nextcloud from 32.0.6~ynh2 to 34.0.2~ynh1 always fails.

YunoHost automatically restores the previous installation.

After the restore, Nextcloud is healthy again.

Verified

The installation has been thoroughly checked:

apt is healthy.
MariaDB is healthy.
Disk space is sufficient.
occ status is OK.
occ upgrade -vvv returns “No upgrade required”.
maintenance:mode is disabled.
files:scan, files:cleanup and sharing cleanup completed successfully.
LDAP configuration has been verified.
No incompatible apps (e.g. Memories) are installed.

After the automatic restore:

sudo yunohost app setting nextcloud php_version

returns:

8.3

The web interface may initially return HTTP 500, but it is restored by running:

sudo -u nextcloud php8.3 /var/www/nextcloud/occ maintenance:repair
Log observations

The upgrade log shows the package switching the application to PHP 8.4:

ynh_app_setting_set --key=php_version --value=8.4

Later, exec_occ detects that Nextcloud 32 still requires PHP 8.3:

NEXTCLOUD_PHP_VERSION=8.3
php_version=8.4

It then starts rebuilding the dependencies for PHP 8.3 before the upgrade aborts.

The log also contains:

BASH_XTRACEFD: 7: invalid value for trace file descriptor

although it is unclear whether this is related to the failure.

Additional information

I searched the forum and found several upgrade issues:

incompatible apps (Memories),
failed restore,
APT update failures,
script errors resolved after later PHP updates.

However, none of those cases match this one:

there are no incompatible app errors,
apt works correctly,
the restore succeeds,
the installation is healthy after restore,
the upgrade consistently aborts during the upgrade process.

The complete upgrade log is attached.

Share relevant logs or error messages

https://paste.yunohost.org/raw/ofiqivigam

2

What does return

grep -in --context=10 "User not found in backend" /var/log/nextcloud/nextcloud.log
1 Like
3

Hey,
Are you moving from version 32.0.6~ynh2 to version 34.0.2~ynh1.
Didn’t you make the updates between these two versions?
33.0.x, 34.0.1, 34.0.2

1 Like
4

Yes, that’s correct.
I postponed the updates because I didn’t have time to deal with any potential issues if something went wrong.
I’m upgrading directly from 32.0.6~ynh2 to 34.0.2~ynh1 because that’s the latest version offered by YunoHost when I finally decided to update.
Is upgrading through the intermediate versions required?

5

No, it does intermediate migration to 33.0.5 automatically, that one passed.

1 Like
6

Come to think about it perhaps do the intermediate step manually? There’s a maintained v33 branch available:

sudo yunohost app upgrade nextcloud -u https://github.com/YunoHost-Apps/nextcloud_ynh/tree/v33
1 Like
7

Here is the output.

The exception occurs during the repair step:



Exception while executing repair step "Cleanup share names with false conflicts"
OC\User\NoUserException: User not found in backend

The stack trace points to:



OCA\Files_Sharing\Repair\CleanupShareTarget

Interestingly, just before that the log reports:



\OC\Updater::updateEnd: Update successful

so it looks like the upgrade itself completes successfully and the failure happens afterwards during maintenance:repair.

8

Thank you. I’ll keep this solution in mind if I don’t see any progress.

10

Something weird in the output of

yunohost app shell nextcloud 
php occ share:list

?

1 Like
11

I don’t see anything obviously wrong in the share:list output.

The command completes successfully and I couldn’t find any entries with empty fields or missing users. Is there something specific I should be looking for?

12

The share:list output looks normal.

However, I checked the Nextcloud log and the exception always comes from:



OCA\Files_Sharing\Repair\CleanupShareTarget

during



Cleanup share names with false conflicts

where LazyUser->isEnabled() throws



OC\User\NoUserException
User not found in backend

So it looks like there is still a share referencing a user that no longer exists, but I cannot identify it from occ share:list.

13

Try this [Bug]: `NoUserException` `Backends provided no user object` · Issue #292 · nextcloud/files_fulltextsearch · GitHub

1 Like
14

Thanks for the suggestion, and thank you for taking the time to help me investigate this.

I found what may be a related case. It ended up being a stale Deck attachment referencing a deleted user, which triggered NoUserException. My share:list output is almost entirely deck shares, and my exception also happens while processing shares (CleanupShareTarget).

Do you think this could be a similar issue involving a stale Deck share or attachment?

15

I looked into the issue you linked. It doesn’t seem to be the same bug because I don’t have files_fulltextsearch installed. However, it made me think about the underlying cause: a stale reference to a user that no longer exists.

In my case, deck is installed and enabled (v1.16.7), and most of the shares returned by occ share:list are Deck-related. Since the exception is thrown from OCA\Files_Sharing\Repair\CleanupShareTarget, I’m wondering if a stale Deck share or attachment could be triggering the NoUserException.

When I have some more time, I’ll also try temporarily disabling Deck and retrying the upgrade to see whether the behaviour changes.

16

Good. You can open an issue in the deck repo. May be there is something they can improve in the app

1 Like
17

Thanks. That makes sense.

Before opening an issue in the Deck repository, I’d like to gather a bit more evidence that Deck is actually involved. I’ll try temporarily disabling Deck and rerunning the upgrade to see whether the behaviour changes. If it does, I’ll open an issue with all the details and logs.