Error de Git Push: permiso insuficiente para agregar un objeto a la base de datos del repositorio

Cuando intento pasar a un control remoto git compartido, aparece el siguiente error: insufficient permission for adding an object to repository database

Luego leí acerca de una solución aquí: Solución Esto funcionó para el siguiente envío, ya que todos los archivos eran del grupo correcto, pero la próxima vez que alguien presionó un cambio, hizo un nuevo elemento en la carpeta de objetos que tenía su grupo predeterminado como el grupo Lo único que se me ocurre es cambiar todo el grupo predeterminado del desarrollador por los elementos que registran, pero eso parece un truco. ¿Algunas ideas? Gracias.

Permisos de reparación

Después de haber identificado y corregido la causa subyacente (ver más abajo), querrá reparar los permisos:

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

Tenga en cuenta que si desea que todos puedan modificar el repositorio, no necesita el chgrpy querrá cambiar el chmod asudo chmod -R a+rwX .

Si no soluciona la causa subyacente, el error seguirá apareciendo y tendrá que volver a ejecutar los comandos anteriores una y otra vez.

Causas subyacentes

El error podría ser causado por uno de los siguientes:

• El repositorio no está configurado para ser un repositorio compartido (ver core.sharedRepositoryen git help config). Si la salida de:

  git config core.sharedRepository
  

  no es groupo trueo 1o alguna máscara, intente ejecutar:

  git config core.sharedRepository group
  

  y luego vuelva a ejecutar el recursivo chmody chgrp(consulte "Permisos de reparación" más arriba).

• El sistema operativo no interpreta un bit setgid en los directorios como "todos los archivos y subdirectorios nuevos deben heredar el propietario del grupo".

  Cuando core.sharedRepositoryes trueo group, Git se basa en una característica de los sistemas operativos GNU (por ejemplo, cada distribución de Linux) para garantizar que los subdirectorios recién creados sean propiedad del grupo correcto (el grupo en el que se encuentran todos los usuarios del repositorio). Esta característica está documentada en la documentación de GNU coreutils :

  ... [Si] se establece el bit set-group-ID de un directorio, los subfiles recién creados heredan el mismo grupo que el directorio y los subdirectorios recién creados heredan el bit set-group-ID del directorio padre. ... [Este mecanismo permite] a los usuarios compartir archivos más fácilmente, al disminuir la necesidad de usar chmodo chowncompartir archivos nuevos.

  Sin embargo, no todos los sistemas operativos tienen esta característica (NetBSD es un ejemplo). Para esos sistemas operativos, debe asegurarse de que todos sus usuarios de Git tengan el mismo grupo predeterminado. Alternativamente, puede hacer que el repositorio sea editable en todo el mundo ejecutando git config core.sharedRepository world(pero tenga cuidado, esto es menos seguro).

• El sistema de archivos no admite el bit setgid (por ejemplo, FAT). ext2, ext3, ext4 todos admiten el bit setgid. Hasta donde yo sé, los sistemas de archivos que no admiten el bit setgid tampoco admiten el concepto de propiedad del grupo, por lo que todos los archivos y directorios serán propiedad del mismo grupo de todos modos (qué grupo es una opción de montaje). En este caso, asegúrese de que todos los usuarios de Git estén en el grupo que posee todos los archivos en el sistema de archivos.
• No todos los usuarios de Git están en el mismo grupo propietario de los directorios del repositorio. Asegúrese de que el propietario del grupo en los directorios sea correcto y que todos los usuarios estén en ese grupo.

Para Ubuntu (o cualquier Linux)

Desde la raíz del proyecto,

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

Puede saber cuál debería ser su nombre y su grupo mirando los permisos en la mayoría de los resultados de ese comando ls -al

Nota: recuerda la estrella al final de la línea de sudo

usa el siguiente comando, funciona como magia

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

escriba el comando exactamente como está (con espacios adicionales y un punto al final)

sudo chmod -R ug+w .;

Básicamente, el .git/objectsarchivo no tiene permisos de escritura. La línea anterior otorga permiso a todos los archivos y carpetas en el directorio.

Solo quería agregar mi solución. Tuve un repositorio en OS X que tenía la propiedad de root en algunos directorios y Home (que es mi directorio de usuarios) en otros, lo que causó el mismo error mencionado anteriormente.

La solución fue simple, afortunadamente. Desde la terminal:

sudo chown -R Home projectdirectory

Una buena manera de depurar esto es la próxima vez que suceda, SSH en el repositorio remoto, cd en la carpeta de objetos y hacer un ls -al .

Si ve 2-3 archivos con un usuario diferente: la propiedad del grupo es el problema.

Me sucedió en el pasado con algunos scripts heredados que acceden a nuestro repositorio de git y generalmente significa que un usuario diferente (unix) empujó / modificó los archivos al final y su usuario no tiene permisos para sobrescribir esos archivos. Debe crear un grupo git compartido en el que estén todos los usuarios habilitados para git y luego recursivamente chgrpla objectscarpeta y su contenido para que la propiedad del grupo sea el gitgrupo compartido .

