fix(deploy): restore www-data ownership after deploy-code to prevent HTTP 500

justfile

@@ -103,7 +103,7 @@ build-check:
 # ============================================================================
 
 [group('deploy')]
-deploy: build deploy-code deploy-nginx deploy-deps deploy-migrate
+deploy: build deploy-code deploy-nginx deploy-deps deploy-migrate deploy-sudoers deploy-permissions
     @just deploy-env
     @just deploy-verify-permissions
     @echo ""
@@ -114,9 +114,48 @@ deploy: build deploy-code deploy-nginx deploy-deps deploy-migrate
 deploy-code:
     # Sync application code only (no Composer deps, no migrations, no nginx config).
     # nginx + server-side setup are handled by `deploy-nginx` (via deploy).
-    rsync -az --info=progress2 --delete \
+    # No -p/-t/-o/-g: the destination tree is owned by www-data:xamxam (setgid),
+    # so this SSH user can read/write it but cannot chmod/chown/settime files it
+    # doesn't own — preserving perms/times would fail every file with
+    # "Operation not permitted" and exit rsync 23. Ownership/perms are restored
+    # by `deploy-permissions` right after. Times are only used as a transfer
+    # heuristic here; --size-only keeps unchanged files from being re-uploaded
+    # since their remote mtimes are no longer preserved.
+    rsync -rlDz --size-only --info=progress2 --delete \
         --exclude-from=.rsync-exclude \
-        app/ xamxam:/var/www/xamxam/
+          app/ xamxam:/var/www/xamxam/
+    # Plain rsync (as this user) leaves newly-synced files owned by the caller,
+    # not www-data:xamxam — php-fpm then can't create SQLite journals in
+    # storage/ → HTTP 500. Restore ownership right after, so `just deploy-code`
+    # alone can never break the live site.
+    @just deploy-permissions
+
+[group('deploy')]
+deploy-permissions:
+    # Fix app-tree ownership/permissions on the host so www-data (php-fpm) can
+    # read code and write storage (/sqlite wal+shm), cache/, tmp/, var/. Needs
+    # sudo. Run after any deploy-code resync and as a dep of `deploy`.
+    #
+    # sudo here is NOPASSWD-scoped to /tmp/fix-permissions.sh via the
+    # deploy/xamxam-fix-permissions.sudoers drop-in (installed once by `just
+    # deploy-sudoers`). That avoids relying on an interactive remote pty, which
+    # is fragile: `ssh -t` silently drops the pty when local stdin is not a TTY,
+    # so sudo's prompt prints but accepts no input. If you have not installed
+    # the drop-in yet, this step will prompt for your password interactively.
+    @echo "🔒 Fixing www-data ownership/permissions…"
+    rsync -v scripts/fix-permissions.sh xamxam:/tmp/fix-permissions.sh
+    ssh -t xamxam "sudo bash /tmp/fix-permissions.sh && rm -f /tmp/fix-permissions.sh"
+
+[group('deploy')]
+deploy-sudoers:
+    # One-time install: scoped NOPASSWD sudo so `deploy-permissions` never needs
+    # an interactive remote pty (see deploy/xamxam-fix-permissions.sudoers for
+    # rationale). Privileged write to /etc/sudoers.d requires an interactive sudo
+    # password, so run this from a real terminal the first time.
+    @echo "🔒 Installing NOPASSWD sudo rule for fix-permissions.sh…"
+    rsync -v deploy/xamxam-fix-permissions.sudoers xamxam:/tmp/xamxam-fix-permissions.sudoers
+    ssh -t xamxam "sudo install -o root -g root -m 0440 /tmp/xamxam-fix-permissions.sudoers /etc/sudoers.d/xamxam-fix-permissions && sudo visudo -c -f /etc/sudoers.d/xamxam-fix-permissions && rm -f /tmp/xamxam-fix-permissions.sudoers"
+    @echo "✅ NOPASSWD rule installed. deploy-permissions will run without a password prompt."
 
 [group('deploy')]
 deploy-deps: