Fix "fatal: detected dubious ownership in repository" in Git

# make it yours
sudo chown -R "$USER": /path/to/repo
# or trust this one repository
git config --global --add safe.directory /path/to/repo

The message Git prints on Linux looks like this:

fatal: detected dubious ownership in repository at '/srv/app'
To add an exception for this directory, call:

	git config --global --add safe.directory /srv/app

Newer Git versions add lines showing who owns the directory and who you are (for example '/srv/app' is owned by: ... but the current user is: ...). Very old releases said fatal: unsafe repository ('/srv/app' is owned by someone else).

What the error means

A Git repository's .git/config can make Git run programs (hooks, core.fsmonitor, pagers). If another user owns a repository you walk into, they could make Git execute commands as you. To close that hole (CVE-2022-24765), Git refuses to operate in a repository whose top directory is owned by a different user, unless you list it in safe.directory.

So the check compares the owner of the repository directory (or of .git) with your user ID:

ls -ld /srv/app /srv/app/.git
id -u

Example output:

drwxr-xr-x 8 www-data www-data 4096 Oct 12 10:41 /srv/app
drwxr-xr-x 8 www-data www-data 4096 Oct 16 09:03 /srv/app/.git
1000

The repository belongs to www-data, you are UID 1000: dubious ownership.

Cause 1: the repo was created or cloned as root (or with sudo)

The most common case: you ran sudo git clone or copied the project as root, so the files belong to root while you work as yourself. Take ownership back:

sudo chown -R "$USER": /path/to/repo

This is the cleanest fix because it also stops "permission denied" errors when Git writes to .git. The trailing colon sets the group to your login group. See file permissions explained for how ownership works.

The reverse also triggers it: running sudo git pull in a repository owned by you. Git allows this case when run through sudo (it checks SUDO_UID), but other tools that switch user, such as su or runuser, do not get that exception. Avoid running Git as root in user repositories.

Cause 2: a deployment repo owned by a service user

Web roots and deploy directories often belong to www-data, nginx, git or a deploy user. Changing the owner would break the service, so either run Git as that user, or trust that one path:

# run as the owning user
sudo -u www-data git -C /srv/app pull
# or mark it safe for your user
git config --global --add safe.directory /srv/app

Running Git as the owner is better: it keeps new files owned correctly. safe.directory is read only from system, global and command-line config, never from the repository itself, which is what makes it safe. For a system-wide exception, use sudo git config --system --add safe.directory /srv/app.

Cause 3: Docker containers and CI

Bind-mounted source trees are owned by your host UID (say 1000), while the container often runs as root (UID 0), or the other way around. CI runners such as GitHub Actions, GitLab CI and Jenkins agents hit this when the checkout step and the build step run as different users.

# inside the container or job, trust the workspace
git config --global --add safe.directory "$PWD"
# or run the container as the file owner
docker run --rm -u "$(id -u):$(id -g)" -v "$PWD":/src -w /src image git status

In disposable containers that only ever contain your own code, git config --global --add safe.directory '*' is acceptable. Do not use the wildcard on shared workstations or servers. See Docker on Linux for user mapping and rootless mode; a related permission problem is covered in Docker socket permission denied.

Cause 4: USB drives, NTFS, exFAT and network shares

FAT, exFAT and NTFS have no Unix ownership; Linux shows every file as owned by whatever the mount options say, often root. Network shares (SMB, NFS with root squashing, sshfs) can map owners unexpectedly. Options:

# check the owner reported by the mount
ls -ld /media/alice/USB/project
# remount with your UID (FAT/exFAT/NTFS)
sudo mount -o remount,uid=$(id -u),gid=$(id -g) /media/alice/USB
# or trust the path
git config --global --add safe.directory /media/alice/USB/project

In WSL, repositories under /mnt/c/ are on the Windows drive and show similar ownership problems; keep repositories inside the Linux filesystem (~/) for this and for speed.

Managing safe.directory entries

# list current exceptions
git config --global --get-all safe.directory
# remove one
git config --global --unset safe.directory /srv/app
# exceptions live here
cat ~/.gitconfig

Each entry must be the exact path of the repository's top-level directory. A trailing /* (Git 2.46 and later) trusts everything under a directory, such as /srv/repos/*.

Distro notes

The behaviour comes from Git itself, so it is identical on Ubuntu, Debian, Fedora, Arch and openSUSE once Git is 2.35.2 or newer, which all current releases ship. Check your version with git --version. Distro packages install the system config at /etc/gitconfig, which is where --system entries go. Installation and setup are covered in Git on Linux.

How to prevent it

• Clone and work in repositories as the user who will own them; never use sudo git clone into your home directory.
• For deployments, run Git as the service's deploy user (sudo -u deploy git ...).
• In containers, run as your host UID or add safe.directory in the image or job setup.
• Keep working copies on native Linux filesystems.

Everyday Git commands are collected in the Git commands cheat sheet.

Frequently asked questions