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
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