Q: Your team hardened an application Dockerfile to run as non-root user `appuser` (UID 1000). When developers run `docker run -v $(pwd)/data:/data my-app`, the container crashes immediately with `EACCES: permission denied, open '/data/app.log'`. On the host, the mounted directory is owned by host root or another user ID. When an engineer added `RUN chown -R 1000:1000 /data` to an entrypoint script, production startup hung for 12 minutes because the volume contained 500GB of files. You must implement a clean, production-grade permission reconciliation pattern.

Docker bind mounts and named volumes inherit the filesystem permissions and numeric UID/GID from the host OS. If host directory `/opt/data` is owned by UID 0 (root) with mode `755`, a container running as `USER 1000` will be denied write access (`EACCES`) by the Linux VFS kernel layer.

# Inspect host directory permissions
ls -ld /opt/data
# Output: drwxr-xr-x 2 root root 4096 ... /opt/data (Owner is UID 0)

# Container fails because UID 1000 does not match UID 0 and lacks write permission

Executing `chown -R appuser:appuser /data` in an entrypoint script requires running the entrypoint as root, and more critically, it forces the kernel to read and update metadata for every single file in the volume. On large volumes with millions of files, this causes severe I/O thrashing and multi-minute boot delays.

# Broken Entrypoint Anti-pattern:
# #!/bin/sh
# chown -R 1000:1000 /data  <-- Freezes container startup on large volumes!
# exec su-exec appuser "$@"

Use `gosu` (written in Go) instead of `sudo` or `su`. Unlike `su`, `gosu` uses `execvp` to replace the calling shell with the target process, preserving PID 1 status, environment variables, and TTY signal handling.

# entrypoint.sh using gosu
#!/bin/sh
set -e

# Check if ownership is mismatched and fix ONLY the top-level directory
if [ "$(stat -c '%u' /data)" != "1000" ]; then
    echo "Adjusting ownership of /data mount point..."
    chown 1000:1000 /data
fi

# Drop privileges to UID 1000 and execute application command
exec gosu 1000:1000 "$@"

In Kubernetes, avoid in-container chown altogether. Use `fsGroup: 1000` in the Pod's `securityContext`, which instructs the kubelet to set group ownership at mount time, or use `fsGroupChangePolicy: "OnRootMismatch"` so permissions are only touched if the top-level directory does not match.

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:
    fsGroup: 1000
    fsGroupChangePolicy: "OnRootMismatch"  # Prevents recursive chown on every restart
  containers:
    - name: app
      image: my-app:latest
      securityContext:
        runAsNonRoot: true
        runAsUser: 1000