Git hatası: .git / logs / refs / remotes / origin / master'a eklenemiyor: İzin reddedildi


87

Çözemediğim garip bir sorun yaşıyorum. İşte olanlar:

Bir github deposunda, orada olmasını istemediğim bazı günlük dosyalarım vardı. Dosyaları git geçmişinden tamamen kaldıran bu komut dosyasını buldum:

    #!/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

Tabii önce bir yedekleme yaptım ve sonra denedim. İyi çalışıyor gibiydi. Daha sonra git push -f yaptım ve aşağıdaki mesajlarla karşılandım:

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

Yine de her şey yolunda gitmiş gibi görünüyor, çünkü dosyalar GitHub deposundan gitmiş gibi görünüyor, eğer tekrar denersem ve basarsam aynı şeyi elde ederim:

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

DÜZENLE

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

Teşekkürler!

DÜZENLE

Uh Oh. Sorun. Bütün gece bu proje üzerinde çalıştım ve değişikliklerimi yapmaya gittim:

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

Yani ben:

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

İşlemi tekrar deniyorum ve şunu elde ediyorum:

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

Yani ben:

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

Ve sonra işleme işlemini tekrar deniyorum:

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

Yaşasın. Ben atlamak http://GitHub.com ve depo kontrol ve yerde bulunabilir benim son taahhüt hayırdır. :: kazı kazan :: Bu yüzden tekrar itiyorum:

Everything up-to-date

Umm ... öyle görünmüyor. Bu sorunu daha önce hiç yaşamadım, bu github ile ilgili bir sorun olabilir mi? yoksa git projemle bir şeyler mi karıştırdım?

DÜZENLE

Boşver, basit bir şey yaptım:

git push origin master

ve iyi itti.

Yanıtlar:


219

Görünüşe göre git'i yerel olarak root olarak çalıştırmışsınız, bu nedenle originşubenin konumunu izleyen bazı dosyaların sahipliğini değiştirmişsiniz .

Dosya sahipliğini düzeltin ve iyi olmalısınız:

# run this from the root of the git working tree
sudo chown -R "${USER:-$(id -un)}" .

1
Bu komut benim için çalıştı. Onu klonun kökünden çalıştırdım. Teşekkürler @CharlesDuffy!
ariestav

