Ошибка Git: невозможно добавить в .git / logs / refs / remotes / origin / master: в разрешении отказано

87

У меня странная проблема, которую я не могу решить. Вот что случилось:

У меня были файлы журналов в репозитории github, которые мне там не нужны. Я нашел этот скрипт, который полностью удаляет файлы из истории git, например:

    #!/bin/bash
set -o errexit

# Author: David Underhill
# Script to permanently delete files/folders from your git repository.  To use 
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2

if [ $# -eq 0 ]; then
    exit 0are still
fi

# make sure we're at the root of git repo
if [ ! -d .git ]; then
    echo "Error: must run this script from the root of a git repository"
    exit 1
fi

# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD

# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all &&  git gc --aggressive --prune

Я, конечно, сначала сделал резервную копию, а потом попробовал. Казалось, все работает нормально. Затем я сделал git push -f и получил следующие сообщения:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.

Кажется, что все прошло нормально, потому что файлы, похоже, исчезли из репозитория GitHub, если я попытаюсь нажать еще раз, я получу то же самое:

error: Unable to append to .git/logs/refs/remotes/origin/master: Permission denied
error: Cannot update the ref 'refs/remotes/origin/master'.
Everything up-to-date

РЕДАКТИРОВАТЬ

$ sudo chgrp {user} .git/logs/refs/remotes/origin/master
$ sudo chown {user} .git/logs/refs/remotes/origin/master
$ git push
Everything up-to-date

Благодарность!

РЕДАКТИРОВАТЬ

Ух Ой. Проблема. Я работал над этим проектом всю ночь и просто пошел фиксировать свои изменения:

error: Unable to append to .git/logs/refs/heads/master: Permission denied
fatal: cannot update HEAD ref

Так что я:

sudo chown {user} .git/logs/refs/heads/master
sudo chgrp {user} .git/logs/refs/heads/master

Я пытаюсь выполнить коммит еще раз и получаю:

error: Unable to append to .git/logs/HEAD: Permission denied
fatal: cannot update HEAD ref

Так что я:

sudo chown {user} .git/logs/HEAD
sudo chgrp {user} .git/logs/HEAD

А потом снова пытаюсь выполнить коммит:

16 files changed, 499 insertions(+), 284 deletions(-)
create mode 100644 logs/DBerrors.xsl
delete mode 100644 logs/emptyPHPerrors.php
create mode 100644 logs/trimXMLerrors.php
rewrite public/codeCore/Classes/php/DatabaseConnection.php (77%)
create mode 100644 public/codeSite/php/init.php
$ git push
Counting objects: 49, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (27/27), done.
Writing objects: 100% (27/27), 7.72 KiB, done.
Total 27 (delta 15), reused 0 (delta 0)
To git@github.com:IAmCorbin/MooKit.git
59da24e..68b6397  master -> master

Ура. Я захожу на http://GitHub.com и проверяю репозиторий, а мою последнюю фиксацию нигде не найти. :: царапина :: я снова нажимаю:

Everything up-to-date

Эмм ... не похоже. У меня никогда раньше не было этой проблемы, может ли это быть проблемой с github? или я что-то испортил с моим проектом git?

РЕДАКТИРОВАТЬ

Да ладно, я сделал простое:

git push origin master

и толкнул нормально.

Корбин Таррант
источник

Ответы:

216

Похоже, вы запустили git локально как root, тем самым сменив владельца на некоторые файлы, отслеживающие расположение originветки.

Исправьте право собственности на файл, и все будет в порядке:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .
Чарльз Даффи
источник
1
Эта команда сработала для меня. Я запустил его из корня клона. Спасибо @CharlesDuffy!
ariestav
4
@ Mr.Stranger, только если у вас есть нормальное значение IFS и имя пользователя (имена пользователей с пробелами могут встречаться, например, на cygwin). Проще цитировать: sudo chown -R "$USER" .и не предполагать вменяемости. :)
Чарльз Даффи
@ Mr.Stranger ... также USERне гарантируется pubs.opengroup.org/onlinepubs/009695399/utilities/… , поэтому его использование может быть безопаснее "$(id -un)".
Чарльз Даффи
Там написано, что мой пользователь is not in the sudoers file. This incident will be reported.- какие-нибудь советы о том, что я могу сделать? Спасибо.
giovannipds
1
Синтаксис выше - это расширение параметра ; "${var:-default}"расширяется до значения переменной "$var", если это значение не пусто или не установлено, и в этом случае оно разрешается в default. Таким образом, мы либо расширяемся до "$USER", либо вывод, генерируемый запуском id -un.
Charles Duffy
4

