在VPS上执行git status、部署脚本或CI任务时，Git可能提示detected dubious ownership in repository并拒绝继续。这个检查用于阻止当前用户读取和执行由其他账户控制的仓库配置与钩子。
先确认仓库为何属于另一个用户，再决定修复属主还是建立受控例外。
dubious ownership为什么会出现
Git官方说明，默认只允许用户访问自己拥有的仓库；仓库所有者与当前Git进程身份不一致时，Git甚至不会解析该仓库的配置。常见场景包括用root解压代码后改由部署用户运行、挂载共享目录、CI工作目录复用，以及容器内外UID不一致。
这不是普通读写权限不足，也不能只靠chmod解决。目录可读并不等于其所有者可信。
先核对用户与目录属主
使用id确认实际运行用户，再执行stat -c '%U %G %u %g %n' /srv/app /srv/app/.git查看仓库与元数据目录的所有者。若命令由systemd、cron或CI执行，还要查看服务的User=、计划任务账户和容器内UID。
运行git config --show-origin --get-all safe.directory检查现有例外来自哪个配置文件。不要在未确认仓库来源时直接把报错路径加入信任列表。
按最小范围修复
如果仓库本应由当前部署账户独占，先停止相关任务，在确认路径无误后使用chown -R deploy:deploy /srv/app恢复正确属主。共享仓库确有业务需要时，可由对应用户执行git config --global --add safe.directory /srv/shared/repo，只加入明确的绝对路径。
优先修正错误所有权；safe.directory只用于有意共享且边界清楚的仓库。修改后再次用--show-origin确认生效范围。
为什么不建议配置星号
Git允许把safe.directory设置为*以完全关闭所有权检查，但官方文档明确把它描述为退出该安全机制。多用户VPS、托管构建机和会运行第三方代码的节点尤其不应这样配置。
不要为了省事执行git config --global --add safe.directory "*"。若历史配置已经放宽，应先清空列表，再逐个加入经过核实的仓库。
修复后的验收标准
用与生产任务相同的账户运行git status、git config --local --list和一次只读拉取测试，并确认父目录没有意外的可写权限。可在萤光云或LightNode的隔离VPS复现UID与挂载场景。验收标准是报错消失、仓库属主符合设计、信任列表只包含必要路径，部署任务无需切换到root。
FAQ
问：sudo git就能绕过问题吗？答：不应把sudo当长期修复。Git在非Windows平台还会考虑SUDO_UID，而以root运行可能制造新的属主和安全问题。
问：chmod 777可以解决吗？答：不能可靠解决所有者校验，还会扩大写入面。
问：每个用户都要配置safe.directory吗？答：配置只在受保护配置范围内生效，应由实际运行Git的账户按需要设置。
问：容器里UID不同怎么处理？答：应优先统一挂载目录与容器用户的UID/GID，确需共享时再加入精确路径。
问：可以信任整个父目录吗？答：Git支持特定目录形式，但共享范围越大风险越高，应尽量信任单个仓库。
温馨提示
温馨提示：部署目录的所有者、运行账户和写入权限应纳入发布清单。镜像、备份或迁移恢复后，先核对UID/GID映射，再运行Git自动化。
