fatal: detected dubious ownership in repository at '[path]'

TL;DR

git refuses to run because the repository directory is owned by a different user than the one running git. Trust the repo once and move on:

git config --global --add safe.directory /path/to/the/repo

Re-run the original git command; it should work now. This guard is a real security feature (CVE-2022-24765), so only trust repos you actually control.

Verbatim error

fatal: detected dubious ownership in repository at '/path/to/the/repo'
'

(The trailing quote is a shell quirk of the error print; ignore it.)

Fix it

Step 1: confirm you own the directory

whoami && ls -ld /path/to/the/repo

Expected: the owner printed by ls differs from the user running git. Common causes: the repo was cloned by root, copied from another user, or is a Docker bind mount that shows up as root-owned inside the container.

Step 2: add the repo to git's safe list

git config --global --add safe.directory /path/to/the/repo

Expected: no output, exit code 0. Verify it stuck:

git config --global --get-all safe.directory

Expected output lists the path you just added:

/path/to/the/repo

Step 3: re-run the original command

git status

Expected: normal git status output instead of the fatal error.

When this applies

• git errors with "dubious ownership" in Docker containers with bind mounts (the classic: files owned by root, container runs as a different user).
• CI runners where the workspace was created by a different user (root in the runner image, job user at runtime).
• You ran sudo for a clone and now use git as a normal user.
• Repos copied or rsynced from another user or machine without preserving the working directory ownership.

When it does NOT apply

• The repo sits on a machine with multiple users and you do not trust whoever owns .git; an untrusted .git can contain malicious hooks and config. Inspect .git/config and .git/hooks first.
• You only need one command to run: prefer the per-invocation form instead of trusting globally:

git -c safe.directory=/path/to/the/repo status

• Actual permission errors (e.g. "Permission denied" on .git/objects): that is a file-permission problem, not this one.

Version compatibility

• git 2.35.2 and later enforce the ownership check.
• git 2.36.2 and later also accept a * wildcard (safe.directory='*'); avoid it on shared machines because it trusts everything.

Check your version with git --version.

Variant phrasings

The message is identical across platforms; only the path changes:

• Windows: fatal: detected dubious ownership in repository at 'C:[HOME]/...'
• Docker: the container path, e.g. /app or /workspace, owned by root
• CI: the runner workspace path, owned by the image build user

Why it happens (root cause)

Git fixed CVE-2022-24765 by refusing to read .git metadata it does not trust. The .git directory can hold executable hooks and config that git would honor; if another user owns it, running git commands could execute that user's code. The ownership check forces you to opt in per repository via safe.directory.

Edge cases

• Dockerfiles: bake the trust into the image (RUN git config --global --add safe.directory /app) or set it at container start for one-off containers.
• The wildcard `:** git config --global --add safe.directory '*'` works on git 2.36.2+, but on a shared host it disables the protection for every repo. Prefer listing paths.
• sudo users: each user has their own global config; a trust you add as root does not cover your normal user. Add it as the user who runs git.
• System-wide trust: admins can set safe.directory in the system config (git config --system --add safe.directory [path]) instead of per-user.