Since CVE-2022-24765, git refuses to operate when the repo owner differs from the current user — classic in containers, WSL, and shared mounts. The fix declares the directory safe, scoped to exactly that path.
A bind-mounted volume, a container user mismatched to the host, or files chown-ed by root: git's ownership check fires. ls -ld /path shows the owner git is complaining about.
Windows host + WSL + Docker all seeing one directory: three different uid mappings, one of which trips the check every time.
ls -ld /path/to/repo ; id # compare repo owner with current uid/gidgit config --global --add safe.directory /path/to/reposudo chown -R $(id -u):$(id -g) /path/to/repo # container: match the user in the image, or run as the right uid# git config --system --add safe.directory /workspace (in the Dockerfile) — system scope, no per-user surprisessafe.directory is an allowlist of paths git may operate on despite the ownership mismatch — it does not disable the check globally (that was deliberately made impossible). The CVE context: a malicious repo in a shared directory could execute as another user. The annoyance you see is git refusing that attack — the scoped allowlist keeps the protection for everything else.
git removed the global off switch deliberately. safe.directory accepts exact paths (or the * wildcard for all, strongly discouraged). Scope it to the mounts you actually control.
Bind mounts preserve host uid/gid numbers, but the container/WSL user maps them differently — git sees an owner that is not you. Native checkouts never mismatch.
Our most-documented failures, packaged as ready-to-ship starter kits: Docker, Kubernetes, and Terraform.
Browse the template store →One-time. Yours to modify. Instant download from the NinjaOps template store.