How to Fix Git Dubious Ownership in WSL Without Using Safe.Directory

If you’re using Git in Windows Subsystem for Linux (WSL) and you see an error like “fatal: detected dubious ownership in repository”, it can feel like a brick wall in your coding journey. Maybe you’re trying to run git status or git commit, and bam—this error stops you cold. The usual fix is to add a safe.directory exception, but what if you don’t want to just patch it over? What if you want to really fix it? In this guide, I’ll show you how to solve the “dubious ownership” problem in WSL the right way—without using safe.directory. We’ll dig into why it happens, how WSL and Windows play together (or don’t), and step-by-step ways to make it work. Let’s get started!

What’s This “Dubious Ownership” Error Anyway?

Picture this: you’re working on a cool project in WSL—a Linux-like setup inside Windows. You type a Git command, and instead of seeing your changes, you get:

fatal: detected dubious ownership in repository at '/home/user/myproject'

What’s going on? Git’s freaking out because it thinks someone else owns your project folder, not you. Starting with Git version 2.35.2, it got stricter about security. It checks who owns the repository (the folder with the .git hidden folder inside) and compares that to who’s running the Git command. If they don’t match, Git says, “Nope, this looks sketchy,” and stops.

Why Does This Happen in WSL?

WSL is awesome because it lets you run Linux commands on Windows, but it creates a weird situation. Your files might live on the Windows side (like C:\Users\You\Projects), and you access them from WSL (like /mnt/c/Users/You/Projects). Windows and Linux handle “ownership” differently:

Windows: Uses something called SIDs (security identifiers) to track who owns files.
Linux (WSL): Uses user IDs (UIDs) and group IDs (GIDs).

When Git in WSL looks at a folder owned by your Windows user, it might not recognize it as “you” because the IDs don’t line up. That’s when you hit the dubious ownership error. The usual fix is:

git config --global --add safe.directory /home/user/myproject

But that’s like putting a Band-Aid on a leaky pipe—it works, but it doesn’t fix the root problem. Let’s do it the proper way.

Why Avoid Safe.Directory?

Adding safe.directory tells Git, “Trust this folder, even if it looks weird.” It’s quick, but:

You’d have to add it for every repository.
It skips the security check, which might hide bigger issues.
It doesn’t feel like a real solution—you’re just telling Git to ignore the problem.

Instead, let’s make Git happy by matching the ownership properly. No workarounds, just fixes!

Step 1: Understand Where Your Repository Lives

First, figure out where your project folder is. In WSL, type:

pwd

This shows your current path. It might be:

/mnt/c/…: Your files are on the Windows side, mounted into WSL.
/home/user/…: Your files are in WSL’s own filesystem.

Why It Matters

If your repository is in /mnt/c, it’s on Windows, and WSL sees the Windows ownership. If it’s in /home/user, it’s in WSL’s space, and Linux ownership applies. The fix depends on this.

Quick Check

Run:

ls -ld .

In WSL, this shows the owner of your current folder. It might say youruser yourgroup. Now, check who you are:

whoami

If the folder owner doesn’t match your WSL username, that’s the problem!

Step 2: Fix Ownership for Repositories in WSL’s Filesystem

If your project is in /home/user/myproject (not /mnt/c), it’s in WSL’s own space. Here’s how to fix it.

Check the Current Owner

In your project folder, run:

ls -ld .

You might see something like:

drwxr-xr-x 1 root root ... myproject

If it says root root instead of youruser yourgroup, Git won’t trust it because you’re not root.

Change the Owner

Make yourself the owner with:

sudo chown -R $(whoami):$(whoami) .

sudo: Runs the command with superpowers.
chown: Changes ownership.
-R: Applies it to the folder and everything inside (like .git).
$(whoami): Uses your username automatically.

Run ls -ld . again—it should now show your username. Test Git:

git status

If it works, you’ve fixed it! No safe.directory needed.

Step 3: Fix Ownership for Repositories on Windows (/mnt/c)

