How to fix fatal: unsafe repository ('/path/to/repo' is owned by someone else) in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 398 views

The 'unsafe repository' error occurs when Git detects that the repository is owned by a different user than the one running Git commands. This security feature was introduced in Git 2.35.2 to prevent CVE-2022-24765, which could allow malicious code execution.

Quick fix

Fixes CVE-2022-24765

# Add a single repository to safe.directory (recommended)
git config --global --add safe.directory /path/to/your/repo

# Example for a specific project
git config --global --add safe.directory /home/otheruser/projects/myrepo

# On Windows (use forward slashes or escaped backslashes)
git config --global --add safe.directory "C:/Users/OtherUser/projects/myrepo"
git config --global --add safe.directory "C:\\Users\\OtherUser\\projects\\myrepo"
  1. Add the repository to Git's safe.directory list
  2. Trust all repositories (use with caution)
  3. Change ownership of the repository (preferred solution)
  4. Fix for Docker containers
git — error
# Add a single repository to safe.directory (recommended)
git config --global --add safe.directory /path/to/your/repo
# Example for a specific project
git config --global --add safe.directory /home/otheruser/projects/myrepo
# On Windows (use forward slashes or escaped backslashes)
git config --global --add safe.directory "C:/Users/OtherUser/projects/myrepo"
git config --global --add safe.directory "C:\\Users\\OtherUser\\projects\\myrepo"
fatal: unsafe repository ('/path/to/repo' is owned by someone else)

What this error means