También debe agregar un bit adhesivo en la carpeta para que todos los archivos creados en la carpeta siempre tengan el grupo de git.

nombre-directorio chmod g + s

Actualización: no sabía sobre core.sharedRepository. Es bueno saberlo, aunque probablemente solo haga lo anterior.

Resuelto para mí ... solo esto:

sudo chmod 777 -R .git/objects

Esto puede suceder fácilmente si se ejecutó git initcon un usuario diferente del que está planeando usar al empujar los cambios.

Si sigue ciegamente las instrucciones en [1], esto sucederá ya que probablemente creó el git-user como root e inmediatamente pasó a git init sin cambiar de usuario.

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

Linux, macOS:

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

donde nameestá su nombre de usuario y groupes el grupo al que pertenece su nombre de usuario.

Después de agregar algunas cosas ... compromételas y, después de todo, ¡presiónalo! ¡¡EXPLOSIÓN!! Comience todos los problemas ... Como debe notar, hay algunas diferencias en la forma en que se definieron los proyectos nuevos y existentes. Si alguna otra persona intenta agregar / confirmar / enviar los mismos archivos o contenido (git mantiene ambos como los mismos objetos), nos enfrentaremos al siguiente error:

$ 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, debe tener en cuenta el sistema de permisos del sistema operativo, ya que en este caso está restringido. Para comprender mejor el problema, continúe y verifique la carpeta de su objeto git (.git / objects). Probablemente verá algo así:

<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

* Tenga en cuenta que esos permisos de archivo se otorgaron solo para sus usuarios, nadie nunca podrá cambiarlo ... *

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

RESOLVIENDO EL PROBLEMA

Si tiene permiso de superusuario, puede seguir adelante y cambiar todos los permisos usted mismo utilizando el paso dos, en cualquier otro caso deberá preguntar a todos los usuarios con objetos creados con sus usuarios, use el siguiente comando para saber quiénes son :

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

Ahora usted y todos los usuarios propietarios del archivo tendrán que cambiar el permiso de esos archivos, haciendo lo siguiente:

$ chmod -R 774 .

Después de eso, deberá agregar una nueva propiedad que sea equivalente a --shared = group done para el nuevo repositorio, de acuerdo con la documentación, esto hace que el repositorio sea editable en grupo, ejecute:

$ git config core.sharedRepository group

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

Para mi caso, ninguna de las sugerencias funcionó. Estoy en Windows y esto funcionó para mí:

• Copie el repositorio remoto en otra carpeta
• Comparta la carpeta y otorgue los permisos adecuados.
• Asegúrese de poder acceder a la carpeta desde su máquina local.
• Agregue este repositorio como otro repositorio remoto en su repositorio local. ( git remote add foo //SERVERNAME/path/to/copied/git)
• Empujar a foo. git push foo master. ¿Funcionó? ¡Excelente! Ahora elimine el repositorio que no funciona y cambie el nombre de esto a lo que era antes. Asegúrese de que los permisos y la propiedad compartida sigan siendo los mismos.

Llegué a este mismo problema. Al leer por aquí, me di cuenta de que el mensaje se refería a los permisos de archivo. La solución, para mí, estaba en:

/etc/inetd.d/git-gpv

Estaba iniciando git-daemon ya que el usuario ' nobody ' no tenía permiso de escritura.

# 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

(Dudo que otros llamen a su archivo inetd conf git-gpv. Comúnmente estaría directamente en /etc/inetd.conf)

Necesita los permisos de escritura suficientes en el directorio al que está presionando.

En mi caso: servidor Windows 2008

haga clic derecho en el directorio git repo o directorio principal

Propiedades> pestaña Compartir> Uso compartido avanzado> Permisos> asegúrese de que el usuario tenga los derechos de acceso adecuados.

Es posible que haya anidado accidentalmente repositorios git

También existe la posibilidad de que haya agregado otro repositorio local con el mismo alias. Como ejemplo, ahora tiene 2 carpetas locales a las que se hace referencia origincuando intenta empujar, el repositorio remoto no aceptará sus credenciales.

Cambie el nombre de los alias del repositorio local, puede seguir este enlace https://stackoverflow.com/a/26651835/2270348

Tal vez pueda dejar 1 repositorio local de su agrado como originy los demás los renombren, por ejemplo, de origina anotherorigin. Recuerde que estos son solo alias y todo lo que necesita hacer es recordar los nuevos alias y sus respectivas ramas remotas.

Funciona para mi

sudo chmod -R g+rwX .

Obtuve esto cuando llegué a un proyecto de Rstudio. Me di cuenta de que olvidé hacer:

sudo rstudio

en el inicio del programa. De hecho, como hay otro error que tengo, debo hacerlo:

sudo rstudio --no-sandbox

Use sudo para commit -m

• git add -A
• sudo git commit -m "Usa sudo para commit -m"
• git push origin branch_name

Estaba teniendo este problema con un repositorio remoto en un recurso compartido de Samba; Salí con éxito de este control remoto, pero fallé al presionarlo.

La causa del error fue credenciales incorrectas en mi ~/.smbcredentialsarchivo.