I cannot add the parent directory to *safe.directory* in Git

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.

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 directory structure here, but the same is true on Windows.

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 '*'¹

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 "*"}

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

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 repo folder.

takeown.exe /f . /r

Note: if you have multiple repo folders inside a work folder you may want to take ownership of the work folder and its sub-folders recursively. It takes more time to execute but you only need to to 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

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

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).

I run Visual Studio sometimes as Administrator and sometimes as normal user. This lead 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 Visaul 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 executiong 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.

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.

For (mainly) Visual Studio 2022 users:

So this is my setup:

• Git version 2.36.0.windows.1
• Mounted SMB network share from my NAS \\MyNas\User as X:\
• 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 repo in VS, 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 repo 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 SO-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 VS-installation directory.

Keynotes:

• Latest Git-Version (2.36.0) supports safe/trusted directories.
• Make sure your IDE is using the latest version of Git.

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 seems not required for my case.

On Windows when you create folder from elevated prompt it gets owner set to the Administrators group. Then inside it when you clone repo using non elevated prompt it gets you as an owner. It is enough to trigger new git validation.

I had a local repository at my Windows PC mapped at 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 ''!

Solutution:

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

https://stackoverflow.com/questions/71849415/i-cannot-add-the-parent-directory-to-safe-directory-in-git

This issue occur after the ubuntu auto package update. After checking the updates in log file - /var/log/apt/history.log.

Found 2 git packages updated and after that update date mess with phabricator occurred.

git

git-man

Used below 2 commands to check the previous version in cache and installing the old version.

root@phabricator:~# apt-cache policy git:amd64
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

root@phabricator:#sudo apt-get install git=1:2.17.0-1ubuntu1
----------------------------------------------------------------

root@phabricator:# apt-cache policy git-man:amd64
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

root@phabricator:~# sudo apt-get install git-man=1:2.17.0-1ubuntu1

OK. To add more to the soup above 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.

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 $_}

Ubuntu 20.04 Laravel Forge (user isolation)

I tried updating git to 2.36 as recommended above but this did NOT work. I tried the github solution

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

and also recommended above

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 .git is located has the same owner as explained by Tc Blaize above.

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.

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.

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

For example:

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

your path = as shown in message

In Windows, run cmd.exe as administrator, otherwise it generates "fatal: unsafe repository"