Nextcloud app always recreates ix-nextcloud_redis-data Docker volume; triggers postgres_upgrade on fresh installs (even with host path storage)
I want to add a concrete technical finding to the ongoing Nextcloud app issues on TrueNAS SCALE. Many existing threads describe symptoms such as postgres upgrade loops, unhealthy containers, or suspected permission problems, but this specific root cause does not appear to be clearly documented.
This issue is reproducible on a clean system with brand-new datasets and is not a filesystem permissions problem.
Environment
TrueNAS SCALE (current release)
Nextcloud app (latest chart)
Brand-new ZFS datasets
Host path storage selected for all configurable paths
System rebooted between install attempts
Key finding
The Nextcloud chart always creates a named Docker volume called:
ix-nextcloud_redis-data
This occurs:
-
on every deployment
-
even when host path storage is selected
-
even after deleting the app
-
even after rebooting the system
-
even with completely new datasets
This can be verified immediately after a failed install by running:
docker volume ls | grep nextcloud
Result:
local ix-nextcloud_redis-data
This volume exists outside ZFS, in Docker’s global volume namespace, and is not removed when the app is deleted.
Why this breaks fresh installs
Because this Redis Docker volume persists across deployments, the chart appears to assume an existing installation and automatically injects the postgres_upgrade service, even when the Postgres dataset is new and empty.
From /var/log/app_lifecycle.log on a clean install:
Container ix-nextcloud-postgres_upgrade-1 Starting
service “postgres_upgrade” didn’t complete successfully: exit 1
In later attempts, Postgres and Redis may both report healthy, but Nextcloud then fails its healthcheck:
dependency failed to start: container ix-nextcloud-nextcloud-1 is unhealthy
At that point, the database state is already inconsistent due to the failed upgrade attempt.
Important clarifications
This is not caused by leftover datasets.
This is not caused by filesystem permissions (verified writable).
This is not a Redis service failure.
This is not user misconfiguration.
This appears to be a chart logic issue:
Redis Docker volume exists
→ chart assumes upgrade scenario
→ postgres_upgrade runs
→ fresh install fails
Why host path storage does not prevent this
Even when all visible storage options are configured as host paths, Redis still uses a named Docker volume that cannot be overridden via the UI. That volume is the trigger for the upgrade logic.
Manually removing the volume allows a clean install:
docker volume rm ix-nextcloud_redis-data
However, the volume is recreated on every redeploy.
Expected behavior
At least one of the following should occur:
-
Redis storage should be configurable to use host paths
-
Named Docker volumes should be cleaned up when the app is deleted
-
postgres_upgrade should not run when no database exists
Currently, a “fresh install” is not actually fresh.
Posting this to add a concrete, reproducible data point for others troubleshooting repeated Nextcloud app failures on TrueNAS SCALE.