Git Push Error: havuz veritabanına nesne eklemek için yetersiz izin

Paylaşılan bir git uzaktan kumandasına aktarmaya çalıştığımda, aşağıdaki hatayı alıyorum: insufficient permission for adding an object to repository database

Sonra burada bir düzeltme hakkında okudum: Düzelt Tüm dosyalar doğru gruba ait olduğu için bir sonraki push için çalıştı, ancak bir dahaki sefere birisi bir değişiklik yaptığında varsayılan klasörleri olan nesneler klasöründe yeni bir öğe yaptı grup olarak. Düşünebildiğim tek şey, geliştiricinin varsayılan grubunu kontrol ettikleri öğeler için değiştirmektir, ancak bu bir hack gibi görünüyor. Herhangi bir fikir? Teşekkürler.

Onarım İzinleri

Temel nedeni belirledikten ve düzelttikten sonra (aşağıya bakın), izinleri onarmak isteyeceksiniz:

cd /path/to/repo.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
find . -type d -exec chmod g+s '{}' +

Herkesin havuzu değiştirebilmesini istiyorsanız, buna ihtiyacınız olmadığını chgrpve chmod'u şu şekilde değiştirmek isteyeceğinizi unutmayın:sudo chmod -R a+rwX .

Temel nedeni düzeltmezseniz, hata geri gelmeye devam eder ve yukarıdaki komutları tekrar tekrar çalıştırmanız gerekir.

Altında yatan sebepler

Hatanın nedeni aşağıdakilerden biri olabilir:

• Depo paylaşılan bir havuz olarak yapılandırılmamış (bkz core.sharedRepository. İçeri git help config). Çıktısı ise:

  git config core.sharedRepository
  

  değil groupveya trueveya 1bazı maskeler varsa, çalıştırmayı deneyin:

  git config core.sharedRepository group
  

  ve sonra özyinelemeyi yeniden çalıştırın chmodve chgrp(bkz. yukarıdaki "İzinleri Onar")