4
@ Bay Stranger, yalnızca mantıklı bir IFS değeriniz ve kullanıcı adınız varsa (boşluklu kullanıcı adları, örneğin cygwin'de olabilir). Alıntı yapmak daha güvenli: sudo chown -R "$USER" .ve akıl sağlığını varsaymayın. :)
Charles Duffy

@ Bay Stranger, ... ayrıca, pubs.opengroup.org/onlinepubs/009695399/utilities/…USER tarafından garanti edilmez , bu nedenle kullanımı daha güvenli olabilir "$(id -un)".
Charles Duffy

Kullanıcım is not in the sudoers file. This incident will be reported.- yapabileceklerim hakkında herhangi bir ipucu var mı? Teşekkürler.
giovannipds

1
Yukarıdaki sözdizimi, parametre genişletmedir ; "${var:-default}"değişken değere genişler "$var", sürece bu değer bu durumda giderir, boş veya ayarlanmadan default. Böylece, ya genişleriz "$USER"ya da çalıştırılarak üretilen çıktı id -un.
Charles Duffy

4

Tam olarak neyle ilgili şikayet ettiğine odaklanalım:

İzin verilmedi hatası: Ref 'refs / remotes / origin / master' güncellenemiyor.

Özyinelemeli mod / sahiplik değişiklikleri yapmadan önce, o dosyaya gidin ve yanlış olan tüm izinleri düzeltin.

Sanırım bu soruna root iken bir şube oluşturarak ve ardından kullanıcım olarak o şubeyi karıştırmaya çalışarak neden oldum.


3
Kullanıcıdan başka herhangi birinin sahip olduğu dosyaların tek tek tüm kaynak ağacına sahip olması beklenen dosyaları düzeltmek gerçekten bir gelişme mi?
Charles Duffy

2

Benim durumumda, dosyaları yerel olarak kök izniyle oluşturdum ve kodu yerel izinlerle uzaklara göndermeyi denedim. Ben de bu komutu çalıştırdım

$find . -user root

tüm dosyaların sahip olarak "root" a sahip olduğunu bulmak için. Ve sonra aşağıdaki komutu kullanarak kök altındaki tüm dosyaların sahibini yerel olarak değiştirdim

$sudo chown parineethat `find . -user root`

Sonra kodumu yerelden uzaklığa aktarabildim.


sudo chown parineethat `find . -user root` güvenilmezdir - boşluk içeren dosya adlarında doğru çalışmaz. Bunun yerine sudo find . -user root -exec chown parineethat {} +,. İlgili tartışma için BashPitfalls # 1'e bakın .
Charles Duffy

1

Bu, tüm .git dosyalarınızı ve dizinlerinizi özyinelemeli olarak değiştirecek (kökten 1000'e) ve size terminalde yapılan tüm değişikliklerin tam bir listesini verecektir.

sudo chown -Rc $ UID .git /


0

Git'in sahipliğini düzeltmeyi denedim ama yine de çalışmıyor.

Ancak yerel şubeyi farklı bir isimle oluşturup silerek düzeltmeyi başardım.

Sonra aynı şube adını tekrar kontrol ediyorum ve işe yarıyor.

TLDR;

`` Staging / rc '' yi kontrol edemiyorum.

Bu yüzden, staginguzaktan kumandanın `` staging / rc '' yi işaret ettiğini kullanarak kontrol ediyorum .

Ve onu silip tekrar kontrol ediyorum. Ama bu sefer staging/rcyerel şube adım olarak kullanıyorum.

Çalışıyor ve nedenini bilmiyorum.


-16

Lütfen önce rootaşağıdaki gibi hesaptan izinleri verin

chmod -R 777 foldername

bundan sonra commit komutunu çalıştırın


7
Bu son derece tehlikelidir - yalnızca "hiç kimse" ayrıcalıklarına sahip güvenliği ihlal edilmiş bir daemon da dahil olmak üzere sistemdeki herhangi bir hesaba dosyalarınıza yazma erişimi sağlar. Sistem arka plan programları, güvenliğe duyarlı bileşenler için "hiç kimseyi" (veya diğer ayrıcalıksız hesapları) kullanır, çünkü kimse hesabının güvenliği ihlal edilse bile çok riskli bir şey yapamayacağı varsayılır. Tüm kullanıcıların, hatta hiç kimsenin dosyalarınıza yazma erişimine sahip olmasına izin vererek, temel güvenlik önlemlerini gereksiz hale getiriyorsunuz.
Charles Duffy

1
Herhangi bir nedenle dosyalarınızın köke ait olmasını ve belirli bir kök olmayan kullanıcı tarafından yazılabilir olmasını istiyorsanız, bunu yapmanın güvenli yolu (standart uygulamada olduğu gibi her kullanıcının kendi grubuna sahip olduğu bir sistemde) chown -R root:user directoryve daha sonra chmod -R 775 directory(veya 770diğer hesapların da okuma erişimine ihtiyacı yoksa).
Charles Duffy

1
@JasonGlisson, yalnızca büyük güvenlik açıkları oluşturarak "çalışan" bir şey muhtemelen bozuk kalmaktan daha iyi olacak bir şeydir.
Charles Duffy

1
@JasonGlisson, hem bir topluluk olarak hem de o topluluğun bir üyesi olarak tavsiyelerde bulunduğumuz için, ne tür ve kaliteli tavsiyeler verdiğimiz, başkaları kadar benim de işimdir - ve güvenlik alanında çalışan biri olarak , Konu hakkında yorum yapmak için iyi konumdayım. İlk yorumu görün, re: effect.
Charles Duffy

1
@JasonGlisson, ... tavsiyemin sizin için neden işe yaramadığına gelince, ayrıntıları görmem gerekiyor - sırayla çalıştırılan komutların günlüğü, her birinden önce mevcut çalışma dizinini gösteren bir komut istemi; yayılan hataların metni; vb - yorum yapmak için; ancak bu tartışmanın yeri, buradaki yerine kötü sonuçları bildirdiğiniz cevaba eklenecektir.
Charles Duffy
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.