Issue: ▎ Applying an in-app update first captures a pre-update rollback checkpoint — a safety step that records a restore point before the container image is swapped. On installs without a durable backup volume mounted, this step tried to create its working directory inside the container's root-owned application folder, which the app's non-root runtime user cannot write to, and failed with a filesystem permission error (EACCES). Because the checkpoint is fail-closed by design (it won't proceed without a rollback point), the update was safely aborted — nothing changed and the instance kept running its current version, healthy. It surfaced the first time this checkpoint ran on an install without durable backups; installs using the default (durable backups on) are unaffected. Fix: ▎ The update path no longer depends on a writable local backup directory: the fail-closed rollback point is recorded in a location that's always available and survives restarts, and the on-disk full backup is best-effort — so a backup-volume problem degrades gracefully instead of blocking updates. The container image also provisions a writable default backup directory for the non-root runtime user. The operator-facing error now names the actionable remedy (e.g., "the backup directory isn't writable — enable durable backups or point it at a writable path, then retry") instead of a generic message. Recovery for an already-affected install (self-service, since the update path itself was blocked): point the backup directory at a writable path, or enable durable backups, then retry.
The most likely culprit (and it fits: your 1.4→1.5 update worked before, so the machinery is fine — something changed since): the /backups durable mount is out of space or unwritable. Each update attempt writes a full pre-checkpoint backup there; if you clicked Update a few times, or scheduled backups accumulated on a small Azure Files share, a write can ENOSPC/EACCES and take the tiny checkpoint file down with it.
Updated the marketplace package with the fixed version 1.7.1 so this doesn't happen again.