Problem: "detected dubious ownership in repository" — every git command fails —— Trove problem library

What you will run into

Any git command on a repo (git status / git log / git pull...) fails immediately with fatal: detected dubious ownership in repository at '<path>', and git even suggests git config --global --add safe.directory <path>.

The repo opens fine and files are all there, but every git command is dead.

Most common: dual-boot Ubuntu mounting a Windows NTFS drive, repos copied via USB/external drive, WSL accessing the Windows side, or repos created by root/sudo — the repo files' owner doesn't match the current logged-in user.

Why this happens

dubious ownership is a trust-boundary check added in git 2.35.2. Before operating on a repo, git verifies that the owner of the repository root matches the current user (or a group the user belongs to), and refuses otherwise.

It defends against CVE-2022-24765-style attacks: an attacker places a .git/config in a directory you can nominally write, then uses custom hooks (core.hooksPath / aliases) to execute arbitrary commands in your environment.

Common sources of owner mismatch:

Owner mismatch is not a permission problem. On filesystems without POSIX ownership (NTFS/exFAT), every file shows the mount owner (often root), so any non-root user triggers it.

Deterministic takeaway: on dubious ownership, first run ls -ld <repo> to see the owner. For a trusted single-user environment, declare trust explicitly with git config --global --add safe.directory <path> — that is an "I confirm this directory is safe" statement, not a disabled check.

For shared multi-user directories, fix the owner instead of piling up safe.directory entries. On mount drives chown is ineffective, so safe.directory is the only real fix.

Step by step

1. safe.directory whitelist (most universal) — Required

git config --global --add safe.directory <absolute repo path>

With many repos you can use git config --global --add safe.directory '*' to trust everything (convenient but trusts all directories; not recommended on shared machines).

2. chown the owner (Linux filesystems only) — Required

sudo chown -R $(id -u):$(id -g) <repo path>

Ineffective on NTFS/exFAT mounted drives (the article author measured it as ineffective); use option 1 or 3 for mounted drives.

3. Fix the dual-boot NTFS mount at the source — Required

Edit /etc/fstab and add uid=1000,gid=1000 to the mount entry (replace 1000 with what id <username> reports), then reboot; or in the Ubuntu disks tool, turn off default mount options and add the same uid/gid in the mount parameters.

Every repo on the drive then naturally has consistent ownership.

4. Just want a quick look — Required

Read the files directly without running git commands; or re-clone the repo into your own directory (a fresh clone is owned by you).

How to confirm it works

After the whitelist, git commands work again (measured output shape):

nobody user git status/log → exit 0 (after whitelist, measured)
chown then access without whitelist → success (chown works on Linux filesystems, measured)

Control group: the whitelist only covers registered directories — a new sub-repo inside a registered directory still errors (registered one by one, not recursive, measured).

Other environments

Symptom

Any git command on a repository (git status / git log / git pull ...) fails with:

fatal: detected dubious ownership in repository at '<absolute repo path>'
To add an exception for this directory, call:

	git config --global --add safe.directory <absolute repo path>

Signs: the repo opens fine and files are all there, but every git command fails; the path named in the error is the repo root. Most common in: dual-boot Ubuntu mounting a Windows NTFS drive, repos copied from USB/external drives, WSL accessing Windows-side directories, or repos created by root/sudo — anywhere the repo files are owned by a different user than the current one.

Cause

Since git 2.35.2, git refuses to run in repositories whose top-level directory is owned by a user other than the current one (security hardening for CVE-2022-24765 and similar malicious-repo attacks): a crafted .git/config with custom command hooks must not be trusted in another user's context. Common sources of owner mismatch:

1. NTFS/exFAT mounts: the filesystem has no POSIX ownership, so every file appears owned by the mounting user (often root) and chown has no effect — the typical dual-boot case;
2. Shared directories: a repo created by another user (or root) that you access directly;
3. USB/copied archives: files keep the original machine's uid/gid, which doesn't match the current one.

Solution

In recommended order:

1. safe.directory whitelist (most universal, works on mounts): run exactly what the error suggests — git config --global --add safe.directory <absolute repo path>. Note the whitelist is per-directory, not recursive: other repos on the same drive need their own entry. If you have many repos, git config --global --add safe.directory '*' trusts everything (convenient, but not recommended on shared machines).
2. chown the repo (Linux filesystems only): sudo chown -R $(id -u):$(id -g) <repo path>. Ineffective on NTFS/exFAT mounts (verified ineffective by the source author) — use option 3 or 1 there.
3. Fix the dual-boot NTFS mount at the source: make the whole drive owned by your user. Add uid=1000,gid=1000 (replace 1000 with the value from id <username>) to the mount options in /etc/fstab and reboot; or in Ubuntu's Disks tool, turn off default mount options and add the same uid/gid. Every repo on the drive then has a consistent owner.
4. For a quick look only: read files directly without git, or re-clone the repo into your own directory (a fresh clone is owned by you).