Problem entry · machine-readable · 编码代理与终端

git 报 fatal: detected dubious ownership in repository at(仓库属主与当前用户不一致)

本页嵌入 #trove-entity JSON(本条目全量结构化数据);全库数据见 /agent/trove.json。

元数据

idgit-dubious-ownership收录2026-08-29
问题域编码代理与终端主题分组权限与安全
适用工具git · 外部工具

症状

对某个仓库执行任意 git 命令(git status / git log / git pull…)直接报:

```

fatal: detected dubious ownership in repository at '<仓库绝对路径>'

To add an exception for this directory, call:

git config --global --add safe.directory <仓库绝对路径>

```

特征:仓库能正常打开、文件也都在,但所有 git 命令全挂;错误里点名的路径是仓库根目录;最常出现在双系统 Ubuntu 挂载 Windows NTFS 硬盘、U 盘/移动硬盘拷贝的仓库、WSL 访问 Windows 侧目录、或 root/sudo 创建的仓库——这些场景下仓库文件属主和当前登录用户不一致。

原因

git 2.35.2 起引入的安全机制(修复 CVE-2022-24765 等恶意仓库攻击):仓库所在目录的属主若与当前用户不一致,git 拒绝执行——防止攻击者构造的 .git/config(含自定义命令钩子)在别的用户环境里被意外信任执行。属主不一致的常见来源:

1. **NTFS/exFAT 等挂载盘**:文件系统不支持 POSIX 属主,盘上所有文件在 Linux 眼里都显示为挂载用户(通常是 root),chown 改了也不生效——双系统用户最典型;

2. **多用户共享目录**:别人(或 root)建的仓库,你直接访问;

3. **U 盘/压缩包拷贝**:保留的是原机器的 uid/gid,与当前机器对不上。

解法

按推荐顺序选:

1. **safe.directory 白名单(最通用,挂载盘也有效)**:照错误提示执行 `git config --global --add safe.directory <仓库绝对路径>`。注意:白名单**按目录登记、不递归**——同盘其他仓库还要再 add 一次;仓库很多时可用 `git config --global --add safe.directory '*'` 全局信任(省事但信任所有目录,不推荐在共享机器上用)。

2. **chown 改属主(仅 Linux 文件系统)**:`sudo chown -R $(id -u):$(id -g) <仓库路径>`。对 NTFS/exFAT 挂载盘无效(文章作者实测无效),挂载盘请用方案 3 或 1。

3. **双系统 NTFS 挂载源头修复**:让整个盘固定属主为你的用户。编辑 /etc/fstab 在挂载项加 `uid=1000,gid=1000`(1000 换成 `id <用户名>` 查到的值)后重启;或 Ubuntu 磁盘工具里关闭默认挂载选项、在挂载参数里加同样的 uid/gid。这样盘上所有仓库天然属主一致,不再报错。

4. 只想临时看一眼:直接读文件不跑 git 命令;或把仓库重新 clone 到自己目录下(新 clone 属主就是你自己)。

验证证据

- 本地实测(2026-08-29,WSL Ubuntu,git 2.53.0):

- root 建仓库并提交,改用 nobody 用户访问 → 完整复现 `fatal: detected dubious ownership in repository at '/tmp/dubious-repo'` + 白名单提示,退出码 128,与文章报错逐字一致;

- 修复 A:nobody 执行 `git config --global --add safe.directory /tmp/dubious-repo` → 再次 git status/log 成功(退出码 0);

- 修复 B:`chown -R nobody:nogroup` 仓库后不配白名单直接访问 → 成功(退出码 0,证明 Linux 文件系统上 chown 有效);

- 对照组:白名单只覆盖已登记的目录——在登记目录下新建子仓库仍报同样错误,证明「逐个登记、不递归」;

- NTFS 挂载 uid/gid 方案本机无 NTFS 挂载盘,未能实测(文章作者实测有效,属于环境源头修复)。

- 实测复现日志(2026-08-29)

来源与证据

素材来源:https://www.cnblogs.com/lusa/p/18489485

验证证据:Evidence details kept locally (2026-08-29)