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

591

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.

skaz
fuente
Recibí este error después de accidentalmente git addy git commit-ing como usuario root. Lo arreglé con git resetay la respuesta de esta pregunta para arreglar los .gitpermisos del directorio.
StockB
¿Cómo puedo averiguar qué objeto estaba tratando de crear (al depurar manualmente tales problemas de permisos)? El mensaje de error es demasiado vago.
mirabilos
Recibí este error al copiar y pegar otro archivo .git primero usando sudo. por lo tanto, los archivos tenían sudo sudo como nombre y grupo.
Vincent

Respuestas:

864

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.
Richard Hansen
fuente
1
@ Richard Hansen - Realmente no sé a qué te refieres con forzar la propiedad. Estoy mirando al hombre para chmod, pero no sé lo suficiente para que las palabras tengan sentido :) ¿Algún consejo?
skaz
77
@GiH: no obtendrá nada si no está configurado (que es lo mismo que falseo umask). Ver git help configpara más detalles.
Richard Hansen
10
Debo haber emitido git pushusando la cuenta raíz en mi directorio de trabajo. Encontré que el propietario de algunos archivos de repositorio de git es root ( -r--r--r--. 1 root root 6380 5月 25 12:39 9b44bd22f81b9a8d0a244fd16f7787a1b1d424) según esta respuesta.
LiuYan 刘 研
3
@MattBrowne: Tenga en cuenta que es una capital X, no una minúscula x. Una letra mayúscula Xsignifica "establecer S_IXGRPsi el archivo es un directorio (o si S_IX*se configura cualquier otro bit)", por lo que no hará que todos los archivos sean ejecutables. Puede ser innecesario, pero tal vez no si core.sharedRepositoryse estableció 0600en algún momento en el pasado.
Richard Hansen
2
@francoisromain: esa línea establece el bit setgid en todos los directorios. Ver gnu.org/software/coreutils/manual/html_node/…
Richard Hansen
440

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

TerryS
fuente
77
Funcionó genial! Sí, por alguna razón, a algunas de las carpetas se les asignó un nombre y grupo (raíz) diferentes.
Peter Arandorenko
2
Obtengo:Sorry, user myuser is not allowed to execute '/bin/chown
Francisco Corrales Morales
El *hizo toda la diferencia. Gracias.
Bradley Flood
55
Mi problema fue que una vez hice un "git pull" como root, que creo que arruinó los permisos ... puedes verificarlo haciendo unls .git
rogerdpack
¡Gracias por una solución rápida!
helvete
75

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)

Code_Worm
fuente
66
¡Funciona de maravilla!
doncadavona
1
¡increíble! funcionó perfectamente en mi Mac
Sachin Khot
¡Esto también me ayudó! Gracias.
Horvath Adam
De hecho, funcionó como magia! ¡Gracias!
Kumar Manish
49

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.

Rajendra kumar Vankadari
fuente
2
Esto es lo que funcionó para mí. La respuesta aceptada tristemente no lo hizo. Gracias rajendra!
revelt
27

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
Brandon
fuente
A mi me pasó lo mismo. No puedo entender cómo algunos de los objetos obtuvieron la propiedad raíz, pero lo hicieron.
vy32
18

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.

Mauvis Ledford
fuente
15

Resuelto para mí ... solo esto:

sudo chmod 777 -R .git/objects
GUSTAVO BERBERT
fuente
21
Chmod 777no se recomienda ya que expone todo su archivo al resto del mundo haciendo que su máquina sea vulnerable
Elena
23
Si su consejo es chmod 777, 99 de cada 100 veces no comprende el problema y es probable que cause más problemas de los que ayuda a resolver. Como muestra la respuesta aceptada anteriormente, este problema no es diferente.
jonatan
¿Por qué ustedes no proponen una respuesta aceptable en lugar de decir que es una elección incorrecta?
Giovani
2
Porque a pesar de que hay respuestas aceptables en la página, esta respuesta inaceptable todavía está aquí.
Teh JoE
sudo chmod -R 777 .git / objects
Nabeel Ahmed
9

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

gitzor
fuente
7

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.

Afshin Mehrabani
fuente
5

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

helmedeiros
fuente
Tenía lo mismo username:groupnamepara el mío, pero cuando lo intenté chmod -R 774 ., pude correr con git add --alléxito.
John Skilbeck
3

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.
Halil Kaskavalci
fuente
1
En mi caso, simplemente copiando la carpeta local a una nueva carpeta, eliminando la antigua y cambiando el nombre de la nueva al nombre anterior, se solucionaron los problemas de permisos.
mgiuffrida
2

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)

GraemeV
fuente
1

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.

Caqui Fuyu
fuente
1

Es posible que haya anidado accidentalmente repositorios git

IliasT
fuente
1

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.

Huey Mataruse
fuente
0

Funciona para mi

sudo chmod -R g+rwX .
Nitina
fuente
0

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
Timothy Pollington
fuente
0

Use sudo para commit -m

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

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.

Josh
fuente