Technology · PRACTICAL GUIDE
Git “detected dubious ownership”: verify the owner boundary before adding safe.directory
Treat the fatal message as an identity mismatch, not a nuisance warning. Check the Git process user, repository owner, mount path and configuration scope before granting one narrow exception.
Git refuses to read repository configuration when a working tree is owned by another identity unless that path is explicitly trusted. The safe fix is to prove which user runs Git and which user owns the canonical repository path, repair accidental ownership, and add only one exact exception when sharing is intentional.
1. Capture the failing identity and canonical path
Run the same Git command in the same shell, service, container or CI step that fails. Record the effective user, the exact path printed by Git and the canonical working-tree path. On Unix-like systems, compare id -u and id -g with ownership for the repository and every parent directory; on Windows, inspect the owner SID from the same Git client context. Do not assume an interactive shell, a GUI, sudo, a service and a container share one identity or one configuration file.
2. Classify the mismatch before changing anything
There are three materially different cases. First, ownership is accidentally wrong after a restore, administrator clone, disk move or root-run build; correct the owner or run Git as the intended user. Second, ownership is intentionally different because a repository is shared; preserve the owner and create one exact exception. Third, the filesystem boundary reports misleading or unstable metadata, as a recent Docker Desktop bind-mount-root case demonstrated; collect repeated ownership evidence and test a nested path or parent-directory mount before treating trust configuration as the root cause.
3. Check which configuration the failing process actually reads
A safe.directory written with --global is stored for the user running that command. It will not help a different service account, container user or CI process that reads another home directory. Use git config --show-origin --get-all safe.directory in the failing context to see the effective entries and their files. Use system scope only when administrators deliberately want a machine-wide policy. Because the setting is honored only in protected configuration, a repository cannot mark itself safe from its own local config.
4. Apply the narrow repair
If the owner is accidental, change only the repository tree to the intended account and verify the result; do not recursively loosen permissions on unrelated parents. If sharing is intentional, add the canonical repository path as one safe.directory value for the identity that runs Git. Quote paths correctly for the active shell. Avoid the wildcard value *: Git documents it as a complete opt-out that treats every repository as safe. A directory ending in /* also trusts every repository below it, so use it only for a deliberately controlled shared root.
5. Retest the real operation, including nested repositories
Repeat git status and the original failing command as the original process user. Then inspect submodules, worktrees or nested repositories separately, because each path can cross a different owner boundary. A successful command is not enough if the test accidentally ran as root or under another home directory; confirm the effective identity and show-origin output again. Remove stale or wildcard entries once a narrow path works, and keep a short record of why intentional shared ownership is trusted.
Why the warning deserves respect
The ownership traversal rule followed CVE-2022-24765. GitHub explained that an attacker on a multi-user system could place a parent .git directory so Git would read configuration capable of invoking commands. Modern Git therefore stops when repository discovery crosses an ownership boundary unless the path is explicitly trusted. That is why the right question is not “How do I silence this?” but “Which identity owns this path, why is that expected, and how narrow can the exception be?”
