The ProblemYou go to run a quick git status or git pull, but instead of the usual output, your terminal throws a curveball. Git suddenly refuses to work, displaying a frustrating security warning:
fatal: detected dubious ownership in repository at '/Users/username/project'
This usually happens right after a Git update or when you're jumping between local development and Docker containers. It’s a total workflow killer that prevents you from committing, pushing, or even checking which branch you're on.
The Root CauseThis isn't a random bug. It is a deliberate security measure. Back in April 2022, the Git team released a patch (v2.35.2) to close a vulnerability known as CVE-2022-24765.
On shared systems, a bad actor could create a .git folder in a parent directory they own. If you ran a Git command in a subdirectory, Git might accidentally execute code using your high-level permissions. To stop this, Git now verifies that the person running the command actually owns the repository folder. If there is a mismatch, Git locks the door.
On macOS, you'll likely hit this wall if:
- Docker Mismatches: You're working inside a container where the user is
root(UID 0), but your Mac user ID is501.- Migration: You migrated files from an old Mac using Time Machine or a Migration Assistant.- External Drives: Your project sits on a drive formatted with FAT32 or ExFAT, which doesn't handle Unix permissions well.## Step-by-Step Solutions### Solution 1: Trust the Specific Directory (Best Practice)If you know the repository is safe, tell Git to ignore the ownership check for this specific path. This is the cleanest fix because it doesn't lower your security settings for the rest of your system. Copy the path from your error message and run:
git config --global --add safe.directory /Users/username/project
Pro tip: If your folder name has spaces, like /Users/work/My Project, make sure to wrap the entire path in quotes.
Solution 2: The "Global Trust" ShortcutAre you seeing this error on dozens of different projects? This is common for developers who rely heavily on Docker Compose. Rather than adding every single folder manually, you can tell Git to trust every directory on your machine.
git config --global --add safe.directory '*'
Use this with caution. By using the '*' wildcard, you are essentially opting out of the security fix Git implemented in 2022. Only do this if you are the sole user of your machine.
Solution 3: Reclaim Folder OwnershipIf the project is strictly local, the best long-term fix is to ensure your macOS user actually owns the files. This aligns the filesystem permissions with Git's expectations.
sudo chown -R $(whoami) /Users/username/project
This command recursively changes the owner of the folder to your current logged-in user. It’s a one-time fix that usually solves the problem without needing to touch your Git config.
How to Verify the FixAfter applying one of the steps above, test it by running a basic command:
git status
If you see your staged changes and branch name, you're good to go. To see a list of all directories you've currently marked as safe, run:
git config --global --get-all safe.directory
Summary of Key TakeawaysSecurity updates can be annoying, but they exist for a reason. When troubleshooting ownership on macOS, keep these points in mind:
- Check your UIDs: Remember that Docker often operates as UID 0, while your Mac user is likely 501. This 501 vs 0 conflict is the #1 cause of this error.- Be Specific: Try to use Solution 1 whenever possible. It’s better to have a long list of safe directories than to leave the door wide open with a wildcard.- Trailing Slashes: Git is picky. Ensure the path in your
safe.directoryconfig matches the error message exactly, character for character.