sig español git github

español - sig in github



Error al presionar a GitHub: permiso insuficiente para agregar un objeto a la base de datos del repositorio (21)

Estoy recuperando un error inusual mientras trato de hacer un "git push" a mi repositorio de GitHub:

Counting objects: 8, done. Delta compression using 2 threads. Compressing objects: 100% (4/4), done. Writing objects: 100% (5/5), 1.37 KiB, done. Total 5 (delta 2), reused 0 (delta 0) error: insufficient permission for adding an object to repository database ./objects fatal: failed to write object error: unpack-objects exited with error code 128 error: unpack failed: unpack-objects abnormal exit To [email protected]:bixo/bixo.git ! [remote rejected] master -> master (n/a (unpacker error)) error: failed to push some refs to ''[email protected]:bixo/bixo.git''

  • Después de un clon limpio de GitHub, puedo editar / agregar / confirmar / presionar un archivo modificado.
  • Si repito esto por segunda vez, obtengo el error anterior.
  • Puedo presionar a otros repositorios de GitHub sin problemas.
  • Revisé los permisos de archivos / directorios de mi lado, y parecen estar bien.
  • Estoy ejecutando git 1.6.2.3 en Mac OS X 10.5.8

El repositorio anterior fue la fuente de mi diversión para una pregunta previa sobre desbordamiento de pila ( SO 1904860 ), por lo que tal vez el repositorio de GitHub se corrompió. El único problema similar que he encontrado a través de la búsqueda fue un problema fallido de desempaquetado informado en github. ¿Alguien más se ha encontrado con este problema anteriormente, especialmente cuando no está usando GitHub?

¿Has probado sudo git push -u origin --all ? A veces es lo único que necesita para evitar este problema. Le solicita la contraseña del sistema de administración, la que puede iniciar sesión en su máquina, y eso es lo que debe presionar o comprometer, si es el caso.

Dado que el error se refiere a los permisos en la carpeta del objeto, hice un chown directamente en la carpeta de objetos y funcionó para mí.

