Git: невозможно индексировать файл - разрешено отклонение

Только для одного файла возникает следующая ошибка:

error: unable to write sha1 filename /opt/www/.git/objects/3f/ce3587c54a8be14c69b08c6b01f94949b11b47: Permission denied

error: wp/wp-admin/css/theme-install.dev.css: failed to insert into database
fatal: unable to index file wp/wp-admin/css/theme-install.dev.css

Я проверил свои разрешения на соответствующий файл, .git каталог объектов и .git. Я могу добавить любые другие файлы, кроме этого. Я мог бы stat/r/w/touch файл, и прикосновение не помогло. Разрешения верны.

Это какая-то сумасшедшая ошибка?

Ответы

Ответ 1

Глядя на исходный код Git (sha1_file.c, function move_temp_to_file()), похоже, что Git не может переименовать временный файл с именем /opt/www/.git/objects/3f/tmp_obj_XXXXXX (где XXXXXX - шесть случайных символов) до /opt/www/.git/objects/3f/ce3587c54a8be14c69b08c6b01f94949b11b47. Это может произойти, если у вас нет разрешения на удаление файлов в /opt/www/.git/objects/3f.

Некоторые вещи, которые нужно попробовать:

  • Если несколько пользователей обращаются к репозиторию Git, вам может потребоваться выполнить что-то вроде git config core.sharedRepository 0664 (подробнее см. git help config), чтобы убедиться, что вновь созданные каталоги и файлы имеют соответствующие разрешения для всех пользователей репозитория.
  • Попробуйте запустить rm -f /opt/www/.git/objects/3f/tmp_obj_* и убедитесь, что проблема устранена.

  • Посмотрите, можете ли вы воспроизвести проблему за пределами Git, выполнив следующие действия:

    mkdir -p /opt/www/.git/objects/3f
cd /opt/www/.git/objects/3f
rm -f tmp_obj_* ce3587c54a8be14c69b08c6b01f94949b11b47
echo "testing" >tmp_obj_abcdefg
mv tmp_obj_abcdef ce3587c54a8be14c69b08c6b01f94949b11b47
rm -f tmp_obj_abcdefg

    Обязательно запустите указанные выше команды тем же пользователем, у кого возникла ошибка.

  • Попробуйте рекурсивно chown ing и chmod в каталоге объектов.

Ответ 2

Если вы используете Visual Studio или что-то подобное, генерирующее файл mdf, просто закройте VS и повторите команду git снова. На этот раз это должно сработать.

Чтобы сохранить закрытие и повторное открытие, вы должны добавить ссылки в файл .gitignore в корне проекта. Например, если это база данных, вызывающая проблему, добавьте следующее:

# SQL Server files
*.mdf
*.ldf

Ответ 3

У вас нет разрешения на запись в /opt/www/.git/objects/3f.

Самое быстрое решение - использовать команду sudo для выполнения вашей команды с правами root.

sudo <Your git command>

Решил это для меня.

Ответ 4

Что-то пошло не так в вашем git-репозитории, вероятно, из-за того, что внешний процесс создал файл или каталог, принадлежащий другому пользователю, а не текущему.

Эта ошибка часто встречается при использовании Docker, а служба в вашем файле docker-compose.yml имеет локально смонтированный том, который был создан с использованием пользователя, отличного от пользователя локального компьютера.

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

sudo chown -R ${USER}:${USER} .

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

Безусловно, самое быстрое решение - выполнить следующее из корневого каталога проекта, в котором находится ваш git-репозиторий:

sudo chown -R ${USER}:${USER} .git/objects

Чтобы проверить, что все исправлено, выполните следующее:

git add .

Быстро с последующим выполнением:

git status

Вы увидите, что все было добавлено в репозиторий git без необходимости что-либо тестировать/возиться.

Ответ 5

Просто закройте Visual Studio (или Unity) и попробуйте добавить эти файлы снова.

Ответ 6

У меня была эта проблема в моем репозитории с исходным кодом, когда права были root: git 770, по-видимому, мне пришлось изменить его на 771, даже если мой пользователь находится в группе git. Я подозреваю, что, возможно, git, возможно, либо не знает ACL, либо не совместим со вторичными группами, так как в этом случае группа Git была одной из моих вторичных групп.