Git "fatal: detected dubious ownership in repository": fix it without turning the check off
Fix Git "detected dubious ownership in repository": run Git as the owner, fix the ownership, or trust one path with safe.directory, on servers, Docker and CI.
by OhSudo ·
Part of a learning path:Git for everyday work
A git pull that always worked suddenly stops:
$ git pullfatal: detected dubious ownership in repository at '/srv/app'To add an exception for this directory, call:
git config --global --add safe.directory /srv/appThe folder belongs to another user than the one running Git. Since Git 2.35.2 (April 2022), Git refuses to work in such a repository. The reason is a security issue: a repository’s .git/config can tell Git to run programs (hooks, core.fsmonitor, editors), so a repository created by another user could make your Git — maybe running as root — execute their commands.
The message offers an exception. Sometimes that’s the right fix, but often the real problem is that Git runs as the wrong user.
TL;DR
ls -ld /srv/app /srv/app/.git # who owns the repository?whoami # who runs Git?- Run Git as the owner:
sudo -u deploy git -C /srv/app pull - Or fix the owner:
sudo chown -R deploy:deploy /srv/app - Or, if the mismatch is expected, trust that one path:
git config --global --add safe.directory /srv/app
1. Find the mismatch
drwxr-xr-x 8 deploy deploy 4096 Nov 2 09:14 /srv/appdrwxr-xr-x 8 deploy deploy 4096 Nov 2 09:14 /srv/app/.gitrootThe repository belongs to deploy, and Git runs as root. Typical ways to get there:
- Servers: the app was deployed by one user (
deploy,www-data), and someone updates it as root or with their own account. - Docker: a host folder is mounted into a container, and the user IDs inside don’t match the owner on the host.
- CI: the runner checks out code as one user and a job step (or a container) runs Git as another.
- Windows / WSL: repositories on another user’s folder, a network share or an external drive (FAT/exFAT has no owner at all).
2. Run Git as the owner (best on servers)
Files Git creates or changes stay owned by deploy, so the app keeps working, and you don’t need any exception.
Running sudo git … in your own repository also works with current Git versions: under sudo, Git accepts a repository owned by the user who ran sudo.
3. Fix the ownership
If the repository should belong to the user who runs Git, change the owner:
sudo chown -R deploy:deploy /srv/appCheck what else needs that folder first — a web server may need to read it (group permissions), and services may write into parts of it.
4. Trust one path with safe.directory
When the mismatch is expected and you trust the repository, add an exception for exactly that path, as the user who runs Git:
It’s stored in that user’s ~/.gitconfig. For all users on the machine, use sudo git config --system --add safe.directory /srv/app.
In CI and containers, add it in the job, for the checkout folder:
git config --global --add safe.directory "$GITHUB_WORKSPACE" # GitHub Actionsgit config --global --add safe.directory "$CI_PROJECT_DIR" # GitLab CIIn a Dockerfile, use the path the code is mounted at: RUN git config --system --add safe.directory /app.
Warning
git config --global --add safe.directory '*' trusts every repository on the machine — exactly what the check protects you from. It’s acceptable in a throwaway CI container that only ever sees your own code; on a shared server or your workstation, list the paths you trust.
Shell, we have a problem!
Similar, but different: error: insufficient permission for adding an object to repository database .git/objects — Git may work here, but the current user can’t write in .git; same cause (mixed owners), fixed with section 2 or 3. fatal: not a git repository (or any of the parent directories) — you’re in the wrong folder, or .git is missing.
$ ./practice.sh
Practice this in the terminal
Open the Terminal Playground with this article’s scenario loaded. It is safe and runs in your browser.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.