fix(deploy): auto re-own data volumes to UID 1000 (#958 / #874)

[dolho]

Summary

Dev deploys have been failing since 2026-05-27 with container ***-backend is unhealthy. Root cause confirmed via docker logs on the dev VM:

sqlite3.OperationalError: attempt to write a readonly database
  File "/app/db/migrations.py", line 2096, in _migrate_null_legacy_schedule_timeouts
    cursor.execute("UPDATE agent_schedules SET timeout_seconds = NULL ...")

After issue #874 the backend and scheduler run as UID 1000 inside the container, but the dev VM's /data bind mount + agent-configs named volume were still owned by root from the prior root-container era. Earlier deploys survived because no migration actually wrote to existing rows — #922's null_legacy_schedule_timeouts was the first UPDATE migration after #874, so it's the one that surfaces the permission gap. SQLite then fails the whole startup, /health returns 503 forever, and the workflow's up -d times out at the unhealthy gate.

docs/migrations/NON_ROOT_CONTAINERS_2026-05.md documents the manual re-own recipe for operators. Nobody ran it on the dev VM.

Fix

Pre-flight in deploy-dev.yml that auto-runs the canonical recipe. Idempotent:

• Bind mount: stat -c %u "${TRINITY_DATA_PATH:-./trinity-data}" → chown -R 1000:1000 only if not already 1000.
• Named volume ${PROJECT}_agent-configs: probe ownership with an ephemeral alpine container, chown via a second ephemeral container (--user 0) only if not 1000.

Both branches no-op silently on healthy VMs, so it's safe on every deploy.

Why CI rather than a one-shot manual fix

• This works the first time on the dev VM and any future VM rolled before fix(security): add non-root USER directive to 4 production Dockerfiles (CSO hardening, persistent since 2026-04-05) #874.
• No SSH access required for the routine deploy path.
• Self-heals if some other procedure later re-roots the volumes.

Test plan

• Merge → deploy-dev workflow runs → pre-flight detects the root-owned data path, re-owns, build proceeds, backend reaches /health healthy.
• Subsequent deploys: pre-flight is silent (no Re-owning ... log line), unchanged behavior.
• If the dev VM's TRINITY_DATA_PATH is something other than the compose default, the bind-mount check is a no-op (directory doesn't exist) — script proceeds without error.

Out of scope (follow-up)

When up -d times out for any other reason, the workflow currently produces no logs because set -e aborts before the "Error check" step. Worth a separate small PR to wrap the up + health checks with a trailing docker logs capture so the next incident is one-click triaged. Not bundling here.

🤖 Generated with Claude Code

[dolho]

/review report — fine to merge

Critical findings: 0
Informational findings: 2 (bounded, non-blocking)

Pass 1 (critical / blockers)

• SQL & data safety — no DB writes
• Race / concurrency — chown to 1000 when the running container also runs as 1000 is a no-op; prior failed deploys left backend/scheduler stopped, so no in-flight writes to contend with
• Auth boundary — no new endpoints
• Credential exposure — log lines emit $DATA_UID (integer) and $TRINITY_DATA_PATH (relative path); no secrets

Pass 2 (informational)

[I1] Custom TRINITY_DATA_PATH from .env would be silently missed. Script reads TRINITY_DATA_PATH="${TRINITY_DATA_PATH:-./trinity-data}" from the SSH shell. SSH session doesn't source .env, so if the dev VM's .env sets a non-default path (e.g. /var/lib/trinity), the shell defaults to ./trinity-data, the [ -d ... ] guard fails, the chown silently skips, and the same migration crash recurs on the actual mounted path. Not a problem for the current dev VM (uses the default), but cheap insurance worth adding: set -a; . .env 2>/dev/null || true; set +a before reading the var, OR parse the path from docker-compose config.

[I2] alpine image is unpinned. docker run --rm … alpine … pulls latest from Docker Hub. The repo's container-security.yml workflow pins SHAs elsewhere; consistency would suggest pinning here too. Low priority — ephemeral container, chown only, bounded blast radius. Pin to alpine:3.20 or a digest if you want to close it.

Scope check

CLEAN. Single file, single concern, scope matches PR title and body exactly.

Other categories — clean

Conditional side effects (guards fail safe — chown fires on unknown UIDs, no-op on 1000) · magic numbers (1000 matches the Dockerfile USER directive; varying would be worse) · dead code · error handling (set -e at line 30 catches chown failures; stat … || echo "0" defaults to "definitely chown" on probe failure — safe default) · frontend (none) · performance (one-shot chown + two ephemeral containers per deploy, negligible after first run) · enum completeness (no enums)

🤖 Generated by /review (Claude Opus 4.7)