• İşletim sistemi dizinlerdeki setgid bitini "tüm yeni dosyalar ve alt dizinler grup sahibini devralmalıdır" şeklinde yorumlamaz.

  Ne zaman core.sharedRepositoryolduğunu trueveya group, Git yeni oluşturulan alt dizinleri doğru grubunda (deponun tüm kullanıcıların olduklarını grubu) ait olduğundan emin olmak için, GNU işletim sistemlerinin bir özelliği (örneğin, her Linux dağıtımı) dayanır. Bu özellik GNU coreutils belgelerinde belgelenmiştir :

  ... [Bir dizinin set-group-ID biti ayarlanmışsa, yeni oluşturulan alt dosyalar dizinle aynı grubu devralır ve yeni oluşturulan alt dizinler üst dizinin set-group-ID bitini devralır. ... [Bu mekanizma] kullanıcıların yeni dosyaları kullanma chmodveya chownpaylaşma ihtiyacını azaltarak dosyaları daha kolay paylaşmalarını sağlar.

  Ancak, tüm işletim sistemleri bu özelliğe sahip değildir (NetBSD buna bir örnektir). Bu işletim sistemleri için tüm Git kullanıcılarınızın aynı varsayılan gruba sahip olduğundan emin olmalısınız. Alternatif olarak, depoyu çalıştırarak dünya çapında yazılabilir yapabilirsiniz git config core.sharedRepository world(ancak dikkatli olun - bu daha az güvenlidir).

• Dosya sistemi setgid bitini desteklemez (örn. FAT). ext2, ext3, ext4 hepsi setgid bitini destekler. Bildiğim kadarıyla, setgid bitini desteklemeyen dosya sistemleri de grup sahipliği kavramını desteklemiyor, bu nedenle tüm dosya ve dizinler yine de aynı gruba ait olacak (hangi grup bir montaj seçeneğidir). Bu durumda, tüm Git kullanıcılarının dosya sistemindeki tüm dosyalara sahip olan grupta olduklarından emin olun.
• Git kullanıcılarının tümü, depo dizinlerinin sahibi olan aynı grupta değildir. Dizinlerdeki grup sahibinin doğru olduğundan ve tüm kullanıcıların bu grupta olduğundan emin olun.

Ubuntu (veya herhangi bir Linux) için

Proje kökünden,

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

Bu ls -al komutundan çıkışın çoğunluğundaki izinlere bakarak adınızın ve grubunuzun ne olması gerektiğini anlayabilirsiniz.

Not: sudo hattının sonundaki yıldızı hatırlayın

aşağıdaki komutu kullanın, büyü gibi çalışır

sudo chown -R "${USER:-$(id -un)}" .

komutu aynen olduğu gibi yazın (ekstra boşluklar ve sonunda bir nokta ile)

sudo chmod -R ug+w .;

Temel olarak, .git/objectsdosyanın yazma izinleri yoktur. Yukarıdaki satır, dizindeki tüm dosya ve klasörlere izin verir.

Sadece çözümümü eklemek istedim. Yukarıda listelenen aynı hataya neden olan bazı dizinler ve Home (bu benim kullanıcı dizini olan) kök sahiplik OS X bir repo vardı.

Çözüm neyse ki basitti. Terminalden:

sudo chown -R Home projectdirectory

Bu hata ayıklamanın iyi bir yolu, bir dahaki sefere gerçekleştiğinde, SSH uzak repoya, cd'yi nesneler klasörüne ve bir ls -al.

Farklı kullanıcı: grup sahipliğine sahip 2-3 dosya görüyorsanız, sorun budur.

Geçmişte bazı eski komut dosyalarının git repo'mıza erişmesi bana oldu ve genellikle farklı bir (unix) kullanıcı tarafından itilen / değiştirilen dosyaların sürdüğü anlamına gelir ve kullanıcınızın bu dosyaların üzerine yazma izni yoktur. Tüm git etkinleştirilmiş kullanıcıların içinde olduğu bir paylaşılan git grubu oluşturmalı ve ardından klasör ve içeriğini özyinelemeli chgrpolarak objectsgrup sahipliği paylaşılan gitgrup olmalıdır.

Ayrıca klasörde yapışkan bir bit eklemeniz gerekir, böylece klasörde oluşturulan tüm dosyalar her zaman grubuna sahip olur git.

chmod g + s dizin adı

Güncelleme: core.sharedRepository hakkında bilmiyordum. Bilmek güzel, ama muhtemelen sadece yukarıdakileri yapıyor.

Benim için çözüldü ... sadece şu:

sudo chmod 777 -R .git/objects

Bu, git initdeğişiklikleri zorlarken kullanmayı planladığınızdan farklı bir kullanıcıyla çalıştırdıysanız kolayca gerçekleşebilir .

[1] üzerindeki talimatları körü körüne uygularsanız, bu muhtemelen git-user'ı root olarak oluşturduğunuzda ve ardından aradaki kullanıcıyı değiştirmeden git init'e geçtiğinizde gerçekleşir.

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

Linux, macOS:

cd .git/
sudo chown -R name:group *

nerede nameKullanıcı adınız ve groupadınızı ait olduğu gruptur.

Bazı şeyler ekledikten sonra ... taahhüt edin ve sonuçta itin! BANG !! Tüm problemlere başlayın ... Fark ettiğiniz gibi, hem yeni hem de mevcut projelerin tanımlanma biçiminde bazı farklılıklar vardır. Başka bir kişi aynı dosyaları veya içeriği (git her ikisini de aynı nesne olarak tutar) eklemeye / taahhüt etmeye / aktarmaya çalışırsa, aşağıdaki hatayla karşılaşırız:

$ git push
Counting objects: 31, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (17/17), done.
Writing objects: 100% (21/21), 2.07 KiB | 0 bytes/s, done.
Total 21 (delta 12), reused 0 (delta 0)
remote: error: insufficient permission for adding an object to repository database ./objects  remote: fatal: failed to write object

Bu sorunu çözmek için, işletim sisteminin izinlerini, bu durumda kısıtladığınız için aklınızda bulundurmanız gerekir. Sorunu daha iyi anlayın, devam edin ve git nesnenizin klasörünü (.git / objects) kontrol edin. Muhtemelen böyle bir şey göreceksiniz:

<your user_name>@<the machine name> objects]$ ls -la
total 200
drwxr-xr-x 25 <your user_name> <group_name> 2048 Feb 10 09:28 .
drwxr-xr-x  3 <his user_name> <group_name> 1024 Feb  3 15:06 ..
drwxr-xr-x  2 <his user_name> <group_name> 1024 Jan 31 13:39 02
drwxr-xr-x  2 <his user_name> <group_name> 1024 Feb  3 13:24 08

* Bu dosyanın izinlerinin yalnızca kullanıcılarınız için verildiğini, kimsenin asla değiştiremeyeceğini unutmayın ... *

Level       u   g   o
Permission rwx r-x ---
Binary     111 101 000
Octal       7   5   0

