Automatic updates fail silently when image pulls fail — no notification, daily log still says successful

[EagleEyeElite]

Steps to reproduce

1. Enable daily backup + automatic updates (data/daily_backup_time with empty second line), success notifications disabled (failure notifications implicitly on — the state after unchecking "send success notifications").
2. Break docker pull on the host in a way that fails layer extraction (in my case: an Incus 7.0.0 seccomp regression, seccomp mknod interception returns EPERM for calls from non-leader threads (breaks Docker whiteouts / image pulls) lxc/incus#3637, made every pull of a layer containing a whiteout fail with failed to register layer: failed to mknod(...): operation not permitted; a registry outage or full disk should behave similarly).
3. Wait for the nightly run.

Current behavior

The nightly flow runs "successfully" every night while updating nothing:

• Cron/PullContainerImages.php exits 0 and prints nothing when pulls fail (verified by running it manually inside the mastercontainer while pulls were broken; aio_log_level=warn).
• daily-backup.sh logs Updating container images... → Creating daily backup... → Daily backup successful! with no hint of the failed pulls.
• No failure notification is sent (backup succeeded, and pull failures don't trigger one).

Result: the instance silently ran images from 2026-05-22 (Nextcloud 33.0.3) for ~6 weeks while upstream moved to 33.0.6. The only user-visible signal was Nextcloud's generic "update available" banner in the admin overview — nothing indicated that automatic updates were failing, and nothing pointed at the host-level pull problem.

Expected behavior

When automatic updates are enabled and PullContainerImages (or the watchtower mastercontainer update) fails, AIO should treat it like a backup failure: send a failure notification (and/or log a clear warning in the daily-backup log / AIO interface), e.g. "Automatic update failed: could not pull image X: ". The underlying docker error message would have made the root cause immediately findable.

Host OS

NixOS 26.05pre (host) / Alpine 3.21 (Docker host, unprivileged Incus container), aarch64

Nextcloud AIO version

Mastercontainer image from 2026-05-22 (nextcloud/all-in-one:latest, digest 5d2d488a…) — the version that itself couldn't update due to the same pull failure.

Other valuable info

The pull failures were caused by an Incus host regression (lxc/incus#3637), not by AIO — this report is only about the failures being swallowed silently. Happy to provide the full diagnosis timeline if useful.

[szaimen]

Hi, thanks foe the report! I agree we should add some safeguard for this and harden the failure tolerance if pulling fails.