Git Push Error: permissão insuficiente para adicionar um objeto ao repositório de banco de dados

Quando tento enviar para um controle remoto compartilhado do git, recebo o seguinte erro: insufficient permission for adding an object to repository database

Então li sobre uma correção aqui: Fix Isso funcionou para o próximo push, já que todos os arquivos estavam no grupo correto, mas na próxima vez que alguém pressionou uma alteração, ele criou um novo item na pasta de objetos que tinha o grupo padrão como o grupo. A única coisa em que consigo pensar é alterar todo o grupo padrão do desenvolvedor para itens que eles fazem check-in, mas isso parece um hack. Alguma ideia? Obrigado.

Permissões de reparo

Depois de identificar e corrigir a causa subjacente (veja abaixo), convém reparar as permissões:

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

Observe que se você quiser que todos possam modificar o repositório, você não precisa do chgrpe deseja alterar o chmod parasudo chmod -R a+rwX .

Se você não corrigir a causa subjacente, o erro continuará voltando e você precisará continuar executando os comandos acima repetidamente.

Causas subjacentes

O erro pode ser causado por um dos seguintes:

• O repositório não está configurado para ser um repositório compartilhado (veja core.sharedRepositoryem git help config). Se a saída de:

  git config core.sharedRepository
  

  não é groupou trueou 1ou alguma máscara, tente executar:

  git config core.sharedRepository group
  

  e execute novamente o recursivo chmode chgrp(consulte "Permissões de reparo" acima).

• O sistema operacional não interpreta um bit setgid nos diretórios como "todos os novos arquivos e subdiretórios devem herdar o proprietário do grupo".

  Quando core.sharedRepositoryé trueou group, o Git conta com um recurso dos sistemas operacionais GNU (por exemplo, toda distribuição Linux) para garantir que os subdiretórios recém-criados sejam de propriedade do grupo correto (o grupo em que todos os usuários do repositório estão). Esse recurso está documentado na documentação do coreUtil GNU :

  ... [Se] o bit de ID do grupo de conjunto de um diretório estiver definido, os subarquivos recém-criados herdarão o mesmo grupo que o diretório e os subdiretórios recém-criados herdarão o bit de ID do grupo de conjuntos do diretório pai. ... [Esse mecanismo permite] que os usuários compartilhem arquivos com mais facilidade, diminuindo a necessidade de usar chmodou chowncompartilhar novos arquivos.

  No entanto, nem todos os sistemas operacionais possuem esse recurso (o NetBSD é um exemplo). Para esses sistemas operacionais, verifique se todos os usuários do Git têm o mesmo grupo padrão. Como alternativa, você pode tornar o repositório gravável em todo o mundo executando git config core.sharedRepository world(mas tenha cuidado - isso é menos seguro).

• O sistema de arquivos não suporta o bit setgid (por exemplo, FAT). ext2, ext3, ext4 suportam o bit setgid. Até onde eu sei, os sistemas de arquivos que não suportam o bit setgid também não suportam o conceito de propriedade de grupo, portanto todos os arquivos e diretórios pertencerão ao mesmo grupo de qualquer maneira (qual grupo é uma opção de montagem). Nesse caso, verifique se todos os usuários do Git estão no grupo que possui todos os arquivos no sistema de arquivos.
• Nem todos os usuários do Git estão no mesmo grupo que possui os diretórios do repositório. Verifique se o proprietário do grupo nos diretórios está correto e se todos os usuários estão nesse grupo.

Para Ubuntu (ou qualquer Linux)

Da raiz do projeto,

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

Você pode dizer qual deve ser seu nome e seu grupo observando as permissões na maioria da saída desse comando ls -al

Nota: lembre-se da estrela no final da linha sudo

use o seguinte comando, funciona como mágica

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

digite o comando exatamente como é (com espaços extras e um ponto no final)

sudo chmod -R ug+w .;

Basicamente, o .git/objectsarquivo não tem permissões de gravação. A linha acima concede permissão para todos os arquivos e pastas no diretório.

Eu só queria adicionar minha solução. Tive um repo no OS X que possuía a propriedade root em alguns diretórios e o Home (que é o meu diretório de usuários) em outros que causaram o mesmo erro listado acima.

A solução foi simples, felizmente. Do terminal:

sudo chown -R Home projectdirectory

Uma boa maneira de depurar isso é a próxima vez que isso acontecer, SSH no repositório remoto, cd na pasta de objetos e faça um ls -al.

Se você vir 2-3 arquivos com usuário diferente: propriedade do grupo, esse é o problema.

Isso aconteceu comigo no passado com alguns scripts herdados acessando nosso repositório git e geralmente significa que um usuário (unix) empurrou / modificou arquivos pela última vez e seu usuário não tem permissão para sobrescrever esses arquivos. Você deve criar um grupo git compartilhado no qual todos os usuários habilitados para git estejam e, em seguida, recursivamente chgrpa objectspasta e seu conteúdo, para que a propriedade do grupo seja o gitgrupo compartilhado .

