NCP 1.57.x updating NC fails if app previewgenerator is not installed

Start in library.sh by reading is_app_enabled, then inspect its call from bin/ncp-update-nc.d/update-nc.sh. Verify that the function checks the app passed to it, especially notify_push, and review the update path for the reported reinstall failure. Done means the check no longer causes an unnecessary notify_push installation when the app is already enabled.

See discussion:
[NCP - Nextcloud Update 33.0.3 fails](https://help.nextcloud.com/t/ncp-nextcloud-update-33-0-3-fails/244550?u=geow)
There user ernolf (Raphael Gradenwitz) finds:

The root cause appears to be a bug in bin/ncp-update-nc.d/update-nc.sh.

The update log shows this sequence after a successful occ upgrade:

There are no commands defined in the "app_api:daemon" namespace.

notify_push already installed
Abort
Clean up...

Here is what actually happens, step by step:

Step 1 — app_api:daemon:list (line 222)

if $ncc app_api:daemon:list | grep 'No registered daemon configs.' > /dev/null 2>&1
then
$ncc app:disable app_api
fi

Since app_api is disabled on your system, the app_api:daemon command namespace does not exist. The error is visible in the log. However, this does not cause the rollback — the failing command is inside an if condition, so bash’s ERR trap does not fire here.

Step 2 — is_app_enabled has a bug (library.sh)

function is_app_enabled()
{
local app="$1"
ncc app:list --output json | jq -r '.enabled | keys | .[]' | grep '^previewgenerator$' > /dev/null 2> /dev/null
}

The $app argument is accepted but never used. The function always checks whether previewgenerator is enabled, regardless of which app is passed.

Step 3 — The broken check causes the install block to be entered

The script calls:

if ! is_app_enabled notify_push; then
ncc app:install notify_push
...
fi

The intent is: “if notify_push is NOT enabled, install it.” But because is_app_enabled always checks for previewgenerator instead, the actual question being answered is: “is previewgenerator enabled?”

previewgenerator is not in your enabled apps list → the function returns false → ! false = true → the install block is entered, even though notify_push is in fact already enabled and installed.

Step 4 — ncc app:install notify_push fails

notify_push is already installed. Nextcloud’s occ app:install exits with a non-zero status when the app is already present, outputting “notify_push already installed”. The script has trap rollback ERR active, so this non-zero exit triggers the rollback function, which prints “Abort\nClean up…”.

In short: The update fails because of a bug in is_app_enabled in library.sh — it always checks for previewgenerator instead of the app passed as argument. This causes a spurious attempt to reinstall notify_push, which fails and triggers the rollback.

This bug was introduced in PR #2100 (“Add support for NC 33 + fixes”), merged 2026-04-03, and is present in v1.57.0 and v1.57.1. That PR also migrated to the upstream previewgenerator — it looks like previewgenerator was temporarily hardcoded for testing during that work and never changed back to $app before the merge. Before PR #2100 the function correctly used $app. This is a regression worth reporting to the NCP maintainers at Issues · nextcloud/nextcloudpi · GitHub — you can reference this post as context.

I should note that I don’t run NCP myself — I derived all of this purely from reading the source code, so I may be wrong on some details. The NCP developers will be able to verify quickly.

As a workaround until it is fixed, you could try enabling previewgenerator before running the update (so the broken check passes), or manually patch library.sh on your NCP system to use $app instead of the hardcoded previewgenerator.

h.t.h.

ernolf