Помилка 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.- будь-яка порада про те, що я можу зробити? Дякую.
Джованніпдс

1
Синтаксис вище - розширення параметрів ; "${var:-default}"розширюється до значення змінної "$var", якщо це значення не є порожнім або не встановленим, і в цьому випадку воно вирішується до default. Таким чином, ми або розширюємось до "$USER", або вихід, генерований запуском id -un.
Чарльз Даффі

3

Зупинимося на тому, на що саме він скаржиться:

Помилка відмови у дозволі: Не вдається оновити посилання 'refs / remotes / origin / master'.

Перш ніж виконувати рекурсивні зміни мода / власності, пройдіть шлях до цього файлу та виправте неправильні дозволи.

Я думаю, що я спричинив цю проблему, створивши гілку, будучи коренем, а потім спробувавши зіпсувати цю гілку як свого користувача.


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 рекурсивно (від кореневого до 1000) і дасть вам повний перелік усіх змін, внесених у терміналі.

sudo chown -Rc $ UID .git /


0

Я намагався виправити право власності на Git, але це все одно не працює.

Але мені вдалося це виправити, створивши локальну гілку з іншою назвою та видалити.

Потім я знову перевіряю ту саму назву гілки, і вона працює.

TLDR;

Я не можу замовити `staging / rc '.

Отже, я перевіряю, використовуючи stagingзамість цього, що пульт вказує на `staging / rc '.

І я видаляю це і перевіряю знову. Але цього разу я використовую staging/rcяк назву місцевої філії.

Це працює, і я не уявляю, чому.


-16

Спочатку надайте дозволи з rootоблікового запису, як показано нижче

chmod -R 777 foldername

після цього запустіть команду коміту


7
Це надзвичайно небезпечно - це дає будь-якому обліковому запису в системі, включаючи зламаний демон з лише привілеями "ніхто", доступ до записів до ваших файлів. Системні демони використовують "ніхто" (або інші непривілейовані облікові записи) для компонентів, що вразливі до безпеки, оскільки цей обліковий запис не повинен робити що-небудь занадто ризиковане, навіть якщо воно скомпрометоване. Дозволяючи всім користувачам, навіть нікому, мати доступ до записів до ваших файлів, ви робите необхідні заходи безпеки марними.
Чарльз Даффі,

1
Якщо з якихось причин ви хотіли, щоб ваші файли належали кореневим особам та могли бути записані певним некореневим користувачем, безпечним способом це зробити (у системі, де кожен користувач має власну групу, як це прийнято у звичайній практиці) є chown -R root:user directoryта потім chmod -R 775 directory(або 770, якщо інші облікові записи не потребують доступу для читання).
Чарльз Даффі

1
@JasonGlisson, щось, що "працює", лише створюючи масивні діри в безпеці, - це, мабуть, те, що було б краще залишатися зламаним.
Чарльз Даффі

1
@JasonGlisson, оскільки ми надаємо поради як спільноті, так і громаді, як члену цієї спільноти, які та якісні поради ми надаємо - це мій бізнес, як і будь-хто інший - і як хтось, хто працює в галузі безпеки , Я маю можливість коментувати цю тему. Див. Початковий коментар, re: impact.
Чарльз Даффі

1
@JasonGlisson, ... щодо того, чому моя порада для вас не спрацювала, мені потрібно було б побачити деталі - журнал запущених команд, по порядку, з підказкою, що показує поточний робочий каталог перед кожною; текст випущених помилок; тощо - для того, щоб коментувати; але місце для цієї дискусії буде додано до відповіді, щодо якої ви повідомляєте про погані результати, на відміну від тут.
Чарльз Даффі
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.