• v0.10.5 2b2e77768c

    v0.10.5
    Some checks failed
    CI / Build / Publish / Validate CHANGELOG structure (push) Successful in 1s
    CI / Build / Publish / Shellcheck (push) Successful in 4s
    CI / Build / Publish / Bats unit tests (push) Successful in 10s
    CI / Build / Publish / PR build & smoke test (push) Has been skipped
    CI / Build / Publish / Host-driven integration (entrypoint + storage sidecars) (push) Successful in 2m23s
    CI / Build / Publish / Round-trip + scheduler smoke (push) Successful in 4m19s
    CI / Build / Publish / Build multi-arch and push (push) Successful in 4m3s
    CI / Build / Publish / Reconcile releases across registries (push) Successful in 1m5s
    CI / Build / Publish / Workflow summary (push) Failing after 1s
    Stable

    Cody Bryant released this 2026-08-16 17:48:26 -07:00 | 24 commits to main since this release

    Fixed

    • The recovery kit still landed unreadable to a mirror/backup user on an ACL-backed share (e.g. a Synology volume) after 0.10.4: the staged copy did inherit the destination directory's ACL, and the chmod that stamps the kit with the storage's own mode then discarded it. On such a share the ACL is the access model — from inside the container every file in the store reads as a plain owner-only mode with no ACL visible at all — so the kit was chmod'ed to the mode it already carried, lost the inherited ACL for nothing, and verified clean because its mode still equalled that of the storage's config. The kit is now chmod'ed only when that would actually change its mode, so a placement already matching the storage keeps whatever access the directory granted it. The placement-scheme version is bumped, so existing deployments re-place their already-placed kit once on the first backup (or archiver recovery-kit) run after upgrade — no recovery-kit force needed.

    Dependencies

    • chore(deps): update dependency aptible/supercronic to v0.2.49
    Downloads