entrypoint.sh

#!/bin/sh
# NetCopy container entrypoint.
#
# Goal: make the obvious "docker run -v ... ghcr.io/.../netcopy" form Just Work
# regardless of how the host directories were created.
#
# Without this script, users hit one of two annoyances:
#   - Files NetCopy writes to /incoming end up owned by uid 10001 (the image's
#     default user), unreadable from the host without sudo.
#   - Passing --user "$(id -u):$(id -g)" "fixes" file ownership but breaks
#     named volumes (Docker creates the volume's mountpoint as root, and the
#     unprivileged user can't write there) and Docker-auto-created bind-mount
#     directories (same problem).
#
# What this does:
#   - Starts as root (image has no USER directive any more).
#   - Reads PUID / PGID env vars (defaults: 10001 / 10001 — the historical id).
#   - chown's /var/lib/netcopy to PUID:PGID so the dropped user can write.
#     /share and /incoming are NOT touched: they're user data, recursive
#     chown there could surprise the user (and would be slow on TBs).
#   - Drops to PUID:PGID via gosu and execs the JVM.
#
#   - If the container is launched with `--user X`, we're already X (not
#     root), can't chown anyway, and the user has explicitly opted out of
#     PUID handling. We just exec java directly. Same behaviour as the
#     pre-v0.2.7 image; the caller is responsible for ownership.

set -e

if [ "$(id -u)" -eq 0 ]; then
    PUID="${PUID:-10001}"
    PGID="${PGID:-10001}"
    # `|| true` keeps the container starting on read-only volumes (CI tests,
    # offline-disk scenarios). On a real run-time error reading the dir, the
    # JVM's own AccessDeniedException with the README hint takes over.
    chown -R "${PUID}:${PGID}" /var/lib/netcopy 2>/dev/null || true
    exec /usr/local/bin/gosu "${PUID}:${PGID}" \
        java -jar /opt/netcopy/netcopy.jar "$@"
fi

# `--user` was passed: not root, can't chown, can't gosu — just run.
exec java -jar /opt/netcopy/netcopy.jar "$@"