Git Push Error: permissão insuficiente para adicionar um object ao database do repository

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

Então eu li sobre uma correção aqui: Correção Isso funcionou para o próximo push, já que todos os arquivos eram do grupo correto, mas da próxima vez que alguém fez uma alteração, ele criou um novo item na pasta de objects 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 os itens que eles registram, mas isso parece um hack. Alguma ideia? Obrigado.

   

    Permissões de reparo

    Depois de ter identificado e corrigido a causa subjacente (veja abaixo), você vai querer reparar as permissions:

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

    Note que se você quiser que todos possam modificar o repository, você não precisa do chgrp e vai querer mudar o chmod para sudo chmod -R a+rwX .

    Se você não corrigir a causa subjacente, o erro continuará voltando e você terá que continuar executando novamente os comandos acima repetidas vezes.

    Causas Subjacentes

    O erro pode ser causado por um dos seguintes motivos:

    • O repository não está configurado para ser um repository compartilhado (veja core.sharedRepository em git help config ). Se a saída de:

       git config core.sharedRepository 

      não é group ou true ou 1 ou alguma máscara, tente executar:

       git config core.sharedRepository group 

      e, em seguida, execute novamente o chmod recursivo e 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 é true ou group , o Git depende de 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 no qual todos os usuários do repository estão). Este recurso está documentado na documentação do GNU Coreutils :

      … [Se] o bit set-group-ID de um diretório estiver definido, os subarquivos recém-criados herdam o mesmo grupo que o diretório e os subdiretórios recém-criados herdam o bit set-group-ID do diretório pai. … [Esse mecanismo permite que] usuários compartilhem arquivos com mais facilidade, diminuindo a necessidade de usar chmod ou chown para compartilhar novos arquivos.

      No entanto, nem todos os sistemas operacionais têm esse recurso (o NetBSD é um exemplo). Para esses sistemas operacionais, você deve se certificar de que todos os seus usuários do Git tenham o mesmo grupo padrão. Alternativamente, você pode tornar o repository world-writable 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 todos suportam o bit setgid. Até onde sei, os filesystems que não suportam o bit setgid também não suportam o conceito de propriedade de grupo, de forma que todos os arquivos e diretórios pertencerão ao mesmo grupo (qual grupo é uma opção de assembly). Nesse caso, certifique-se de que todos os usuários do Git estejam 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 repository. Certifique-se de que o proprietário do grupo nos diretórios esteja correto e que todos os usuários estejam nesse grupo.

    Para o Ubuntu (ou qualquer Linux)

    Da raiz do projeto,

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

    Você pode dizer o que yourname e yourgroup devem estar olhando as permissions na maior parte da saída do comando ls -al

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

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

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

     sudo chown -R Home projectdirectory 

    sudo chmod -R ug+w .;

    Basicamente, o arquivo .git/objects não possui permissions de gravação. A linha acima concede permissão para todos os arquivos e pastas no diretório.

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

    Se você vir de 2 a 3 arquivos com usuários diferentes: propriedade do grupo, esse é o problema.

    Aconteceu comigo no passado com alguns scripts legados acessando nosso repository git e geralmente significa que um usuário (unix) diferente carregou / modificou arquivos por último e seu usuário não tem permissions para sobrescrever esses arquivos. Você deve criar um grupo git compartilhado no qual todos os usuários habilitados pelo git estejam e então chgrp recursivamente a pasta de objects e seu conteúdo, para que a propriedade do grupo seja o grupo git compartilhado.

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

    chmod g + s nome-do-diretório

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

    Isso pode acontecer facilmente se você executar o git init com um usuário diferente daquele que você está planejando usar ao enviar as alterações.

    Se você seguir cegamente as instruções em [1], isso acontecerá, já que você provavelmente criou o git-user como root e imediatamente mudou para git init sem alterar o usuário entre elas.

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

    Resolvido por mim … apenas isto:

     sudo chmod 777 -R .git/objects 

    Depois de adicionar algumas coisas … cometê-los e depois de tudo terminado empurrá-lo! BANG !! Comece todos os problemas … Como você deve notar, existem algumas diferenças na maneira como os projetos novos e existentes foram definidos. Se alguma outra pessoa tentar adicionar / confirmar / enviar os mesmos arquivos ou conteúdo (git manter ambos como os mesmos objects), 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 este problema, você deve ter algo em mente com o sistema de permissions do sistema operacional, pois você está restrito a ele neste caso. Tu entendeu melhor o problema, vá em frente e verifique a pasta do seu object git (.git / objects). Você provavelmente verá algo assim:

     @ objects]$ ls -la total 200 drwxr-xr-x 25   2048 Feb 10 09:28 . drwxr-xr-x 3   1024 Feb 3 15:06 .. drwxr-xr-x 2   1024 Jan 31 13:39 02 drwxr-xr-x 2   1024 Feb 3 13:24 08 

    * Observe que as permissions desse arquivo foram concedidas apenas para seus usuários, ninguém nunca poderá alterá-lo … *

     Level ugo Permission rwx rx --- Binary 111 101 000 Octal 7 5 0 

    RESOLVENDO O PROBLEMA

    Se você tem permissão de superusuário, você pode ir adiante e alterar todas as permissions usando a segunda etapa, em qualquer outro caso você precisará perguntar a todos os usuários os objects criados com seus usuários, use o seguinte comando para saber quem eles são :

     $ ls -la | awk '{print $3}' | sort -u   

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

     $ chmod -R 774 . 

    Depois disso você precisará adicionar uma nova propriedade que é equivalente a –shared = group done para o novo repository, de acordo com a documentação, isto torna o repository group-writable, execute:

     $ git config core.sharedRepository group 

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

    Linux, macOS:

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

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

    No meu caso, nenhuma das sugestões funcionou. Eu estou no Windows e isso funcionou para mim:

    • Copie o repository remoto para outra pasta
    • Compartilhe a pasta e dê as devidas permissions.
    • Certifique-se de que você pode acessar a pasta da sua máquina local.
    • Adicione este repository como outro repository remoto em seu repository local. ( git remote add foo //SERVERNAME/path/to/copied/git )
    • Empurre para foo. git push foo master . Funcionou? Ótimo! Agora, exclua o repo não-funcional e renomeie-o para o que estava antes. Certifique-se de que as permissions e a propriedade de compartilhamento permaneçam as mesmas.

    Eu bati nesse mesmo problema. Lendo por aqui, percebi que eram permissions de arquivos que a mensagem estava se referindo. A correção, para mim, estava em:

    /etc/inetd.d/git-gpv

    Ele estava iniciando o git-daemon, pois o usuário ‘ nobody ‘ não possuí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 

    (Duvido que outros chamem seu arquivo conf do inetd git-gpv. Geralmente seria diretamente em /etc/inetd.conf)

    use o seguinte comando, funciona como mágica

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

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

    Você pode ter repositorys git acidentalmente nesteds

    Você precisa das permissions de gravação suficientes no diretório para o qual está enviando.

    No meu caso: servidor Windows 2008

    clique com o botão direito 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 access apropriados.

    Note que isso pode acontecer também se sua umask estiver errada. Testei alguns milks e esqueci de restaurá-lo ao seu padrão (0022), segui-se hilaridade …

    Eu estou recebendo este erro ao tentar empurrar através de um IDE (neste caso, PHPStorm). Quando tentei usar o terminal (OSX), funcionou! Então, é claramente uma questão de permissão. Enquanto não consigo encontrar como consertá-lo permanentemente ,

     $ sudo git push origin master 

    vai fazer o truque