This error is a security feature introduced in Git 2.35.2 (April 2022) to protect against CVE-2022-24765, a vulnerability that could allow malicious actors to execute arbitrary commands through specially crafted Git repositories. When you run a Git command, Git searches for a `.git` directory starting from the current directory and moving upward through parent directories. Before this security fix, an attacker with write access to a shared machine could create a malicious `.git` directory in a common location (like `C:\` on Windows or `/tmp` on Linux), causing Git to load malicious configuration when unsuspecting users ran Git commands. The security check compares the ownership of the directory containing the `.git` folder against the user executing Git commands. If they don't match, Git refuses to operate on the repository and displays this "unsafe repository" error. This commonly happens in legitimate scenarios: - Running commands in Docker containers where files are mounted from the host - Working with repositories on network shares or external drives - Using WSL (Windows Subsystem for Linux) with Windows-mounted directories - CI/CD pipelines running as different users than repository owners - sudo or administrative operations on repositories owned by regular users

Typical symptoms

  • Git commands fail with 'fatal: unsafe repository' message
  • VS Code, IntelliJ, or other IDEs show 'dubious ownership' warnings
  • Git operations work for one user but fail for another on the same machine
  • Docker containers cannot access mounted Git repositories
  • CI/CD pipeline fails with ownership errors after Git upgrade
  • Git Bash on Windows shows error for repositories on mapped drives
  • WSL cannot access Git repositories stored on Windows filesystem

Common causes

  1. Repository is owned by a different user than the one running Git (most common)
  2. Docker container runs as different user than host filesystem owner
  3. WSL accessing repositories on Windows NTFS filesystem via /mnt
  4. Running Git commands with sudo when repo is owned by regular user
  5. Network-mounted filesystems (NFS, SMB) with different user mappings
  6. CI/CD runners using different service accounts than repository creators
  7. Cloning repositories to shared directories with different ownership
  8. External drives or USB storage with different filesystem permissions

How to fix "fatal: unsafe repository ('/path/to/repo' is owned by someone else)"

1Add the repository to Git's safe.directory list

The quickest fix is to explicitly tell Git to trust this specific repository:

bash
# Add a single repository to safe.directory (recommended)
git config --global --add safe.directory /path/to/your/repo

# Example for a specific project
git config --global --add safe.directory /home/otheruser/projects/myrepo

# On Windows (use forward slashes or escaped backslashes)
git config --global --add safe.directory "C:/Users/OtherUser/projects/myrepo"
git config --global --add safe.directory "C:\\Users\\OtherUser\\projects\\myrepo"

This adds an entry to your ~/.gitconfig file:

ini
[safe]
    directory = /path/to/your/repo

Note: You need to run this command for each repository you want to trust, or use the wildcard option in the next step.

2Trust all repositories (use with caution)

If you frequently work with repositories owned by other users and understand the security implications, you can trust all directories:

bash
# Trust all repositories (less secure, but convenient)
git config --global --add safe.directory '*'

Security Warning: This disables the ownership check entirely. Only use this on:
- Personal development machines where you're the only user
- Isolated Docker containers with no untrusted code
- Secure CI/CD environments

NOT recommended for:
- Shared servers or multi-user systems
- Production environments
- Systems where others can create directories

To remove this later:

bash
git config --global --unset-all safe.directory
3Change ownership of the repository (preferred solution)

If you own the machine and the repository should belong to you, fixing the ownership is the cleanest solution:

On Linux/macOS:

bash
# Change ownership to current user
sudo chown -R "$USER":"$(id -gn)" /path/to/repo

# Or specify user explicitly
sudo chown -R username:groupname /path/to/repo

# Verify ownership
ls -la /path/to/repo

On Windows (Command Prompt as Administrator):

cmd
takeown /f "C:\path\to\repo" /r /d Y
icacls "C:\path\to\repo" /grant "%USERNAME%":F /T

On Windows (PowerShell as Administrator):

powershell
$path = "C:\path\to\repo"
$acl = Get-Acl $path
$identity = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule($identity, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.SetAccessRule($rule)
Set-Acl -Path $path -AclObject $acl
4Fix for Docker containers

Docker containers typically run as root or a specific user, while mounted volumes retain the host's file ownership. Here are several solutions:

Option 1: Add safe.directory in Dockerfile or entrypoint:

dockerfile
# In Dockerfile
RUN git config --global --add safe.directory /app

# Or for any directory
RUN git config --global --add safe.directory '*'

Option 2: Set safe.directory via environment in docker-compose:

yaml
services:
  app:
    image: myapp
    volumes:
      - .:/app
    environment:
      - GIT_CONFIG_GLOBAL=/tmp/.gitconfig
    command: >
      sh -c "git config --global --add safe.directory /app && exec your-command"

Option 3: Create .gitconfig before running container:

bash
# Create config file on host
mkdir -p /home/runner/work/_temp/_github_home
printf "[safe]\n\tdirectory = /github/workspace" > /home/runner/work/_temp/_github_home/.gitconfig

# Mount it in container
docker run -v /home/runner/work/_temp/_github_home:/root .gitconfig:/.gitconfig myimage

Option 4: Match container user to host user:

bash
# Run container as current user
docker run --user "$(id -u):$(id -g)" -v "$PWD:/app" myimage
5Fix for GitHub Actions and CI/CD

GitHub Actions and other CI systems often encounter this when using custom Docker containers or specific checkout configurations.

For GitHub Actions:

yaml
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4  # Use latest version

      - name: Configure Git safe directory
        run: git config --global --add safe.directory "$GITHUB_WORKSPACE"

      # Your build steps...

For Docker-based GitHub Actions:

yaml
jobs:
  build:
    runs-on: ubuntu-latest
    container:
      image: node:18
    steps:
      - name: Configure Git
        run: |
          git config --global --add safe.directory /github/workspace
          git config --global --add safe.directory '*'

      - name: Checkout
        uses: actions/checkout@v4

For GitLab CI:

yaml
before_script:
  - git config --global --add safe.directory "$CI_PROJECT_DIR"

For Jenkins:

groovy
pipeline {
    agent any
    stages {
        stage('Configure Git') {
            steps {
                sh 'git config --global --add safe.directory "$WORKSPACE"'
            }
        }
    }
}
6Fix for WSL (Windows Subsystem for Linux)

When accessing Windows filesystems from WSL, ownership appears as root, causing this error:

Option 1: Add specific directories to safe.directory:

bash
# Add your Windows project directories
git config --global --add safe.directory /mnt/c/Users/YourName/Projects/myrepo

Option 2: Configure mount options in /etc/wsl.conf:

bash
# Create or edit /etc/wsl.conf
sudo nano /etc/wsl.conf

Add these contents:

ini
[automount]
enabled = true
options = "metadata,uid=1000,gid=1000,umask=022"

Then restart WSL:

powershell
# In PowerShell (not WSL)
wsl --shutdown

Option 3: Work within the Linux filesystem (recommended for performance):

bash
# Clone repositories to Linux filesystem instead of /mnt/c
cd ~
git clone https://github.com/user/repo.git

# Linux filesystem paths start with /home, not /mnt
# This also improves Git performance significantly

Access Linux files from Windows:
- In File Explorer: \\wsl$\Ubuntu\home\username\projects
- This approach avoids permission issues entirely

7Set safe.directory at system level (for all users)

On shared systems where all users need access to specific repositories, configure at the system level:

bash
# System-wide configuration (requires root/admin)
sudo git config --system --add safe.directory /shared/repo

# View system config location
git config --system --list --show-origin

Typical system config locations:
- Linux: /etc/gitconfig
- macOS: /usr/local/etc/gitconfig or $(brew --prefix)/etc/gitconfig
- Windows: C:\Program Files\Git\etc\gitconfig

Create a startup script for CI runners:

bash
#!/bin/bash
# /etc/profile.d/git-safe.sh
git config --global --add safe.directory '*'

Note: System-level configuration affects all users on the machine. Be cautious about disabling security checks system-wide.

8Verify and troubleshoot the fix

After applying a fix, verify it's working:

bash
# Check if repository is now accessible
git status

# List all safe.directory entries
git config --global --get-all safe.directory

# Show full configuration with file locations
git config --list --show-origin | grep safe

# Check who owns the repository
ls -la /path/to/repo
stat /path/to/repo

# Check current user
whoami
id

If still not working:

1. Check for multiple config files:

bash
git config --list --show-origin

2. Verify the exact path (no trailing slash):

bash
# Wrong
git config --global --add safe.directory /path/to/repo/

# Correct
git config --global --add safe.directory /path/to/repo

3. On Windows, try both path formats:

bash
git config --global --add safe.directory "C:/path/to/repo"
git config --global --add safe.directory "C:\\path\\to\\repo"

4. Remove and re-add:

bash
git config --global --unset-all safe.directory
git config --global --add safe.directory /path/to/repo

Advanced notes

### Understanding CVE-2022-24765

This vulnerability allowed attackers to execute arbitrary commands when a user ran Git in a directory with a malicious .git folder created by another user. The attack vector:

1. Attacker creates /.git or C:\.git with malicious hooks or config
2. Victim runs git status in any subdirectory
3. Git traverses up, finds the malicious .git, and executes hooks

The safe.directory check prevents Git from using .git directories owned by other users.

### Alternative Workaround: GIT_CEILING_DIRECTORIES

Instead of safe.directory, you can limit how far Git searches upward:

bash
# Prevent Git from searching above home directory
export GIT_CEILING_DIRECTORIES="$HOME"

# Or for Windows
export GIT_CEILING_DIRECTORIES="/c/Users/YourName"

# Add to shell profile (.bashrc, .zshrc)
echo 'export GIT_CEILING_DIRECTORIES="$HOME"' >> ~/.bashrc

### Network Filesystems (NFS, SMB/CIFS)

Network mounts often cause ownership mismatches:

NFS with user mapping:

bash
# In /etc/exports (server side)
/shared/repos client(rw,all_squash,anonuid=1000,anongid=1000)

SMB/CIFS mount with uid/gid:

bash
# In /etc/fstab
//server/share /mnt/share cifs uid=1000,gid=1000,credentials=/root/.smbcredentials 0 0

### Git Version-Specific Behavior

- < 2.35.2: No ownership check
- 2.35.2+: Ownership check enabled, safe.directory introduced
- 2.36.0+: Better error messages and Windows path handling
- 2.38.0+: Improved WSL and Docker support

Check your version:

bash
git --version

### Downgrading Git (Not Recommended)

If you need to temporarily work around this on a secure, isolated system:

bash
# Debian/Ubuntu - find available versions
apt-cache policy git

# Install specific older version (not recommended)
sudo apt install git=1:2.34.1-1ubuntu1

Warning: Downgrading exposes you to CVE-2022-24765. Only do this temporarily on isolated systems.

### Dev Containers and VS Code

For VS Code Dev Containers, add to devcontainer.json:

json
{
  "postCreateCommand": "git config --global --add safe.directory ${containerWorkspaceFolder}"
}

Or in the Dockerfile:

dockerfile
RUN git config --system --add safe.directory '*'

### Security Best Practices

1. Prefer changing ownership over adding to safe.directory
2. Use specific paths instead of wildcard *
3. Audit safe.directory entries periodically:

bash
git config --global --get-all safe.directory

4. Remove entries when no longer needed:

bash
git config --global --unset safe.directory /old/path

5. On shared systems, never use safe.directory = *

Frequently asked questions

What does "CVE-2022-24765" mean?
2 (April 2022) to protect against CVE-2022-24765, a vulnerability that could allow malicious actors to execute arbitrary commands through specially crafted Git repositories. git directory starting from the current directory and moving upward through parent directories. git directory in a common location (like C:\ on Windows or /tmp on Linux), causing Git to load malicious configuration when unsuspecting users ran Git commands.
How do I fix "CVE-2022-24765"?
The 'unsafe repository' error occurs when Git detects that the repository is owned by a different user than the one running Git commands. This security feature was introduced in Git 2.35.2 to prevent CVE-2022-24765, which could allow malicious code execution.
What causes "CVE-2022-24765"?
Repository is owned by a different user than the one running Git (most common) Docker container runs as different user than host filesystem owner WSL accessing repositories on Windows NTFS filesystem via /mnt
Is the "CVE-2022-24765" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading