Git初始化：致命错误：无法将“core.filemode”设置为“false”。

Question

使用Team City从Git Repo（如果有关系，则是Gitlabs）检出。

从空构建目录开始，会遇到以下错误：

fatal: could not set 'core.filemode' to 'false'

（在Windows计算机上运行，如果有关系的话）

为了排除问题，将运行Team City的用户更改为管理员。

当此命令退出时，.Git目录不是有效的Repo。

清除整个“work”目录也无济于事。

这个问题随机出现并消失...

另外，执行以下命令也没有任何作用：

git config --global --replace-all core.fileMode false

无论是否带有--replace-all选项，以及以管理员或其他用户身份运行（如果将'false'更改为'true'，则会得到相同的错误；如果将其更改为'falseCD'，则会将错误更改为该值无效-因此显然正在进行更改）。

有人有什么想法吗？

- Traderhut Games

---

很清楚Git试图更改配置设置但失败了，但不清楚原因。Git通过创建.git/config.lock、在那里写入新配置，然后将已完成的.git/config.lock重命名为.git/config来更新.git/config。如果这三个步骤中的任何一个失败（无法创建.lock文件，无法写入.lock文件，无法将.lock文件重命名为目标文件），你就会得到上面的错误。找出其中哪一步出现问题以及为什么出现问题。 - torek

它刚刚创建了目录（没有.git），因此如果有config.lock文件，则此进程将其作为“git init”命令的一部分创建。它在目录中创建了许多其他文件，包括“config”文件，对于正在运行git的进程，它具有完全的管理员访问权限。我相信这已经排除了所有三个可能性... - Traderhut Games

因此，解决这个问题的一种方法是告诉git在第一次写入配置文件后不要更新它。我曾经尝试将值设置为false，还有另一个项目设置为true时都遇到了这个错误。我尝试使用--system而不是--global，但没有帮助。（甚至不确定）-哦，没有config.lock文件。如果无法重命名文件，它应该发出错误提示（我怀疑它不会），如果无法创建它，它应该发出错误提示（我怀疑它不会）。我相当期望它与任何明显的东西都无关 :-( - Traderhut Games

我不“做”Windows，但我了解到Windows有强制文件锁定功能。如果某个进程在打开一个文件时，另一个进程试图操作该文件，则第二个进程的尝试将会失败。也许一些持续运行的后台进程（TeamCity的一部分？）正在持有某些东西，阻止Git完成任何操作，尽管具有管理员权限。 - torek

另一个线索是，似乎与无法更新文件“config”有关，因为它只是创建了该文件，因此从--system级别中删除了core.filemode，现在它失败了：致命错误：无法将'core.bare'设置为'false'。 - Traderhut Games

Answer 1

在我的情况下，使用 "sudo" 对我有用。例如：

asif@asif-vm:/mnt/prog/protobuf_tut$ git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
error: chmod on /mnt/prog/protobuf_tut/protobuf/.git/config.lock failed: Operation not permitted
fatal: could not set 'core.filemode' to 'false'

通过执行“sudo”命令，我得以使其正常工作：

asif@asif-vm:/mnt/prog/protobuf_tut$ sudo git clone https://github.com/protocolbuffers/protobuf.git
Cloning into 'protobuf'...
remote: Enumerating objects: 5, done.
remote: Counting objects: 100% (5/5), done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 66782 (delta 0), reused 0 (delta 0), pack-reused 66777
Receiving objects: 100% (66782/66782), 55.83 MiB | 2.04 MiB/s, done.
Resolving deltas: 100% (45472/45472), done.
Checking out files: 100% (2221/2221), done.

- linuxstack

---

看起来像是权限问题。我们如何通过正确的“chmod”解决这个问题？ - Matthieu

我也认为这对我有用。在我的情况下，我正在Windows 10中的WSL中克隆到Windows目录的符号链接（“/mnt/c/mydir/…”）。 - Ron Burk

我在想：“哎呀，我不需要读所有那些答案……”。然后我找到了这个漂亮的答案。非常感谢！ - Daniel Azamar

Answer 2

我不想唱反调，但我是通过重新启动Windows来解决这个问题的。

- Blairg23

---

我也通过重新启动 Windows 解决了这个问题。 - Vince W.

谢谢你的笑话，哈哈。顺便说一下，你也解决了这个问题。 - birajad

如果您正在使用WSL2并在主目录下进行克隆，则这是正确的答案。当WSL首次启动时，其主目录指向Windows用户目录。当主机重新启动时，您的主目录将恢复正常。 - Louis Go

关掉，然后再打开，谢谢@Louis Go提供的可能原因，但是我一直在尝试使用Phpstorm下载文件，但是Git似乎更快。 - Datadimension

这听起来有些蠢，但基本上是正确的，因为@LouisGo所说的原因 - 你需要重新启动的只是WSL/WSL2，而Windows重新启动会覆盖它，但这太过费力。只需在提升的shell中运行 wsl --shutdown 命令，然后再次启动它（WSL）即可。 - Torque

如果你刚刚安装了一个新的WSL发行版，很遗憾这是最实际的解决方案。 - Hanxue

Answer 3

Traderhunt Games追踪到这是一些杀毒软件, 这很有道理。原因与Git用于更新配置条目的过程有关。

当git config运行并被告知要更改一个或多个配置key = value字段，例如将core.filemode更改为false时，它实现此操作的方式是使用三个步骤：

1. 使用操作系统服务调用创建一个新的空文件 (.git/config.lock)，如果文件已经存在则失败。如果此步骤失败，则表示另一个 git config （或等效命令）正在运行并且我们必须等待它完成才能执行我们自己的 git config。

2. 逐个读取现有的配置文件中的每个 key = value 条目。如果关键字是我们关心的关键字，则写入 新的 key = value 值，否则复制现有的 key = value。

   这里有一些关于允许重复出现的键与应该只出现一次的键的花哨操作；有关详细信息，请参阅 git config 的 --replace-all 和 --unset-all 选项。请注意，git config 本身对大多数键值对知之甚少，您可以发明自己的键/值对，只要选择 Git 今天不使用并且将来也不会使用的键即可。（如何确定 Git 在 2043 年会和不会使用什么，我不知道。:-)）主要的例外是一些 core.* 值，这些值 git config 是可以理解的，而且其他几个 Git 命令可能会自己设置。

   （请注意，--unset 的处理方式与替换非常相似。与非 all 替换一样，它只取消设置第一个匹配的 key = value 对。取消设置是通过简单地不写入给定键来实现的，而不是写入替换的 key = value。由于 git config 仅逐行处理文件，因此这很容易做到。此外，如果您的 key = value 是全新的，则 Git 通过阅读所有行来处理此问题，注意到它没有替换任何现有的 key，因此会添加一个新的 key = value 行。这在一定程度上受到键按部分列出的事实的影响，但逻辑本身是足够简单的。）

3. 最后，在完全读取整个现有配置并完全编写出新配置（根据需要使用 fflush 和 fsync 和 fclose 等），git config 调用操作系统服务以 重命名 文件，将 .git/config.lock 重命名为 .git/config。 这就是在此特定情况下失败的过程。

如果重命名成功，则会将新配置生效并删除锁定文件，所有这些操作都是原子操作：任何其他Git命令都会看到完整的旧配置（来自原始的.git / config文件）或完整的新配置（来自新的.git / config文件，在构建期间称为.git / config.lock）。

另一个StackOverflow问题问道：我们将来是否能够在Windows中删除打开的文件？ 接受的答案包括这样一种说法：不使用完全共享（包括删除）启用的杀毒软件是有缺陷的。 如果是这种情况 - 即，如果特定的杀毒软件无法使用“允许删除”标志打开，并且此类软件有缺陷，则此特定杀毒软件是有问题的。

- torek

Answer 4

当我通过Samba将Windows共享驱动器挂载到Linux上并运行git init时，出现了这个错误。 我使用sudo进行初始化，然后将其更改回原始用户，并一切都好了：

sudo git init # no error
sudo chown user:user .git -R # drop sudo requirement
git add file1 # works normally
git commit -am bla # works normally

- Shadi

---

然后可能需要执行 git config --global --add safe.directory 'path/to/repo'。 - Eric

Answer 5

对我来说，这只是在 /etc/nsswitch.conf 文件中注释掉两行的事情。

我注释掉的行是：

group: files # db
db_enum: cache builtin

然后关闭并重新打开Cygwin

- Shōgun8

Answer 6

在Windows WSL中，当我尝试从Windows树下的文件夹首先创建newuser，然后git init .时，出现了这个错误。 newuser能够在其Linux主目录中创建git存储库。

重新启动Windows对于我来说无法摆脱WSL中的这个问题。在我的用例中，我需要从Windows命令行中发出wsl --shutdown。在这样做之前，我已经在WSL Linux中创建了/etc/wsl.conf，其中包含以下内容，受https://dev59.com/UVYN5IYBdhLWcg3w9Mbr#50856772的启发：

[automount]
options = "metadata"

并将newuser添加到sudo用户组中

usermod -aG sudo newuser

当文件夹不属于newuser时，为了能够不仅执行git init .，还能够实际使用给定的git存储库，则newuser必须运行

git config --global --add safe.directory /mnt/c/...repositorypath

- VojtaK