Victor's room

Executive Summary & Root Cause Analysis: The error fatal: detected dubious ownership in repository at '...' was introduced in Git 2.35.2 as a security mitigation for CVE-2022-24765. When you execute a Git command inside a directory owned by a different OS user than the current effective user, Git refuses to read the local .git/config or hooks to prevent arbitrary code execution on shared systems. Common triggers include: (1) mounting host directories into Docker containers running as root, (2) running commands with sudo, (3) accessing Windows-hosted repositories from WSL2, and (4) self-hosted CI/CD runners operating under different service accounts.

Step 1: Quick Fix – Whitelist the Repository with safe.directory

If you trust the repository and its owner, register the directory path in your global Git configuration using safe.directory. Git typically prints the exact command to run right below the error message:

# Add the specific repository path to your global safe.directory list
git config --global --add safe.directory /path/to/your/repository

# On Windows / Git Bash, use forward slashes for the drive path:
git config --global --add safe.directory C:/projects/my-repo

If you are running Git inside a root-owned shell (such as a systemd service or sudo), pass --system instead of --global so the setting applies to all user accounts on the host:

sudo git config --system --add safe.directory /path/to/your/repository

Step 2: Fix Underlying Filesystem Ownership (Recommended for Host & WSL)

Rather than bypassing Git’s ownership check, the cleanest long-term fix on Linux, macOS, or WSL2 is aligning the directory’s filesystem owner with your current user account:

# Check current directory ownership and your active user
ls -ld /path/to/your/repository
whoami

# Recursively transfer ownership to your current user and primary group
sudo chown -R $(whoami):$(id -gn) /path/to/your/repository

For WSL2 users accessing Windows drives (/mnt/c/...), ensure your user UID owns the mounted files or move active repositories into the native Linux filesystem (e.g., ~/projects/), which also significantly improves Git I/O performance.

Step 3: Docker & CI/CD Container Workarounds

In ephemeral Docker containers or automated CI/CD pipelines where host volumes are mounted into a container running as root or a non-matching UID:

1. Allow all directories inside isolated containers using a wildcard:

   # In your Dockerfile or CI entrypoint script (Use ONLY in isolated containers)
   git config --global --add safe.directory '*'

2. Pass the host UID/GID when launching the Docker container:

   # Match the container user ID to the host directory owner
   docker run --rm -u $(id -u):$(id -g) -v $(pwd):/workspace my-image git status

3. Pass configuration inline for a single command:

   # Temporary one-off override without modifying config files
   git -c safe.directory=/path/to/your/repository status

Verification & Testing Steps

Confirm that Git recognizes the repository as safe and executes commands without ownership warnings:

# Inspect registered safe.directory entries
git config --global --get-all safe.directory

# Verify Git commands run cleanly inside the repository
cd /path/to/your/repository
git status
git log -1 --oneline

Summary Comparison Table

Resolution Method	Target Environment	Security Impact	Persistence
git config --global --add safe.directory <path>	Local dev machines & shared hosts	High (Trusts only explicit paths)	Permanent per user
sudo chown -R $(whoami) <path>	Linux, macOS, native WSL2	Highest (Fixes actual file permissions)	Permanent on filesystem
docker run -u $(id -u):$(id -g)	Local Docker bind mounts	Highest (Aligns container & host UID)	Per container run
safe.directory '*'	Ephemeral CI/CD & isolated Docker	Low (Disables check globally)	Container/User lifetime