Você também deve adicionar um pedaço fixo na pasta para que todos os arquivos criados na pasta sempre tenham o grupo de git.

nome do diretório chmod g + s

Atualização: eu não sabia sobre o core.sharedRepository. É bom saber, embora provavelmente faça o que precede.

Resolvido para mim ... apenas isso:

sudo chmod 777 -R .git/objects

Isso pode acontecer facilmente se você executou git initum usuário diferente daquele que planeja usar ao enviar alterações.

Se você seguir cegamente as instruções em [1], isso acontecerá, pois você provavelmente criou o usuário do git como root e depois passou imediatamente para o git init sem alterar o usuário no meio.

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

Linux, macOS:

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

onde nameé o seu nome de usuário e groupo grupo ao qual ele pertence.

Depois de adicionar algumas coisas ... confirme-as e, depois de tudo terminado, empurre! BANG !! Inicie todos os problemas ... Como você deve notar, existem algumas diferenças na maneira como os projetos novos e os existentes foram definidos. Se outra pessoa tentar adicionar / confirmar / enviar os mesmos arquivos ou conteúdo (o git mantém os dois mesmos objetos), enfrentaremos o seguinte erro:

$ 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

Para resolver esse problema, é necessário ter em mente o sistema de permissões do sistema operacional, pois neste caso você é restringido por ele. Você entende melhor o problema, vá em frente e verifique a pasta do seu objeto git (.git / objects). Você provavelmente verá algo assim:

<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

* Observe que as permissões desse arquivo foram concedidas apenas para seus usuários, ninguém nunca poderá alterá-lo ... *

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

RESOLVER O PROBLEMA

Se você tiver permissão de superusuário, poderá avançar e alterar todas as permissões usando a etapa dois; em qualquer outro caso, você precisará solicitar a todos os usuários com objetos criados com seus usuários, use o comando a seguir para saber quem eles são :

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

Agora você e todos os usuários proprietários do arquivo terão que alterar a permissão desses arquivos, fazendo:

$ chmod -R 774 .

Depois disso, você precisará adicionar uma nova propriedade equivalente a --shared = group feita para o novo repositório, de acordo com a documentação, tornando o repositório gravável em grupo, faça-o executando:

$ git config core.sharedRepository group

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

Para o meu caso, nenhuma das sugestões funcionou. Estou no Windows e isso funcionou para mim:

• Copie o repositório remoto para outra pasta
• Compartilhe a pasta e dê as permissões apropriadas.
• Verifique se você pode acessar a pasta na sua máquina local.
• Adicione este repositório como outro repositório remoto no repositório local. ( git remote add foo //SERVERNAME/path/to/copied/git)
• Empurre para foo. git push foo master. Funcionou? Ótimo! Agora exclua o repositório que não está funcionando e renomeie-o para o que era antes. Verifique se as permissões e a propriedade de compartilhamento permanecem as mesmas.

Eu bati esse mesmo problema. Lendo por aqui, percebi que eram as permissões de arquivo às quais a mensagem estava se referindo. A correção, para mim, estava em:

/etc/inetd.d/git-gpv

Ele estava iniciando o git-daemon como usuário ' ninguém ', por isso faltava a permissão de gravação.

# 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

(Eu duvido que outros chamam seu arquivo inetd conf de git-gpv. Geralmente seria diretamente no /etc/inetd.conf)

Você precisa de permissões de gravação suficientes no diretório para o qual está empurrando.

No meu caso: servidor Windows 2008

clique com o botão direito do mouse no diretório git repo ou no diretório pai.

Propriedades> guia Compartilhamento> Compartilhamento avançado> Permissões> verifique se o usuário possui direitos de acesso apropriados.

Você pode ter aninhado acidentalmente repositórios git

Também é possível que você tenha adicionado outro repositório local com o mesmo alias. Como exemplo, agora você tem duas pastas locais, originassim quando você tenta enviar por push, o repositório remoto não aceita suas credenciais.

Renomeie os aliases do repositório local, você pode seguir este link https://stackoverflow.com/a/26651835/2270348

Talvez você possa deixar um repositório local do seu agrado origine os outros os renomeiem, por exemplo, de originpara anotherorigin. Lembre-se de que são apenas aliases e tudo que você precisa fazer é lembrar os novos aliases e seus respectivos ramos remotos.

Funciona para mim

sudo chmod -R g+rwX .

Eu consegui isso ao entrar em um projeto Rstudio. Percebi que esqueci de fazer:

sudo rstudio

na inicialização do programa. De fato, como há outro bug que eu tenho, eu realmente preciso:

sudo rstudio --no-sandbox

Use sudo para commit -m

• git add -A
• sudo git commit -m "Use o sudo para commit -m"
• origem do push do git branch_name

Eu estava recebendo esse problema com um repositório remoto em um compartilhamento Samba; Puxei com sucesso deste controle remoto, mas falhei ao pressioná-lo.

A causa do erro foram credenciais incorretas no meu ~/.smbcredentialsarquivo.