Сконцентрируемся на том, на что именно он жалуется:

Ошибка отказа в разрешении: невозможно обновить ссылку «refs / remotes / origin / master».

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

Я думаю, что я вызвал эту проблему, создав ветку, когда был пользователем root, а затем попытался возиться с этой веткой как мой пользователь.

Эндрю Э
источник
3
Действительно ли исправление файлов, принадлежащих кому-либо, кроме пользователя, который, как ожидается, будет владеть всем деревом исходных текстов один за другим, действительно улучшением?
Чарльз Даффи
2

В моем случае я создал файлы с правами root локально и попытался отправить код на удаленный компьютер с локальными разрешениями. Итак, я выполнил эту команду

$find . -user root

чтобы узнать, у каких файлов есть "root" в качестве владельца. А затем я сменил владельца для всех файлов, находящихся под root, на локальный, используя следующую команду

$sudo chown parineethat `find . -user root`

Затем я смог перенести свой код с локального на удаленный.

Паринита
источник
sudo chown parineethat `find . -user root` ненадежно - не будет работать с именами файлов с пробелами. Вместо этого sudo find . -user root -exec chown parineethat {} +. См. Соответствующее обсуждение BashPitfalls # 1 .
Чарльз Даффи
1

Это рекурсивно изменит все ваши файлы .git и каталоги (от root до 1000) и предоставит вам полный список всех изменений, сделанных в терминале.

sudo chown -Rc $ UID .git /

Дональд Л. Уилсон
источник
0

Я пытался исправить право собственности на Git, но это все равно не работает.

Но мне удалось это исправить, создав локальную ветку с другим именем и удалив ее.

Затем я снова проверяю то же имя ветки, и оно работает.

TL; DR;

Я не могу проверить `staging / rc '.

Итак, я проверяю, используя stagingвместо этого, что пульт указывает на `staging / rc '.

И я удаляю его и снова оформляю заказ. Но на этот раз я использую имя staging/rcсвоего местного филиала.

Это работает, и я понятия не имею, почему.

Морган Ко
источник
-16

Пожалуйста, сначала предоставьте разрешения из rootучетной записи, как показано ниже

chmod -R 777 foldername

после этого запустите команду фиксации

Виру
источник
7
Это чрезвычайно опасно - это дает любой учетной записи в системе, в том числе скомпрометированному демону только с привилегиями «никто», доступ на запись к вашим файлам. Системные демоны используют «none» (или другие непривилегированные учетные записи) для чувствительных к безопасности компонентов, потому что учетная запись none не должна делать что-либо слишком рискованное, даже если она взломана. Предоставляя всем пользователям, даже никому, доступ на запись к вашим файлам, вы делаете важные меры безопасности бесполезными.
Чарльз Даффи,
1
Если по какой-то причине вы хотите, чтобы ваши файлы принадлежали пользователю root и были доступны для записи определенному пользователю без полномочий root, безопасный способ сделать это (в системе, где каждый пользователь имеет свою собственную группу, что является стандартной практикой) состоит в следующем chown -R root:user directory: затем chmod -R 775 directory(или 770, если другие учетные записи также не нуждаются в доступе для чтения).
Чарльз Даффи
1
@JasonGlisson, то, что «работает» только путем создания массивных дыр в безопасности, вероятно, лучше бы не использовать.
Чарльз Даффи,
1
@JasonGlisson, поскольку мы даем советы как сообществу, так и сообществу, как член этого сообщества, я занимаюсь не только своими советами, но и тем, кто работает в сфере безопасности. , У меня есть все основания, чтобы прокомментировать эту тему. См. Первоначальный комментарий, re: impact.
Чарльз Даффи
1
@JasonGlisson, ... что касается того, почему мой совет не сработал для вас, мне нужно увидеть подробности - журнал выполненных команд по порядку с подсказкой, показывающей текущий рабочий каталог перед каждой; текст выданных ошибок; и т. д. - для комментирования; но место для этого обсуждения будет прикреплено к ответу, для которого вы сообщаете о плохих результатах, а не здесь.
Чарльз Даффи