prole/docs/k3d.md
chrisfu b905cbe584 Bootstrap env-based prole.cfg entrypoint (safe legacy migration)
- Add centralized config resolver/activator with per-environment layering and stable symlink entrypoint\n- Bootstrap missing env dirs and preserve non-symlink legacy prole.cfg by seeding into inferred env\n- Wire installer UI/backend + shell helpers to shared resolution path for explicit, safe env switching\n- Harden k3d: registry network/DNS wiring and ArgoCD repo-server hostPath permission init\n- Add docs + regression tests for env switching, namespace stability, k3d registry, and ArgoCD rollout

Co-authored-by: Junie <junie@jetbrains.com>
2026-03-13 12:23:15 -07:00

952 B

k3d notes

ArgoCD repo-server: copyutil ... Permission denied

If ArgoCD deploy appears to stall on argocd-repo-server and logs show:

copyutil /bin/cp: cannot create regular file '/var/run/argocd/argocd': Permission denied

This is usually a hostPath permission issue.

Why it happens

In k3d, hostPath volumes refer to paths on the k3d node containers' filesystems. When a manifest uses hostPath.type: DirectoryOrCreate, Kubernetes creates the directory on the node as root:root with restrictive permissions.

ArgoCD runs argocd-repo-server and its init containers as a non-root user by default, so an init container like copyutil cannot write to /var/run/argocd unless the volume path is writable.

How Prole avoids the stall

The Prole ArgoCD manifest includes an init-permissions initContainer (running as root) which prepares/chowns the hostPath-backed mount points before the non-root init containers run.