168

After updating Git to v2.35.2.windows.1 I'm getting the following error:

fatal: unsafe repository ('F:/GitHub/my-project' is owned by someone else)
To add an exception for this directory, call:

git config --global --add safe.directory F:/GitHub/my-project

I've tried adding the parent directory of my projects to .gitconfig, but it doesn't work.

[safe]
    directory = F:/GitHub/
    directory = F:/Private/
  • Is there a workaround for this?
  • What does it actually mean by "'x' is owned by someone else"?

I don't want to add every single project I'm working on to the .gitconfig file.

hakre
  • 193,403
  • 52
  • 435
  • 836
Shleemypants
  • 2,081
  • 2
  • 14
  • 21
  • 2
    In my case, I'm the only one working on my laptop. However, since I clone to root rather than my home directory (don't judge me for that), I received this error because directories that I built at the root using `sudo` belong to the `root` user and not me. – Saeed Neamati Apr 14 '22 at 01:47
  • 2
    Also note that the drive letter casing has to match, else this wont work. – leppie Apr 14 '22 at 10:53
  • @DrLightman: you can downgrade your git version, and all things work fine. You have the choice between security and simple living (but note: now the security problem is known, so you should regularly check that nobody in your system is abusing it) – Giacomo Catenazzi Apr 14 '22 at 11:56
  • Note: Now there is a `v2.35.3.windows.1` which fixes some problems (the configuration message now is corrected, and so it *fixes* the problem (but still single repository at a time). (previously: it didn's tell you to add `prefix`, and when it complained, it missed one slash (in case of network drive with ip). – Giacomo Catenazzi Apr 19 '22 at 06:43
  • Is this limited to Windows or not? – Peter Mortensen Jun 04 '22 at 13:31
  • Related (more Linux oriented): *[fatal: unsafe repository ('/home/repon' is owned by someone else)](https://stackoverflow.com/questions/71901632/)* – Peter Mortensen Jun 04 '22 at 14:07
  • 2
    FYI, it seem if you are using fat32 or exfat disks this is an issue. and a very stupid issue at that. – Matthew Whited Jun 19 '22 at 03:05

24 Answers24

146

Starting in Git v2.35.3, safe directory checks can be disabled, which will end all the "unsafe repository" errors (this will also work in the latest patch versions of 2.30-34).

This can be done by running:

git config --global --add safe.directory '*'1

It will add the following setting to your global .gitconfig file:

[safe]
    directory = *

Before disabling, make sure you understand this security measure, and why it exists. You should not do this if your repositories are stored on a shared drive.

However, if you are the sole user of your machine 100% of the time, and your repositories are stored locally, then disabling this check should, theoretically, pose no increased risk.

Also note that you can't currently combine this with a file path, as the command doesn't interpret the wildcard * as an operator per say– it just takes the "*" argument to mean "disable safe repository checks/ consider all repositories as safe".

1 - If this fails in your particular terminal program in Windows, try surrounding the wildcard with double quotes instead of single (Via this GitHub issue):
git config --global --add safe.directory "*"

zcoop98
  • 2,590
  • 1
  • 18
  • 31
Marcodor
  • 4,578
  • 1
  • 20
  • 24
  • 2
    I can't seem to get this to work. It does work if I specify a specific directory. Are you sure this wildcard setting works? – nonrectangular Apr 18 '22 at 23:51
  • Yes, tested it. Git v2.35.3 on Win10. – Marcodor Apr 19 '22 at 05:55
  • I too was able to get this to work; I ran it in git bash on Windows. This should, theoretically, not open any security holes if you're the **sole user** on a machine, and if the repositories you use are on **a local drive** (rather than some shared one). In my case, I'm the sole user of my Windows machine, and my repositories are in a directory at the base of `C:` drive. – zcoop98 Apr 19 '22 at 20:50
  • 7
    @nonrectangular If you're on Windows, you might try using double quotes instead of single around the wildcard `"*"`. – zcoop98 Apr 19 '22 at 21:17
  • There must be more going on. It does not work for me on Ubuntu 20.04. It adds the right stuff to .gitconfig but I still get the error. – Hal Burgiss Apr 20 '22 at 15:40
  • 2
    Me again, sorry but I thought I had upgraded git on the server I am testing on, but no. After doing that and doing what zcoop98 said, it works fine now! YAY! – Hal Burgiss Apr 20 '22 at 15:50
  • Is there any documentation for use of wildcards in this setting? Instead of just using `*`, I tried using `C:/Users/MyUser/Projects/*`, but that didn't work. – asherber Apr 20 '22 at 17:55
  • 4
    Thanks @HalBurgiss. I failed to realize the wildcard is only available in git v2.35.1 and later. Ubuntu 20.04 ships with v2.25.1. Ubuntu applied the security patch to the older versions of git, including v2.25.1, so it would produce this new error, but did not patch support for this wildcard solution. See M.S. Arun's solution to use a PPA on Ubuntu 20.04 to get the latest git. – nonrectangular Apr 20 '22 at 18:17
  • 1
    @asherber To clarify, via [this post in the GitHub thread](https://github.com/git-for-windows/git/issues/3809#issuecomment-1102681740), the asterisk here isn't actually used by git as a "wildcard"– just as a symbol to represent "disable safe repo/ consider all repos as safe". – zcoop98 Apr 21 '22 at 14:51
  • 5
    @zcoop98 Thanks, good catch. And too bad! A wildcard would be useful. – asherber Apr 22 '22 at 15:03
  • 12
    Yes, they fix a security issue so badly that disabling the security fix is necessary to get work done. Awesome. – Eric Jul 25 '22 at 04:03
  • 2
    This setting does nothing for me, I still get the same error. Taking ownership of the folder isn't an option either, as the problem occurs on the build server and the build user isn't allowed to own the folder containing the git repository. – Mort Sep 29 '22 at 12:16
  • I couldn't get this to work in CygWin or plain windows cmdPrompt as "*" or '*'. It worked in cmdPrompt when i removed all quotes and just did a plain *. (this didn't work in cygwin) – Bill Tarbell Dec 30 '22 at 19:19
  • 1
    Since globs can't be used, is there a way to whitelist a user like `root` (e.g. for my NTFS-mounted drive on Ubuntu)? – geekley Mar 23 '23 at 21:42
98

Answer

This seems to be related to this announcement of a vulnerability: https://github.blog/2022-04-12-git-security-vulnerability-announced/

I think it has less to do with your email, and more with the owner of the directories on your filesystem. Is the user you're currently logged in with also the owner of the folder? How about the parent folder? Also, are you invoking git from within the repository directory? The update is only a few hours old, so I guess things are still in flux.

For now, as the message from git suggests, execute

git config --global --add safe.directory F:/GitHub/my-project

and make sure you are calling git from within F:/GitHub/my-project for now.

EDIT: As we found out in the comments below, the owner of the parent of the directory containing the .git folder (the git repository) is the issue.
Cloning the project anew is a platform independent way to make sure you are the owner.

Sidenote

I ran into the same problem using flutter on Linux, which on my distro was installed in /opt/flutter. I am not working as root, thus I run into the same problem. Running git config --global --add safe.directory /opt/flutter did indeed fix the problem for me.

Longer edit: Clarification

Going through the post about the vulnerability again after a good night's sleep, I think a bit of clarification is in order. I'll leave the rest of the answer as is.
Lets look at the following simple directory structure.

/home/
├─ tommy/
│  ├─ .git/
│  ├─ rental_space/
│  │  ├─ mary/
│  │  │  ├─ projects/
│  │  │  │  ├─ phone_app/
│  │  │  │  │  ├─ .git/
│  │  ├─ anthony/

In this case, the user tommy owns his own directory under /home, but (for some reason) rents out space to other users, in this case mary and anthony.
If mary, by mistake, where to execute git in her directory, but outside of her phone_app project, then old git would go up the directory tree to search a .git repository. The first it finds is the one from /home/tommy/.git. This is a security risk, because another user, in this case anyone that can act as tommy, can affect mary's execution of git and possibly cause trouble.
From Git v2.35.2 and onward, the traversal will stop as soon as the directory entered belongs to a user other than mary. Say mary executed git in /home/tommy/rental_space/mary/projects, then git will check in projects, but find no .git. It will go up one directory, check in mary, but again find no .git. Then it will again go up, but rental_space belongs to tommy, not mary. The new git version will stop here and print the message we saw in the question.
Adding the directory /home/tommy/rental_space to the safe.directory variable would allow git to proceed but is, as explained, a security risk.

I used a Linux-like directory structure here, but the same is true on Windows.

Stiin
  • 3,073
  • 1
  • 8
  • 12
derpda
  • 1,093
  • 8
  • 16
  • Yes the current user is the owner of both project and their parent directories. And also yes I'm invoking git from within the repository directory but error still there. Thanks for your answer, I guess I'll add the directories one by one until a fix rolls out. – Shleemypants Apr 13 '22 at 00:01
  • Just noticed the `.git` directory has a weird owner possibly from a previous Windows installation. Changing the permission didn't work but cloning the project again didn't raise the "owned by someone else" error. Interesting. – Shleemypants Apr 13 '22 at 00:12
  • Mhh that is interesting indeed, and most likely the cause. And this is probably also the reason why this change in git was made, since someone else could conceivably modify your .git folder. Good to hear that a simple re-clone fixed your problem though! – derpda Apr 13 '22 at 00:20
  • 2
    Seems that for submodules, the submodule folder and .git file need correct ownership now too. i.e. adding the parent project as a safe.directory will include submodules but only if their file ownership matches current user (or perhaps the parent .git folder). – webaware Apr 13 '22 at 04:01
  • Actually, see my answer; seems that adding to safe.directory is not required on Linux at least, if you are the owner of the folder containing the git repo. – webaware Apr 13 '22 at 04:20
  • 2
    @webaware Can't comment on your answer yet (.....), but I don't think you added much more than a minor clarification. I'll fix up my answer a bit! – derpda Apr 13 '22 at 04:44
  • 2
    You are correct that the `user.*` settings are irrelevant. The security issue is that on WIndows shared drives (and potentially on any multi-user system including some Linux systems) it may be possible to trick people into running Trojan Horse software. Git tries to use the OS's concept of file-and-directory-ownership to get around this security issue. – torek Apr 13 '22 at 04:51
  • So I am running into this same issue. I am pretty sure that it is because I am running a git command inside of my php code from the browser which runs the command under one user, but the owner of the directory for the repository is a different user. I just don't understand why I am running into this issue if I haven't updated git. I am currently on version 2.25.1. I have also tried adding the safe.directory config variable and it still isn't working. – Battousai Apr 13 '22 at 17:20
  • @Battousai In the [git post I mentioned](https://github.blog/2022-04-12-git-security-vulnerability-announced/), they discuss how to reduce the risk on older versions by modifying the [`GIT_CEILING_DIRECTORIES` environment variable](https://git-scm.com/docs/git/2.35.2#Documentation/git.txt-codeGITCEILINGDIRECTORIEScode). Maybe that was done in your case? – derpda Apr 13 '22 at 23:56
  • 2
    There are other problems with trusting folders on Windows. The latest Beta of GitHub Desktop fixes the problem. Git also fails to check whether an NTFS folder's owner is a security group that the user might be in. – Spencer Apr 15 '22 at 15:36
  • *"Adding the directory /home/tommy/rental_space to the safe.directory variable would allow git to proceed but is, as explained, a security risk."* It's not clear there whether you mean you can do it via `--add safe.directory` but it comes with a risk, or that git will just not do it anyway because of the risk. It just plain does not work for me: I literally cut n' paste the `--add safe.directory` command (as both the directory owner and the git user), try git again, nothing has changed, v2.35.3 <- What's strangest is that using `safe.directory '*''` *does* work. – CodeClown42 Jun 03 '22 at 16:21
  • @CodeClown42 Not sure why you think it is unclear, I think that sentence is pretty clear. Add the path to `safe.directory` and git **will** proceed, in spite of the risk. About the command not working for you, I cannot comment on that without more details - maybe open a new question if you are still facing that issue. – derpda Nov 17 '22 at 10:14
  • I think it's potentially unclear because of the difference between your sentence in the comment above and the original source -- they are not the same, and although the latter *could* mean the same thing, it *could* also mean something contradictory. Admittedly, I don't think I would have harped on it if `--add safe.directory` had worked. The fact that it didn't would have led me to consider the possibility that, eg., a typo of mine was involved, then when that was ruled out, that I had misunderstood the docs (or online advice) leading me to take note of ambiguities therein. – CodeClown42 Nov 17 '22 at 19:33
  • @CodeClown42 Frankly I still don't see how that part is unclear, but if you think it could be phrased cleaner then please suggest an edit to my post! – derpda Nov 18 '22 at 03:56
19

As @derpda said, it's related to a Git security vulnerability that has been fixed.

On Linux, at least, you can fix the problem by ensuring that the parent folder of the Git repository is owned by you. There isn't any need to add the safe.directory configuration setting if you can set the folder ownership appropriately.

If you need different ownership (e.g., working on a service that runs as a different user), then add your folder to the multi-value safe.directory configuration setting:

git config --global --add safe.directory /path/to/project
Jeremy Caney
  • 7,102
  • 69
  • 48
  • 77
webaware
  • 2,795
  • 2
  • 30
  • 37
17

I found the same issue on Windows after upgrading to version 2.35.2.windows.1.

I was able to fix it by taking ownership of the folder containing the .git folder and all the files in it.

This is the command assuming you already are in the repository folder:

takeown.exe /f . /r

Note: if you have multiple repository folders inside a work folder, you may want to take ownership of the work folder and its subfolders recursively. It takes more time to execute, but you only need to do this once.

The command would look like this under cmd.exe:

takeown.exe /f C:\Users\%USERNAME%\Work /r

Or like this under powershell.exe or pwsh.exe:

takeown.exe /f $HOME\Work /r
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Camilo Estevez
  • 637
  • 1
  • 8
  • 16
  • 7
    I would not recommend taking ownership recursively. You only need ownership of the parent folder of `.git` and of `.git` itself. For example, using your suggetsions becomes important when your project includes folders used as docker volumes. The permissions inside those folders are often different on purpose, and have no effect whatsoever on the problem with git. – derpda Apr 15 '22 at 00:59
  • @derpda, I generally agree, but your comment is completely true only when you execute all Git commands from the repo's root. If you execute the commands from a subdirectory, the whole path up to the parent of `.git` needs to be owned by the current user. – Palec Apr 19 '22 at 17:14
  • 2
    @Palec You are right about that, but in the example I gave of a docker volume, changing ownership of the directory is a bad solution - just change directory with `cd` instead so you can safely execute `git`. – derpda Apr 20 '22 at 00:59
  • `takeown` also screws multiboot. git needs to do proper ACL checks. Yeah, those things that nobody uses on Linux because they are broken. They work on Windows. Pretty much always have. – Eric Jul 25 '22 at 03:58
7

For those working on an NTFS mounted file system (probably a shared data drive with Windows), you can edit your mount options in /etc/fstab by appending defaults,uid=1000,gid=1000 to it. This is as by default; you can't permanently change the owner of .git in NTFS. These options will make everything owned by your current user (rather than by root).

S P Sharan
  • 1,101
  • 9
  • 18
  • Thank your, works like a charm :D I'm using bitlocker with a windows partition and the owner can acces now to the .git file. – silexcorp Apr 18 '22 at 23:00
7

For (mainly) Visual Studio 2022 users:

This is my setup:

  • Git version 2.36.0.windows.1
  • Mounted SMB network share from my NAS \\MyNas\User as X:\
  • The remote branch was cloned into a directory on X:\.
  • My NAS and PC are not in the same domain.
  • My IDE: Visual Studio 2022 Enterprise 17.2.0 Preview 4.0 (latest)

The issue so far:

Since my NAS and PC are not in the same domain, I cannot set my PC user as the owner of the NAS directory.

When opening the repository in Visual Studio, this error showed up in the console:

Opening Repository:
X:\Repo
Git failed with a fatal error.
fatal: unsafe repository ('//MyNas/User/Repo' is owned by someone else)
To add an exception for this directory, call:

    git config --global --add safe.directory '%(prefix)///MyNas/User/Repo'

After long testing:

The issue was the portable Git installation of Visual Studio, which had the version 2.35.2. Visual Studio, even when the component "Git for Windows" was unchecked, still used its own Git-installation instead of my global Git installation.

The solution:

  1. Add the repository directory as a safe directory with the recommended command:

    git config --global --add safe.directory '%(prefix)///MyNAS/User/Repo'

# Or just trust any directory (not really recommended)
git config --global --add safe.directory *

  2. Update the Git-Version which Visual Studio uses. (I just took the files from the global Git installation located in C:\Program Files\Git\mingw64\bin and pasted them to C:\Program Files\Microsoft Visual Studio\2022\Preview\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\mingw64\bin)

Maybe an alternative of copy/pasting files, would be to make Visual Studio use the global installation of Git, like described in this Stack Overflow question: Configure Visual Studio to use system-installed Git.exe.
Note: I have not tested this alternative, since I already overwrote the Git files in my Visual Studio installation directory.

Key notes:

  • Latest Git version (2.36.0) supports safe/trusted directories.
  • Make sure your IDE is using the latest version of Git.
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Edgar.Bro
  • 121
  • 1
  • 1
  • 4
  • 3
    Yes. Just point out that `%(prefix)` is _literally_ `%(prefix)` and not some variable substitution. – Spencer May 03 '22 at 17:49
6

For Ubuntu 20.xx Users Fix - 2022 UPDATE:

Updating Git with this PPA provides the latest stable upstream Git version fixed this issue.

sudo add-apt-repository ppa:git-core/ppa

sudo apt update

sudo apt install git

Ref: https://git-scm.com/download/linux

M.S. Arun
  • 1,053
  • 13
  • 22
  • There is [Ubuntu 20.04 (Focal Fossa)](https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_20.04_LTS_(Focal_Fossa)) and [Ubuntu 20.10 (Groovy Gorilla)](https://en.wikipedia.org/wiki/Ubuntu_version_history#Ubuntu_20.10_(Groovy_Gorilla)). What version, incl. minor version, did you test it on? – Peter Mortensen Jun 04 '22 at 13:17
  • Works for mine on 20.04 according to https://launchpad.net/~git-core/+archive/ubuntu/ppa both should work – Raymond Jun 05 '22 at 02:11
6

It happened to me, because I'd reinstalled my Windows system, and the owner of some repository folders are the old user in the former install. So Git won't let you use those folders directly.

You can check this by Properties → Security → Advanced → Owner. If the current owner is something like "S-1-blah-blah", then you encountered the same problem as me.

If you are sure you are the real owner of those folders, you can just use the takeown command:

cd F:/GitHub/
takeown /f *

The /r switch does not seem to be required for my case.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
mercury233
  • 61
  • 4
  • I have solved this problem for YEARS by having `BUILTIN\Administrators` as the owner, but now I have been set back a decade because git is using Linux semantics on Windows and they shortcut doing the work with some talk about performance while all they need to check is the repo root. But properly. – Eric Jul 25 '22 at 03:56
6

I had a local repository at my Windows PC mapped to a network folder:

n:\folder

This points to

\windows-server\folder\working-folder

When I tried to do

n:\folder> git status

there came this known error:

fatal: unsafe repository ('//windows-server/folder/working-folder' is owned by someone else) To add an exception for this directory, call:

    git config --global --add safe.directory '%(prefix)///windows-server/folder/working-folder'

To change file permissions was not possible in my case. So I tried

git config --global --add safe.directory '%(prefix)///windows-server/folder/working-folder'

but this did not work. I had to remove the ''!

Solution:

git config --global --add safe.directory %(prefix)///windows-server/folder/working-folder
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
DemIngenieurIstNichtsZuSchwör
  • 91
  • 3
6

In Termux on Android, you have to add the actual git repo, not the parent directory.

git config --global --add safe.directory /storage/emulated/0/src/go2null-dotfiles

You can also disable the check.

git config --global --add safe.directory '*'
go2null
  • 2,080
  • 1
  • 21
  • 17
5

Adding this here since it seems no-one else has, and it helped me. You can set this system-wide by running as root with --system instead of --global, eg:

sudo git config --system --add safe.directory '*'

Alan Rowarth
  • 2,250
  • 2
  • 14
  • 10
4

I run Visual Studio sometimes as Administrator and sometimes as a normal user. This leads to the problem.

Symptoms 1

In Visual Studio - when opening a local folder - it seems as if the code is no longer added to source control.

Opening a solution in Visual Studio 2019: The above messages appear in the Git output window for each project. Opening a solution in Visual Studio 2022: It just says One or more errors occurred..

Symptoms 2

When opening a normal command prompt in the parent folder of .git executing git log shows the message

fatal: unsafe repository ('C:/GIT/MyProject' is owned by someone else)
To add an exception for this directory, call:

    git config --global --add safe.directory C:/GIT/MyProject

There are no errors when executing any command in an Administrator command prompt.

Solution

Change the owner of the MyProject folder to the normal user. Afterwards everything works fine as normal user and also as Administrator.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
huha
  • 4,053
  • 2
  • 29
  • 47
  • 4
    I've already filed an issue in Visual Studio Community to add a warning about this: https://developercommunity.visualstudio.com/t/Consider-adding-a-warning-for-fatal:-uns/10012582 – Shleemypants Apr 14 '22 at 11:31
4

On Ubuntu 20.04 (Focal Fossa) and Laravel Forge (user isolation):

I tried updating Git to 2.36 as recommended in previous answers, but this did not work. I tried the GitHub solution:

git config --global --add safe.directory GIT/MyProject

and also as recommended in a previous answer:

git config --global --add safe.directory '*'

None of these worked for me.

The only thing that worked was ensuring that the ownership of the parent directory and the project directory where folder .git is located has the same owner as explained by Tc Blaize.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Big Pete
  • 138
  • 8
  • True. In my case while parent directory and all sub folders were owned by one user, .git and .gitignore were used by another user. Fixing owner helped – Vitaly Sep 01 '22 at 11:10
4

I recently had the same problem, because I had to reinstall windows and copied the repository from the old system's drive.

A look at the security settings of the folders made clear that the "old users" id (the previous windows system) was set. Because the old user is unknown in the new system the dialog only showed the SID of the user.

Right click on folder -> Properties -> Security -> Advanced

enter image description here

After I changed the ownership to my actual user everything works fine again.

enter image description here

Don't forget to check the "Replace owner on subcontainers and objects". Otherwise only the acutal folder (git repo folder) will have the new ownership.

René Link
  • 48,224
  • 13
  • 108
  • 140
3

In my case, on an Ubuntu 20.04.4 system (Focal Fossa), the project folder had the ownership set to the application user, e.g., www-data:www-data, but the .git folder when initiated had its ownership set to root:root.

To fix this issue, I changed the ownership on my project folder to root:root so as to match its contents (including the .git folder). Then all Git actions started working as normal.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Tc Blaize
  • 61
  • 5
3

As a part of automation, our scenario involved invoking one script multiple times and we don't know the workspace upfront.

So, in our case, git config --global --add safe.directory * created multiple entries in ~/.gitconfig.

git config --global --replace-all safe.directory '*' helped us ensuring no duplicate entries.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
urug99
  • 101
  • 3
  • I'm really enjoying in how git was broken for a ton of people just to "protect" a small number of people that can't seem to check their own security in shared environments. – Matthew Whited Jun 19 '22 at 03:08
3

On windows, I use this

git config --global --add safe.directory *

or

git config --global --replace-all safe.directory *
Rasha Mohamed
  • 66
  • 1
  • 4
2

On Windows, when you create a folder from an elevated prompt, it gets the owner set to the Administrators group.

Then inside it, when you clone the repository using a non-elevated prompt, it gets you as an owner. It is enough to trigger a new Git validation.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
WaSyL
  • 41
  • 1
  • 3
  • In general, I would recommend against this. It is much safer to be running usually as non-admin. On windows, we used @marcodor's solution: `git config --global --add safe.directory *` and it disabled this check for us (which makes sense for us) – Charles Plager Apr 18 '22 at 16:20
  • 2
    This answer is not suggesting to run git as admin. It only refers to creating the folder, and likely not as a solution, but that doing so *causes* the issue. At least on my system, I was getting the error because my project directories are owned by the 'Administrators' group. – Lexikos Apr 23 '22 at 23:56
1

I'm running Windows 11 and WSL and I was getting this error in Sourcetree. I made two mistakes initially -- running the command from WSL, and using quotes as Sourcetree suggested. Once I ran it from cmd at C:\Users\alyssa, and without quotes, it was putting the correct syntax in the correct .gitconfig file:

C:\Users\alyssa\.gitconfig:

[safe]
    directory = %(prefix)///wsl.localhost/Ubuntu/home/alyssa/my-repo
Lys777
  • 426
  • 1
  • 3
  • 11
0

This issue occurs after the Ubuntu auto package update. After checking the updates in log file, /var/log/apt/history.log, I found two Git packages updated and after that update date mess with Phabricator occurred.

git
git-man

I used the below two commands to check the previous version in the cache and installed the old version.

apt-cache policy git:amd64

Output:

git:
  Installed: (none)
  Candidate: 1:2.17.1-1ubuntu0.10
  Version table:
     1:2.17.1-1ubuntu0.10 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     ***1:2.17.0-1ubuntu1*** 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

sudo apt-get install git=1:2.17.0-1ubuntu1
apt-cache policy git-man:amd64

Output:

git-man:
  Installed: 1:2.17.1-1ubuntu0.10
  Candidate: 1:2.17.1-1ubuntu0.10
  Version table:
*** 1:2.17.1-1ubuntu0.10 500
        500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
        500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
        100 /var/lib/dpkg/status
     1:2.17.0-1ubuntu1 500
        500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

sudo apt-get install git-man=1:2.17.0-1ubuntu1
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Rahul Sharma
  • 1
  • 2
0

OK. To add more to the soup in previous answers where the directories either aren't owned or are outside the user's home directory, a little bit of PowerShell, and I'm sure someone can translate this to Bash, can add the directories to the safe list.

The below was written on Windows, but on Linux, remove the "-replace '\','/'" as it would break anything with spaces in the path.

(ls D:\PowerShell\ParentFolder\ -Directory).FullName -replace '\\','/' | %{git config --global --add safe.directory $_}
Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Kevin Pinel
  • 1
0

git config --global --add safe.directory '*' //star meal all

you can create all directory is safe.

Munna Hossain
  • 1
  • 1
  • Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers [in the help center](/help/how-to-answer). – abdo Salm Sep 27 '22 at 02:00
-1

We have fixed this issue by fixing the .git/objects permissions. We were actually unable to add files without sudo because of the bad permissions.

mshakeel
  • 604
  • 6
  • 21
-1

In my case, I just copy the message, write sudo, and then paste the message. After pressing the Enter button, the issue has gone.

For example:

sudo git config --global --add safe.directory your-path

'your-path' = as shown in the message

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
Khandaker Toihidul Islam
  • 393
  • 2
  • 5
  • 2
    This solution works but like I said in my question: I have to run this for every single project in my machine. It shouldn't be like this. – Shleemypants Apr 13 '22 at 18:25
  • 2
    Also, you shouldn't just copy and sudo-paste a message to without understanding the implications of doing so. – AKX Apr 14 '22 at 11:40