SORUNU ÇÖZMEK

Süper kullanıcı izniniz varsa, ikinci adımı kullanarak ileriye doğru gidebilir ve tüm izinleri kendiniz değiştirebilirsiniz, başka bir durumda, kullanıcılarıyla oluşturulmuş nesnelerle tüm kullanıcılara sormanız gerekir, kim olduklarını bilmek için aşağıdaki komutu kullanın :

$ ls -la | awk '{print $3}' | sort -u 
<your user_name>
<his user_name>

Artık siz ve tüm dosyanın sahibi kullanıcılar bu dosyaları iznini değiştirmek zorunda kalacaksınız:

$ chmod -R 774 .

Bundan sonra, yeni depo için yapılan --shared = gruba eşdeğer yeni bir özellik eklemeniz gerekecektir, belgelere göre bu, havuz grubunu yazılabilir yapar, yürütün:

$ git config core.sharedRepository group

https://coderwall.com/p/8b3ksg

Benim durumum için hiçbir öneri işe yaramadı. Windows'tayım ve bu benim için çalıştı:

• Uzak depoyu başka bir klasöre kopyalayın
• Klasörü paylaşın ve uygun izinleri verin.
• Klasöre yerel makinenizden erişebildiğinizden emin olun.
• Bu repoyu yerel deponuzda başka bir uzak repo olarak ekleyin. ( git remote add foo //SERVERNAME/path/to/copied/git)
• Foo'ya doğru itin. git push foo master. Çalıştı mı? Harika! Şimdi çalışmayan depoyu silin ve bunu daha önce olduğu gibi yeniden adlandırın. İzinlerin ve paylaşım özelliğinin aynı kaldığından emin olun.

Aynı sorunu vurdum. Buraları okuduğumda, mesajın atıfta bulunduğu dosya izinleri olduğunu fark ettim. Düzeltme, benim için:

/etc/inetd.d/git-gpv

Git-daemon'u ' hiç kimse ' kullanıcısı olarak yazma izninden yoksun olarak başlatıyordu.

# Who   When    What
# GPV   20Nov13 Created this by hand while reading: http://linuxclues.blogspot.co.uk/2013/06>/git-daemon-ssh-create-repository-debian.html
# GPV   20Nov13 Changed owner (to user_git) otherise nobody lack permission to update the repository
#git stream tcp nowait nobody  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo
git stream tcp nowait user_git  /usr/bin/git git daemon --inetd --verbose --enable=receive-pack --export-all /gitrepo

(Diğerleri inetd conf dosyası git-gpv çağırdığından şüpheliyim. Genellikle doğrudan /etc/inetd.conf içinde olur)

İçe aktardığınız dizinde yeterli yazma izinlerine sahip olmanız gerekir.

Benim durumumda: Windows 2008 sunucusu

git repo dizinine veya üst dizine sağ tıklayın.

Özellikler> Paylaşım sekmesi> Gelişmiş Paylaşım> İzinler> kullanıcının uygun erişim haklarına sahip olduğundan emin olun.

Yanlışlıkla git depolarına sahip olabilirsiniz

Aynı takma adla başka bir yerel depo eklemeniz de mümkündür. Örnek olarak, artık originitmeye çalıştığınızda, uzak depo size kimlik bilgilerini kabul etmeyecek şekilde adlandırılan 2 yerel klasörünüz var .

Yerel depo takma adlarını yeniden adlandırın, bu bağlantıyı takip edebilirsiniz https://stackoverflow.com/a/26651835/2270348

Belki senin kadar sevme 1 yerel depoyu bırakabilir originve diğerleri, örneğin onları adlandırmak originiçin anotherorigin. Bunların sadece takma adlar olduğunu ve tek yapmanız gereken yeni takma adları ve ilgili uzak dallarını hatırlamaktır.

Benim için çalışıyor

sudo chmod -R g+rwX .

Bunu bir Rstudio projesine çekerken anladım. Yapmayı unuttuğumu fark ettim:

sudo rstudio

program başlangıcında. Aslında başka bir hata var gibi, aslında yapmam gerek:

sudo rstudio --no-sandbox

Commit -m için sudo kullan

• git add -A
• sudo git commit -m "commit -m için sudo kullan"
• git push başlangıcı branch_name

Bu sorunu bir Samba paylaşımındaki uzak bir depoda alıyordum; Bu uzaktan kumandayı başarıyla çektim ama iterken başarısız oldum.

Hatanın nedeni dosyamdaki hatalı kimlik bilgileriydi ~/.smbcredentials.