If your repository is in /mnt/c/Users/You/Projects/myproject, it’s trickier because it’s on Windows. WSL mounts these folders, but the ownership is set by Windows, not Linux.

Why It’s Messy

Windows doesn’t use Linux-style UIDs. When WSL looks at /mnt/c, it might map your Windows user to a different UID—or even root. Git sees this mismatch and flags it as dubious.

Option 1: Take Ownership in Windows

Since WSL can’t fully control Windows permissions, fix it on the Windows side:

Open File Explorer and navigate to C:\Users\You\Projects\myproject.
Right-click the folder → Properties → Security tab.
Click Advanced.
Next to “Owner,” click Change.
Type your Windows username (e.g., “You”), click Check Names, then OK.
Check “Replace owner on subcontainers and objects” → Apply → OK.

Back in WSL, run:

ls -ld /mnt/c/Users/You/Projects/myproject

It might still look weird (like 9999 9999), but Git should recognize it as yours now. Test with:

git status

Option 2: Move the Repository to WSL

Windows file ownership can be a headache in WSL. A cleaner fix is to move your project to WSL’s filesystem:

In WSL, go to your home directory:

   cd ~

Make a new folder:

   mkdir projects

Move your repository:

   mv /mnt/c/Users/You/Projects/myproject projects/

Go to the new location:

   cd projects/myproject

Check ownership:

   ls -ld .

If it’s not you, fix it:

   sudo chown -R $(whoami):$(whoami) .

Test Git:

   git status

Now it’s fully in WSL, and ownership matches perfectly.

Step 4: Use the Right Git Installation

Here’s a sneaky issue: are you using Git from Windows or WSL? If your IDE (like VS Code) uses Windows Git but your terminal uses WSL Git, they might see ownership differently.

Check Which Git You’re Using

In WSL, run:

which git

It might say /usr/bin/git (WSL’s Git). In a Windows terminal (like Command Prompt), run:

where git

It might say C:\Program Files\Git\bin\git.exe (Windows Git).

Fix It

Stick to WSL Git: If your project is in WSL, use WSL’s Git. Install it if missing:

  sudo apt update && sudo apt install git

Match Your Tools: In your IDE, set the Git path to WSL’s Git (e.g., /usr/bin/git in VS Code settings).

Run git status again—consistency helps!

Step 5: Clone Fresh If All Else Fails

If ownership is still wonky (especially with old repositories), start over:

Back up your work:

   cp -r myproject myproject-backup

Delete the original:

   rm -rf myproject

Clone it again in WSL’s filesystem:

   cd ~/projects
   git clone <repository-url> myproject

Check ownership:

   ls -ld myproject

It should match your user. If not, fix it:

   sudo chown -R $(whoami):$(whoami) myproject

This ensures a clean slate with proper ownership.

Why This Happens in WSL

Let’s geek out for a sec. WSL bridges Windows and Linux, but they don’t always agree:

File Metadata: WSL 2 uses a virtual filesystem, but /mnt/c reflects Windows permissions.
Git’s Security Update: After a vulnerability (CVE-2022-24765), Git started checking ownership to prevent sneaky attacks.
User Mapping: WSL maps your Windows user to a Linux UID, but it’s not always perfect.

By fixing ownership directly, you align everything—no shortcuts needed.

Keeping It Fixed

Store Projects in WSL: Keep repositories in /home/user instead of /mnt/c for fewer headaches.
Avoid Root: Don’t use sudo with Git commands unless necessary—it can mess up ownership.
Check Updates: New WSL or Git versions might change how ownership works, so test after upgrades.

Wrapping Up: No More Dubious Ownership!

The “detected dubious ownership” error in Git on WSL can be annoying, but you don’t have to settle for safe.directory. By understanding where your files live, fixing ownership with chown (or Windows settings), using the right Git, and maybe cloning fresh, you can solve it for real. Now your Git commands will run like a charm, and you’ll feel like a pro. Go build something awesome—without the errors!