Después de agregar algunas cosas ... ¡compromételas y después de todo termine de empujarlas! ¡¡EXPLOSIÓN!! Comience todos los problemas ... Como debe observar, existen algunas diferencias en la forma en que se definieron los proyectos nuevos y existentes. Si alguna otra persona intenta agregar / comprometer / presionar los mismos archivos, o contenido (git mantiene los dos 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 mente algo del sistema de permisos del sistema operacional, ya que está restringido por este en este caso. Tu entiende mejor el problema, ve y revisa la carpeta de tu objeto git (.git / objects). Probablemente verás 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 los permisos de ese archivo fueron otorgados 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 avanzar y cambiar todos los permisos usando 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 de archivos tendrán que cambiar el permiso de dichos archivos haciendo:

$ 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 grupo de repositorio sea modificable, ejecute:

$ git config core.sharedRepository group

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

En mi caso no hubo autenticación unificada (por ejemplo, dentro del dominio + servicio tipo AD) entre mi máquina y el servidor virtual git. Por lo tanto, los usuarios y el grupo de git son locales para el servidor virtual. En mi caso, mi usuario remoto (que uso para iniciar sesión en el servidor remoto) simplemente no se agregó al grupo remoto de git.

ssh root@<remote_git_server> usermod -G <remote_git_group> <your_remote_user>

Después de eso, compruebe los permisos como se describe en las publicaciones anteriores ...

Esto funciona:

sudo chmod -R gituser.gituser objects

Esto me sucedió cuando traté de git pull . Algunos análisis mostraron que alguien se había comprometido con la raíz en el pasado, creando así algunos objetos con propiedad raíz en .git/objects .

Entonces corrí

cd <repo> la .git/objects/

y que mostró root propiedad root de algunos objetos (directorios) como este:

user@host:/repo> la .git/objects/ total 540 drwxr-xr-x 135 user user 4096 Jun 16 16:29 . drwxr-xr-x 8 user user 4096 Jun 16 16:33 .. drwxr-xr-x 2 user user 4096 Mar 1 17:28 01 drwxr-xr-x 2 user user 4096 Mar 1 17:28 02 drwxr-xr-x 2 user user 4096 Jun 16 16:27 03 drwxr-xr-x 2 user user 4096 Mar 3 13:22 04 drwxr-xr-x 2 root root 4096 Jun 16 16:29 05 drwxr-xr-x 2 user user 4096 Jun 16 16:28 07 drwxr-xr-x 2 root root 4096 Jun 16 16:29 08

Entonces corrí

sudo chown -R user:user .git/objects/

¡Y funcionó!

Estaba reemplazando usuario con mi usuario real, por supuesto.

Intenta hacer lo siguiente:

Ve a tu Servidor

cd rep.git chmod -R g+ws * chgrp -R git * git config core.sharedRepository true

A continuación, vaya a su copia de trabajo (repositorio local) y vuelva a empaquetarla con git repack master

Me funciona a la perfección

Nada de lo anterior funcionó para mí. Un par de horas más tarde encontré el motivo del problema: utilicé una URL de reserva del tipo

ssh://[email protected]/~git/repo.git

Lamentablemente, almacené una sesión de masilla con el nombre example.com que se configuró para iniciar sesión como usuario myOtherUser .

Entonces, mientras creía que git se conectaba al host example.com con el usuario ''git'', Git / TortoiseGit se conectó a la sesión putty example.com que usa el usuario myOtherUser . Esto lleva a exactamente el mismo ..insufficient permission.. (porque ambos usuarios están en grupos diferentes).

Solución: cambie el nombre de la sesión de masilla example.com a [email protected]

OK - Resulta que fue un problema de permisos en GitHub que sucedió durante la bifurcación de emi / bixo a bixo / bixo. Una vez que Tekkub solucionó esto, comenzó a funcionar nuevamente.

Por extraño que parezca, tuve este problema en un clon del repositorio que tenía, pero no en otro. Además de volver a clonar el repositorio (lo que hizo un compañero de trabajo para sortear este problema con éxito), logré hacer un "reinicio de git" de la confirmación que tenía antes de que comenzaran los fracasos. Luego volví a comprometer los cambios, y pude impulsarlos exitosamente después de eso. Entonces, a pesar de todas las indicaciones, había un problema en el servidor, en este caso, aparentemente era indicativo de alguna rareza en el repositorio local.

Por lo general, este problema es causado por permisos incorrectos de usuarios y grupos en su sistema de archivos de servidores Git. El repositorio de git debe ser propiedad del usuario y también de su grupo.

Ejemplo:

Si su usuario se llama "git", su grupo "gitgroup", y la ubicación del repositorio de Git es: [email protected]: path / to / repo.git

luego haz a:

sudo chown -R git:gitgroup path/to/repo.git/

Esto solucionó el error de permiso insuficiente de git para mí.

Recibí este error porque cada vez que un usuario inserta algo de contenido, el grupo del archivo cambia al usuario. Y luego, si algún otro usuario intentaba ingresar al repositorio, causaba un error de permiso y se rechazaba la inserción. Por lo tanto, hay que pedirle a su administrador de sistemas que cambie la configuración del repositorio para que el grupo de cualquier archivo en el repositorio no se modifique por ningún impulso de ningún usuario.

Para evitar dicho problema, asegúrese de que cuando inicialice su repositorio de git, use el comando "git init --shared = group".

Si aún obtiene este error más tarde después de configurar los permisos, es posible que necesite modificar su máscara de creación. Descubrimos que nuestros nuevos commits (carpetas debajo de los objetos) seguían siendo creados sin permiso de escritura grupal, por lo tanto, solo la persona que los había comprometido podría ingresar al repositorio.

Lo solucionamos configurando umask de los usuarios de SSH en 002 con un grupo apropiado compartido por todos los usuarios.

p.ej

umask 002

donde el 0 medio está permitiendo la escritura grupal por defecto.

Supongo que muchos como yo terminamos en foros como este cuando el problema de git como se describe anteriormente se ocura. Sin embargo, hay tantas causas que pueden conducir al problema que solo quiero compartir lo que causó mis problemas para que otros aprendan como ya aprendí de arriba.

Tengo mis repositorios en un NAS Linux de sitecom (nunca compre NAS de Sitecom, pleeaaase). Tengo un repositorio aquí que está clonado en muchas computadoras, pero que de repente se me negó a empujar. Recientemente instalé un complemento para que mi NAS pudiera funcionar como un servidor squeezebox.

Este servidor escanea los medios para compartir. Lo que no sabía era que, posible debido a un error, el servidor cambia la configuración de usuario y grupo para exprimir: usuario para todos los archivos que examina. Y eso son TODOS los archivos. Alterando así los derechos que tuve que empujar.

El servidor se ha ido y se han restablecido los ajustes de derechos adecuados y todo funciona a la perfección.

solía

chmod -R g+ws * chown -R <myuser>:<mygroup> *

Donde myuser y mygroup off-course deben ser reemplazados con la configuración adecuada para su sistema. Prueba git: git o gituser: gituser u otra cosa que te guste.

Verifique el repositorio: $ git remote -v

origin ssh://[email protected]:2283/srv/git/repo.git (fetch) origin ssh://[email protected]:2283/srv/git/repo.git (push)

Tenga en cuenta que aquí hay una subcadena ''git @'', que indica a git que se autentique como nombre de usuario ''git'' en el servidor remoto. Si omite esta línea, git se autenticará con un nombre de usuario diferente, por lo que se producirá este error.

chmod debería ser chown, entonces la línea correcta es:

sudo chown -R gituser:gituser objects

puedes usar esto

sudo chown -R $USER:$USER "$(git rev-parse --show-toplevel)/.git"

user@M063:/var/www/html/app/.git/objects$ sudo chmod 777 -R .git/objects user@M063:/var/www/html/app/.git/objects$ sudo chown -R user:user .git/objects/

sudo chmod 777 -R .git/objects

sudo su root chown -R user:group dir

El dir es tu git repo.

Entonces hazlo:

git pull origin master

Verás cambios sobre commits por parte de otros.