How to correct `git` reporting `detected dubious ownership in repository` without adding `safe.directory` when using WSL?

Question

I used git for the last few years in this context:

• Host = my laptop, windows.
• WSL enabled
• Repos live in the Linux side.
• I access them both from the Linux and the Windows side.

I can access the files in Linux either via git-bash like this (via the //wsl$/ share):

Or natively in the WSL bash terminal:

Those accesses go to the very same directory.

Error

Now it happens that if I do git status inside a repo from the windows side it gives the error fatal: detected dubious ownership in repository at:

While in the WSL-Linux it does not, for the same directory:

Since when?

It did not happen before. I've been using this setup for years. This started happening 2 days ago.

In fact, I installed a newer version of git-bash 2 days ago and I suspect the bash environment could condition this.

I work with about 100 repos, and I have found to fail in all of them which I've tried (about 10 repos). Expectedly it'll happen to those 100 repos.

None of those previously-working now-failing repos have been touched, so neither users, neither permissions have changed.

So mutating from "well" to "bad" is not in the filesystem side, must be in the git-bash side.

Problem

I don't want to just white-list it with safe.directory. I want to understand what's going on behind the scenes. Why it happens today and not 3 days ago. I want to know "what does git expect" and see how can I correct it.

Investigation so far

The users seem correct. From the linux side:

And from the windows side it also matches the hard disk and the id:

Question

How can I tell the ownership that is expected by git for it to do not complain?

Bigener

Others may disagree, but I will say this is a well-organized post and bears recognition for that fact. It is easily scannable and expresses frustration without complaining. Good job – Deficiency

Answer 1

In fact, I installed a newer version of git-bash 2 days ago and I suspect the bash environment could condition this.

I understand you installed a new version of Git for Windows, which includes Git Bash. Newer versions of Git, starting with 2.35.2 and 2.36, including Git for Windows, are stricter about directory ownership: https://github.blog/2022-04-18-highlights-from-git-2-36/#stricter-repository-ownership-checks.

When you use git from Git Bash, you use the Windows program, even if you cd to the //wsl$/ mount. Git for Windows does not have any special code to deal with the permissions of the WSL mount, so that's why you get the error. You can't fix that without modifying the Git source code.

An alternative could be to use wsl git instead of git when in Git Bash, which would then use the Linux executable.

Or, as you wrote, just use git config --global safe.directory '*' to bypass that security feature if you do not consider yourself at risk.

[Editor's Note: If you are using Windows Command Prompt, do not add single-quotes to the asterisk, i.e., git config --global safe.directory *.]

Evenson

I see. Using wsl git will not be so trivial as my wsl is configured to start in certain difectories and the overall is to provide a CLI for the GUI (for example SourceTree). I would be happy to contribute to the git source code trying to overcome the //wsl$/ by exploring more, but since I don't have the environment to compile git and also we need to patch git in a way more restrictive way that the usual pull-requests, I am affraid of trying to contribute and ending in a sterile contribution... Any tips on contributing to the git source code without too much overhead? – Bigener

I see here github.com/git/git/blame/… in line 1483 that the responsible is the result of setup_git_directory_gently_1() being GIT_DIR_INVALID_OWNERSHIP. In addition, the only places where it can be assigned inside the functions are lines 1329 and 1351 and both assignations depend on ensure_valid_ownership(), which is defined in line 1144 and in turn this one depends on is_path_owned_by_current_user(). which ends up being an alias here compat/mingw.h to is_path_owned_by_current_sid. Is it that we need to patch git? Or WSL? – Bigener

I would first start by opening an issue at github.com/git-for-windows/git/issues, with a minimal reproducer, and see what comes out of the discussion. The Git for Windows maintainer is usually very helpful and should be able to guide you. – Evenson

Thanks! This was the solution to my problem git config --global safe.directory '*' – Deficiency

+1 Key point in this answer that helped me: "Newer versions of Git... are stricter about directory ownership". I have simple release process on my own server where the live code has user owner www-data. When I'm preparing a new release, I need to make sure the files in that release are owned by me (by doing a chown) then I won't get that "dubious" error. – Undesigning

For security reasons, I would recommend git config --global --add safe.directory /the/path/to/the/project/in/question instead of wildcard – Roundy

Key point in this answer which helped me is the Editor's Note: "If you are using Windows Command Prompt, do not add single-quotes to the asterisk, i.e., git config --global safe.directory *." – Fugal

I was struggling with the same thing, until I realized that the single quotes should be removed when using git on Windows. – Pleuron

Thanks for the editor's note about no single quotes around the asterisk -- I'm a windows user :) Probably saved me major headaches and this works fine. I'm working up a presentation on pushing to Azure Dev Ops from Visual Studio and the CLI. this is a good nugget to put into the course lineup. Thanks! – Viaticum

A simple and effective solution just putting the line of code git config --global safe.directory * works well for me... – Translunar

Thanks! I changed Path to git Executable in PhpStorm to '\\wsl$\Ubuntu\usr\bin\git' and now it's working. – Darrelldarrelle

Answer 2

I suddenly ran into this issue after reinstalling Windows due to SSD upgrade with all my Git Repos on the old drive.

A recursive Take Ownership fixed it all:

UPDATE: Screenshots as requested by OP (Sorry was traveling and just got home)

Go to Security Tab of Directory or File Properties and click Advanced

Click on CHANGE button on the Owner row

Enter your Username and click CHECK NAME. Note in Windows Username by default is your "Username" minus last character. eg. Johnny would be Johnn. Checkname will ensure your machine name is entered as well and to ensure you got your username correctly

Check "Replace Owner on subcontainers and objects" for recursive ownership change

Horning

Could you also screenshot how you did the "Take Ownership"? Those 2 git commants are consecutive and the operation in the middle is missing. Thnx! – Bigener

Please read Why should I not upload images of code/data/errors? Instead, format code as a code block. The easiest way to do this is to paste the code as text directly into your question, then select it and click the code block button. – Granoff

@XaviMontero Properties Dialog of any files/folder/Secruity/Advance Click on Change button on the OWNER line/type in your username minus last character/click CHECK NAME button to ensure Check the Replace owner on subcontainers and objects once OWNER is defined, Click OK or APPLY. Sorry am traveling so no computers with me – Horning

@XaviMontero screenshots uploaded on main post. Hope this is what you were looking for. – Horning

Answer 3

Unsure whether this applies to everyone experiencing this error using Windows.
I ran Git Bash as administrator and it no longer displayed the error for me when doing "git status".
I may have originally created the repository while running Git Bash as adminstrator. I can't remember unfortunately.

Best of luck

Slippy

Upvoted this, kinda out of desperation :) , but didn't help in my case, unfortunately. (Of course I tried whitelisting the dirs first (initially one by one, then also with '*'), but that didn't work either...) – Antonietta

