git pull на сервере падает с permission denied: как исправлять без хаоса

Ошибка permission denied при git pull на сервере почти всегда связана с правами: репозиторий принадлежит одному пользователю, деплой выполняется другим, часть файлов создана от root, а директория .git недоступна для записи. В итоге обычное обновление превращается в ручную чистку прав.

Исправлять это нужно системно. Разовый chmod 777 может убрать ошибку на минуту, но создаст риск безопасности и вернёт проблему при следующем деплое.

Понять текущего пользователя

Сначала нужно понять, от кого выполняется git pull.

whoami
pwd
git status

Если команда запускается из CI, cron или панели хостинга, пользователь может отличаться от того, под которым вы подключились по SSH.

Проверить владельца файлов

В корне проекта нужно посмотреть владельцев файлов и директории .git.

ls -la
ls -la .git
find . -maxdepth 2 -user root | head

Если .git принадлежит root, а деплой выполняется от deploy, git не сможет обновить служебные файлы.

Типовая причина: команды от root

Проблема часто появляется после ручного исправления:

sudo git pull
sudo composer install

После этого часть файлов становится владельцем root. Следующий обычный деплой падает.

Выбрать deploy user

Лучше иметь отдельного пользователя для деплоя. Он владеет кодом проекта и выполняет git pull, composer install, миграции и очистку кэша. Веб-сервер при этом получает права только на нужные writable-директории.

deploy:www-data

Схема зависит от сервера, но принцип один: не смешивать хаотично root, веб-пользователя и личные аккаунты разработчиков.

Исправить владельца проекта

Пример для проекта, где кодом владеет deploy, а группа веб-сервера — www-data:

sudo chown -R deploy:www-data /var/www/site.ru

После этого права можно привести к более аккуратному виду:

find /var/www/site.ru -type d -exec chmod 755 {} \;
find /var/www/site.ru -type f -exec chmod 644 {} \;

Для runtime, uploads, cache и других writable-директорий нужны отдельные права на запись группе.

chmod -R ug+rw runtime web/assets web/uploads

Не ломать writable-директории

После общей нормализации прав сайт может потерять возможность писать кэш, логи или загруженные файлы. Поэтому отдельно проверяют директории, куда пишет PHP.

ls -la runtime
ls -la web/assets
ls -la web/uploads

Если cron выполняется от другого пользователя, он тоже должен иметь корректные права или запускаться от deploy.

Проверить safe.directory

В новых версиях Git может появиться ошибка dubious ownership. Она не равна permission denied, но часто возникает рядом с проблемами владельца.

git config --global --add safe.directory /var/www/site.ru

Эту команду не стоит использовать как способ игнорировать неправильные права. Сначала нужно понять, почему владелец репозитория отличается.

SSH-ключи

Если permission denied относится не к файлам, а к доступу к репозиторию, нужно проверить SSH-ключ пользователя деплоя.

ssh -T git@github.com
ssh -T git@gitlab.com

Проверять нужно именно от того пользователя, который делает git pull.

Чек-лист

1. Проверить whoami перед git pull.
2. Проверить владельца .git и файлов проекта.
3. Найти файлы, созданные root.
4. Выбрать одного deploy user.
5. Настроить владельца и группу проекта.
6. Отдельно выдать запись на runtime, cache, uploads.
7. Проверить SSH-ключи пользователя деплоя.
8. Не использовать chmod 777 как постоянное решение.

Стабильный деплой начинается с понятной модели пользователей. Если git, Composer, cron и веб-сервер работают каждый от своего случайного владельца, permission denied будет возвращаться снова.