From bd0531e4a8ebeadc175f581087672e86f20af6d4 Mon Sep 17 00:00:00 2001 From: kisfenyo Date: Sat, 6 Jun 2026 14:17:20 +0200 Subject: [PATCH] manifests: umami -> 3.1.0 (v3 line) + filebrowser v2.63.13 with runAsUser:0 umami: Switch from SHA-pinned v3.0.3 to the tagged v3.1.0 release (the v3 line proper -- same schema lineage, normal Prisma minor-version migration). This is the documented forward path that the version- checker hint `postgresql-latest -> 3.1` indicated. The v1.x postgresql-vX.Y.Z line we briefly tried earlier today is a DIFFERENT image lineage with incompatible migrations -- avoid. filebrowser: Re-pin to v2.63.13 (debian-based default) so Renovate can track future bumps. The non-root UID in that image can't write to the existing PVC contents (chowned to root by the previous v2-alpine image), so set pod-level securityContext runAsUser:0 + runAsGroup:0 to keep using the same volume layout without a chown initContainer. Co-Authored-By: Claude Opus 4.7 (1M context) --- manifests/umami.yaml | 10 +--------- manifests/webpage.yaml | 15 +++++++++------ 2 files changed, 10 insertions(+), 15 deletions(-) diff --git a/manifests/umami.yaml b/manifests/umami.yaml index 73f1861..30ad07e 100644 --- a/manifests/umami.yaml +++ b/manifests/umami.yaml @@ -187,15 +187,7 @@ spec: cpu: "50m" containers: - name: umami - # NOTE: pinned to the exact image SHA the working 120d-old pod - # is on. v1.38.0 (the latest postgresql-vX.Y.Z) tries to apply - # migration `02_add_event_data` which requires an `event` table - # that this DB doesn't have -- the DB schema is older than v1 - # numbered migrations expect. Until we plan a proper migration - # (likely to umami v3.x, which is what the dashboard `→ 3.1` - # hint suggests), this stays SHA-pinned so Renovate doesn't - # touch it and pod restarts don't roll the version forward. - image: ghcr.io/umami-software/umami@sha256:28f263fe06f79ebffa5a6a6e9bd33b7a278e9342a88e0bdac812416c9f9e4361 + image: ghcr.io/umami-software/umami:3.1.0 ports: - containerPort: 3000 env: diff --git a/manifests/webpage.yaml b/manifests/webpage.yaml index 06fe460..aadd378 100644 --- a/manifests/webpage.yaml +++ b/manifests/webpage.yaml @@ -105,14 +105,17 @@ spec: labels: app: filebrowser spec: + # filebrowser v2.63.13 (debian default) runs as a non-root UID by default + # and can't write to PVC files left by the previous v2-alpine image (which + # ran as root). Force root explicitly so the existing PVC contents are + # readable + writable. (The alternative -- chown the PVC then drop perms -- + # needs a one-shot initContainer; not worth the moving parts here.) + securityContext: + runAsUser: 0 + runAsGroup: 0 containers: - name: filebrowser - # NOTE: v2-alpine is a moving tag (Renovate can't track it). - # Pinning to v2.63.13 (debian-based default) broke the PVC permissions - # (the image runs as a non-root UID and can't write to files left - # by the alpine variant). A clean re-pin needs either an initContainer - # to chown the PVC, or a fsGroup on the pod spec. Revisit when time permits. - image: filebrowser/filebrowser:v2-alpine + image: filebrowser/filebrowser:v2.63.13 ports: - containerPort: 8080 volumeMounts: -- 2.52.0