This should be the accepted answer. It solves the problem after restart terminal as admin. – Meyerbeer

Answer 4

the acutal issue is that when you run any command in any specific git repo, it checks the issuer id with that of the ownership of the repo files, if git finds any conflict then you may get an error like:

fatal: detected dubious ownership in repository at '/some/path'

the solution is either to change the ownership of the repository files to that of the bash user running the git command, or, if you understand that the ownership and group names are correct for the files in the specific repository then you can run:

git config --global --add safe.directory /some/path

which will securely resolve the issue. done.

Coruscation

This might not work on Windows, at least I can't imagine another reason for downvoting, but it looks like a correct and helpful solution for UNIX-like operating systems. – Soilure

Just ran it on windows, FAIL... I'm running view History from Visual Stupid-o (Studio) and it is throwing this error, doesn't matter if I add that, or even add: git config --global safe.directory '*' --replace-all I still get the error.. Turning the Git_Test_Debug_Unsafe_Directories to true (??) seems like it wouldn't solve the issue either -but could cause it... Last time I solved it by changing the owner of 1GB of files.. – Bulimia

Changing the entire owner tree to me (instead of Admin), exiting VS and going back in and it is still giving the error... Feeling like doing 'find / -name 'git' -rm' except that this is windows... Ugh... getting tired of this thing biting me... it was working until I deleted the entire source tree (due to git checkout branch_name, followed by git status saying I was on a detached head, and there was no remote - huh? how did I check it out then huh? And if I just checked out a branch it isn't detached)... – Bulimia

it WORKS from the command line (running as Admin), like it always did before I wiped out the directory and re-cloned it. – Bulimia

you have to mark it as safe from inside visual studio using their UI, if you do it from the command line, it doesn't work... Nice – Bulimia

Answer 5

I have encounter this issue after copying the folder from another PC (both Windows).

To fix it open property of the folder, click tab "Security" and button "Advanced". In the dialog box appears, make yourself the owner.

Nadabas

Or copy paste the folder, and work on the pasted folder since you will be the owner of it. – Durand

@OlivierdeRivoyre Yes, this should also work, but only if you are copying from a file system with no access rights (e.g. FAT32). – Nadabas

Answer 6

A workaround for Windows command prompt:

takeown /r /d Y /f <repository name>

It's a workaround because I would rather have my repositories installed 'correctly'.

Additional Notes:

Sometimes, I don't experience this issue when running command prompt as Administrator.

Fabria

Answer 7

I also faced the same situation for github and came here. But none of them worked for me in Windows 11. My scenario is, after reinstall windows, "git pull" didn't work. Showed me the same error. My procedure:

Added New SSH Key: GO HERE

Then Added that SSH Key to Github: GO HERE

After using git pull again, I have to give that paraphrase (if any) and that pulling worked.

So, this will definitely work for those who have faced,

1. New windows setup / reinstall windows
2. Using Github and used SSH Key

Thank you.

Excursive

Answer 8

Running wsl inside GitBash worked on my machine.

More discussion is here.

Mathildemathis

Answer 9

First of all, you check status type command: git status

then you saw this message enter image description here

now type these line of command that you have seen in the error line enter image description here

Lew

Answer 10

I just had this come up with using PHPStorm to access files that are on a WSL instance.

My issue was that I mounted the WSL instance to a drive letter and pointed the project to the drive instead of the true WSL file path U:\home\... vs \\wsl$\Ubuntu\home....

So to fix, just had to change the project location and all the git functions worked without have to silence the error.

Logographic

Answer 11

I had similar issue when using WSL2 on Windows and code editor is PhpStorm. The Show Git logs are not working with the error "git reporting detected dubious ownership in repository"

Here is the fix:

1. Open Windows Power shell
2. type wsl + enter
3. git config --global safe.directory '*'

Now the Git log is working.

Nonmoral

Answer 12

I was facing the same issue with Git GUI. A simple 'Run as Administrator' solved the problem for me.

Demagogue

Answer 13

simply add sudo in front of your command

sudo git status

Appendicectomy

If you are sure that you think this is a good solution, please elaborate why. – Soilure