Setup & configAlways fixable

Fix 'detected dubious ownership in repository'

Git says 'detected dubious ownership in repository' — how do I fix it?

If you’re seeing this error

fatal: detected dubious ownership in repository at '<path>'

To add an exception for this directory, call: git config --global --add safe.directory <path>

You’re in the right place — the fix is below.

Short answer

Git 2.35.2 added a security check that refuses to run in a repository owned by a different user. Add the path to safe.directory and the error goes away: git config --global --add safe.directory /path/to/repo. On your own single-user machine that is entirely reasonable; on a shared box, work out why the ownership is wrong before you silence the warning.

quick fix

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

Trust one specific repository — Git even prints this line for you

Does this match your situation?

'fatal: detected dubious ownership in repository at ...'
Git works in a terminal but fails inside Docker, WSL, a dev container or a CI runner.
The repository sits on an external drive, a network share or a mounted Windows folder.
It started happening after a Git upgrade, with no change to the project.

Step-by-step fix

Trust the one repository
Git prints the exact command in the error text. Adding the path writes it to your global config, so the check passes for that repository and stays in force everywhere else.
step 1
```
git config --global --add safe.directory /path/to/repo
git config --global --get-all safe.directory
```
Show the Windows / PowerShell version
Windows / PowerShell
```
git config --global --add safe.directory 'C:/projects/myrepo'
# Git wants forward slashes here, even on Windows
```
Or fix the ownership, which is the real repair
The check fires because the folder belongs to a different user than the one running Git. If that is not deliberate — say, files created by root or by an earlier install — correcting the owner is better than adding an exception.
step 2
```
ls -ld /path/to/repo
sudo chown -R "$(id -u):$(id -g)" /path/to/repo
```
Show the Windows / PowerShell (run as admin) version
Windows / PowerShell (run as admin)
```
takeown /f C:\projects\myrepo /r /d y
icacls C:\projects\myrepo /grant "$env:USERNAME:(F)" /t
```
Containers and CI: trust everything, deliberately
Inside a throwaway container the user IDs rarely line up with the mounted files, and listing every repository is impractical. The wildcard turns the check off wholesale — acceptable in an ephemeral, single-tenant environment, and a poor idea on a shared machine.
step 3
```
git config --global --add safe.directory '*'
```
The wildcard disables a real security control. Use it in containers and CI images, not on a machine other people log into.
Fix it for every user on the machine
A global setting belongs to one user account. Services, scheduled tasks and CI agents run as somebody else and will hit the same error, so those need the system-level config instead.
step 4
```
sudo git config --system --add safe.directory /path/to/repo
```
Undo it later
Exceptions accumulate. Removing one is a single command, and listing them occasionally is worth doing.
step 5
```
git config --global --unset-all safe.directory /path/to/repo
git config --global --get-all safe.directory
```

Why this works

The check exists because of CVE-2022-24765. A repository's own .git/config can name commands Git will execute — core.fsmonitor, core.pager, hooks paths — so simply running git status inside a directory somebody else controls was enough to run their code as you. That is a genuine privilege-escalation route on any shared machine, and on Windows it applied to writable directories like C:\ that any user could plant a repository in. Git's answer was to refuse outright when the repository owner is not the current user, and to make the exception explicit. safe.directory is deliberately not readable from the repository itself, for the obvious reason: an attacker could otherwise mark their own repository as safe.

If that didn’t work

Use forward slashes in the path on Windows, and match Git's spelling exactly — including the drive letter.
WSL accessing /mnt/c often needs the wildcard, since Windows ownership does not map onto Linux UIDs.
In Docker, run as the same UID as the host files (--user $(id -u):$(id -g)) instead of adding exceptions.
For a bare repository ending in .git, add the exact path Git names in the error, .git suffix included.

How to stop it happening again

Do not run git commands with sudo — it makes root the owner of new files and causes this for everything afterwards.
Keep repositories inside your own home directory rather than on shared system paths.
In container images, set safe.directory once during the build rather than in every job.
Match container UIDs to host UIDs on bind mounts so ownership lines up naturally.

Commands used in this guide

git config

Read and write Git settings for one repo, your user, or the whole machine.

git status

Show what's changed, what's staged, and what Git is ignoring.

git clone

Copy a remote repository, its full history and its branches, onto your machine.

git init

Turn the current folder into a Git repository.

git help

Open the full manual for any Git command.

Still stuck?

Search the full command reference and every other rescue guide — there are 76 of them, covering everything from detached HEAD to force-push disasters.

Browse all guides →

Frequently asked questions

What does 'detected dubious ownership in repository' mean?

The repository's directory is owned by a different user than the one running Git. Since 2.35.2 Git refuses to operate there, because a repository you do not own can contain config that executes commands as you — the vulnerability tracked as CVE-2022-24765.

Is it safe to run git config --global --add safe.directory '*'?

On a machine only you use, or inside a disposable container, it is a pragmatic choice. On a shared server or a multi-tenant build host it is not: you are re-enabling the exact attack the check was added to stop, where another user's repository can run commands under your account.

Why do I only get this inside Docker or WSL?

Because the user ID inside the container or the WSL distribution does not match the owner of the mounted files, so Git sees a repository belonging to somebody else. Running the container as your host UID fixes it properly; safe.directory silences it.

Why does my CI job still fail after I added safe.directory?

The setting is per-user, and CI steps often run as root or as a dedicated agent account rather than the one you configured. Add it with --system, or set it in the step that actually runs the failing command.

How do I list or remove safe.directory entries?

git config --global --get-all safe.directory lists them; git config --global --unset-all safe.directory <path> removes one. They accumulate quietly over time, so it is worth reviewing the list occasionally.

Related rescue guides

Always fixable

Git says 'not a git repository (or any of the parent directories): .git' — what does that mean?

You are standing somewhere Git does not consider a repository. Run pwd and ls -a: if there is no .git folder here or in any parent, either cd into the project, or run git init to create one. If .git used to be here and has vanished, the repository is not broken so much as missing — check whether you deleted it or are in a copied folder.

Read the fix →Always fixable

← All Git Rescue guides

Fix 'detected dubious ownership in repository'

Git says 'detected dubious ownership in repository' — how do I fix it?

If you’re seeing this error

Does this match your situation?

Step-by-step fix

Trust the one repository

Or fix the ownership, which is the real repair

Containers and CI: trust everything, deliberately

Fix it for every user on the machine

Undo it later