#Что означает проблема
Git из соображений безопасности может отказаться читать локальную конфигурацию и операции в репозитории, который принадлежит другому пользователю. На сервере это часто случается после загрузки файлов от root, деплоя разными учётными записями или запуска через sudo. Сообщение не означает, что нужно отключать защиту Git глобально: сначала выясните владельца каталога и контекст запуска.
#Как отличить причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Команду запускает другой пользовательФайлы принадлежат отдельной учётной записи деплоя, но Git работает от пользователя службы. | id -un и stat показывают разные имена/UID. | Использовать штатную учётную запись владельца. |
| После копирования изменился владелецРепозиторий скопировали с правами root либо восстановили из архива под другим UID. | ls -ld показывает владельца, не совпадающего с владельцем сайта. | Проверить назначение каталога и исправить владение по утверждённой схеме. |
| Репозиторий общий по правилам командыКаталог намеренно доступен нескольким доверенным учётным записям. | Системный администратор подтверждает общую папку и владельца. | Добавить точный безопасный путь для конкретного пользователя, а не *. |
#Пошаговая диагностика и решение
- Остановите операции записи и запомните текст отказаНа Linux-сервере подключитесь по SSH обычной учётной записью с доступом к проекту. Убедитесь, что запускаемая команда действительно выводит
fatal: detected dubious ownership in repository at .... Не запускайте её повторно сsudoавтоматически: это может создать новые root-файлы и изменить владельцев. Запишите абсолютный путь репозитория из ошибки. Перед остальными командами выполнитеgit --version: в ответ должна появиться установленная версия Git. Если терминал сообщает, чтоgitне найден, проверьте установку Git и доступность команды в этом терминале; не продолжайте операции наугад. - Проверьте, кто выполняет командыВ том же SSH-терминале выполните
id -unиid -u. Первая команда показывает имя, вторая — UID. Если деплой запускается через systemd/CI, посмотрите в разрешённых конфигурационных файлах имя пользователя службы и сравните: ошибка может возникать только там, а при ручном входе — исчезать. Администратор здесь не требуется. - Проверьте владельца каталога и .git без изменения правПерейдите в родительский каталог проекта обычной командой
cd, затем выполнитеls -ld ПУТЬ_К_ПРОЕКТУ ПУТЬ_К_ПРОЕКТУ/.git, подставив реальные абсолютные пути. Проверьте владельца и группу в столбцах списка. Если.gitявляется файлом (в worktree или подмодуле), сначала прочитайте его безопасно и определите фактическое расположение служебных данных, не исправляйте владельца вслепую. - Выберите предпочтительный вариант: правильный пользовательЕсли каталог принадлежит учётной записи
deploy, согласуйте с администратором запуск операций Git от неё, а не от веб-сервера и не от root. В панели управления сервером или конфигурации задания CI измените пользователя штатным способом. После этого повторитеgit statusот того же пользователя. Не используйте один аккаунт сайта для всех проектов только ради удобства. - Для общего доверенного репозитория добавьте только точный путьЕсли администратор подтвердил, что репозиторий безопасен, под учётной записью, которой нужен Git, выполните
git config --global --add safe.directory /srv/project, заменив/srv/projectна ТОЧНЫЙ абсолютный путь из ошибки. Это настройка доверия только для этого пользователя; добавлятьsafe.directory=*опасно. Если путь содержит пробелы, заключите его в кавычки. - Проверьте эффект и убедитесь, что доступ не стал ширеВыполните
git config --global --get-all safe.directoryи убедитесь, что там только согласованные пути. Затемgit -C /srv/project status -sbс вашим путём. Если отказ сохранился, проверьте, от какой учётной записи реально запускается Git и не переопределяет ли команда параметрHOME; не выдавайте Git общесистемное доверие всем каталогам. - Отмените временное доверие, когда оно больше не нужноПод той же учётной записью выполните
git config --global --unset-all safe.directory /srv/projectс реальным путём только после проверки, что эта запись была создана вами и её не используют другие процессы. Проверьте список повторно. Если в конфигурации были дубликаты или права каталогов нетипичны, обсудите с администратором вместо массовой смены владельца.
#Команды для проверки и исправления
Linux · Терминал (Bash)Команда
Команды Linux: первая печатает имя текущего пользователя, вторая UID. Нужен обычный SSH-сеанс.
id -unid -uLinux · Терминал (Bash)Команда
Пример пути
/srv/project, замените его реальным абсолютным путём; команда только показывает владельцев и права.ls -ld /srv/project /srv/project/.gitLinux · Терминал (Bash)С осторожностью
Для заведомо доверенного репозитория. Замените путь.
--global относится к текущему пользователю, а не всем пользователям сервера. Риск средний: уменьшает защиту ТОЛЬКО для конкретного каталога.git config --global --add safe.directory /srv/projectКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
Linux · Терминал (Bash)Команда
Проверьте список доверенных каталогов и состояние репозитория; путь в
-C замените своим.git config --global --get-all safe.directorygit -C /srv/project status -sbLinux · Терминал (Bash)С осторожностью
Снимает доверие к данному точному пути для текущего пользователя. Используйте только если больше никто не зависит от этой настройки.
git config --global --unset-all safe.directory /srv/projectКоманда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.
#Как проверить результат и что делать, если не помогло
Успех подтверждают вывод git status -sb без ошибки владения и отсутствие сомнительных путей в safe.directory. Если Git по-прежнему отказывается работать, нужна проверка реальной учётной записи службы, вложенного репозитория, worktree и разрешений — не пытайтесь исправлять все каталоги командой chown -R без точной инвентаризации.