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?

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 — Eric Hepperle - CodeSlayer2010, Oct 18 '22 at 19:24

philb · Accepted Answer · 2023-02-08T19:15:23.667

91

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 *.]

edited Feb 08 '23 at 19:15

answered Aug 25 '22 at 13:33

philb

2,031
15
20

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? – Xavi Montero Aug 25 '22 at 14:36
I see here https://github.com/git/git/blame/9bf691b78cf906751e65d65ba0c6ffdcd9a5a12c/setup.c 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? – Xavi Montero Aug 25 '22 at 14:57
3

I would first start by opening an issue at https://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. – philb Aug 25 '22 at 15:58
2

Thanks! This was the solution to my problem `git config --global safe.directory '*'` – Eric Hepperle - CodeSlayer2010 Oct 18 '22 at 19:23
+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. – therobyouknow Nov 12 '22 at 02:14
For security reasons, I would recommend `git config --global --add safe.directory /the/path/to/the/project/in/question` instead of wildcard – Xosofox Jan 24 '23 at 18:13
3

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 *`." – finch Feb 08 '23 at 16:46
I was struggling with the same thing, until I realized that the single quotes should be removed when using git on Windows. – Magne Rekdal Mar 13 '23 at 11:41
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! – user1585204 May 18 '23 at 17:55

ShaguarWKL · Answer 2 · 2023-05-18T09:40:59.093

6

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

edited May 18 '23 at 09:40

answered Apr 29 '23 at 04:25

ShaguarWKL

71
1
3

1

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! – Xavi Montero Apr 29 '23 at 21:14
Please read [Why should I not upload images of code/data/errors?](https://meta.stackoverflow.com/q/285551/354577) 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. – ChrisGPT was on strike Apr 30 '23 at 11:57
@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 – ShaguarWKL May 08 '23 at 14:17
@XaviMontero screenshots uploaded on main post. Hope this is what you were looking for. – ShaguarWKL May 18 '23 at 09:38

score 2 · Answer 3 · answered Dec 07 '22 at 08:57

2

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

answered Dec 07 '22 at 08:57

Glenster

1,187
2
13
31

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...) – Sz. Dec 17 '22 at 21:27
This should be the accepted answer. It solves the problem after restart terminal as admin. – Oseack Mar 21 '23 at 01:49

score 2 · Answer 4 · answered Dec 16 '22 at 06:28

2

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.

answered Dec 16 '22 at 06:28

Valentin Safonnikov

179
1
5

Or copy paste the folder, and work on the pasted folder since you will be the owner of it. – Olivier de Rivoyre Jan 26 '23 at 10:47
@OlivierdeRivoyre Yes, this should also work, but only if you are copying from a file system with no access rights (e.g. FAT32). – Valentin Safonnikov Jan 27 '23 at 13:46

score -2 · Answer 5 · answered Apr 12 '23 at 11:12

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.