fix(docker): add diagnostic logging to entrypoint to debug permission issue
CI / Build Native (push) Successful in 6m53s

El chown sigue sin funcionar despues del primer fix. Agregamos logs
para ver:
- con que uid arranca el entrypoint
- ls -la /work/data antes y despues del chown
- si chown falla, lo logueamos en lugar de tragarnos el error

Tambien asegura que /work y /work/application tengan owner 1001:1001
y mode 0755, por si la imagen viene con owner root (que seria el
sintoma de que el build no usaria USER directive).
This commit is contained in:
2026-08-14 23:39:14 -04:00
parent 0bcd66ba32
commit 7ed41ac825
+18 -10
View File
@@ -1,15 +1,23 @@
#!/bin/bash
set -eu
# Arranca como root (USER no está fijado en el Dockerfile, así Docker usa root).
# En el primer arranque, /work/data es el punto de montaje del volumen named
# shot-crafter-data: Docker lo crea con owner root:root, lo que impide al UID
# 1001 (con el que corre la app) escribir. Tomamos root brevemente para
# arreglar los permisos, y después setpriv baja al UID 1001 para la app.
mkdir -p /work/data
chown -R 1001:1001 /work/data || {
echo "WARNING: failed to chown /work/data (root filesystem?); app may fail to start" >&2
}
chmod 0755 /work
echo "[entrypoint] pid=$$ uid=$(id -u) gid=$(id -g)"
echo "[entrypoint] /work/data BEFORE chown:"
ls -ldn /work/data 2>&1 || true
ls -la /work/data 2>&1 | head -50 || true
mkdir -p /work/data
chown -R 1001:1001 /work/data 2>&1 || {
rc=$?
echo "[entrypoint] WARNING chown /work/data rc=$rc (continuamos; la app puede fallar)"
}
echo "[entrypoint] /work/data AFTER chown:"
ls -ldn /work/data 2>&1 || true
# Tambien asegura que el binario sea del app user (por si la imagen viene con owner root)
chown -R 1001:1001 /work 2>&1 || true
chmod 0755 /work /work/application 2>&1 || true
echo "[entrypoint] dropping to UID 1001 via setpriv"
exec setpriv --reuid=1001 --regid=1001 --init-groups -- /work/application "$@"