Git push rejected unpacker error

How to Fix Git Push Insufficient Permission Error for Objects Permanently Sometimes when you do a git push, you might get the following permission error message. This error typically happens when multiple users are working on a particular git repository. The following git push error indicates that it doesn’t have enough permission for adding […]

Содержание

  1. How to Fix Git Push Insufficient Permission Error for Objects Permanently
  2. Set the Appropriate Permissions on Objects Directory
  3. Share the Git Repository with a Group
  4. Remote unpack failed: unpack-objects abnormal exit #13203
  5. Comments
  6. Description

How to Fix Git Push Insufficient Permission Error for Objects Permanently

Sometimes when you do a git push, you might get the following permission error message.

This error typically happens when multiple users are working on a particular git repository.

The following git push error indicates that it doesn’t have enough permission for adding a new object to the ./objects directory under your repository.

Apart from the obvious permission issue, there is also another underlying problem that needs to be addressed, which is explained in this tutorial.

It also shows that the git unpack failed with unpack-objects abnormal exit. Because of this error, it failed to push some refs as shown above.

First, cd to the git repository which is having this issue. If you don’t see the objects directory directly under your repository folder, then look under the .git folder as shown below.

In this particular case, when john is trying to do ‘git push’, he is getting the above error because some of the directories under the objects folder of git repository are owned by lisa as shown below.

Set the Appropriate Permissions on Objects Directory

To solve this problem, execute the following, which will set the group to git (or whatever group where all the users belongs to. Also make sure the user and group has read and write permission to the directory.

  • Make sure all your users who need access to git are part of the git group. Change the “git” in the above chgrp command to whatever group where all your developers belong to.
  • The “s” option in the “g+rws” is to set the setuid bit on the objects folder. This will make sure any new directory created under objects folder will make the group name from the objects folder which is owned by git group.

You may be tempted to execute the following on your objects directory, which will solve the problem that you are having. But, as you can imagine, it is not a good idea to do 777. Instead execute the above chgrp and chmod command.

But, even after doing the above, the same problem might return again, and you may have to do the above chgrp and chmod whenever the problem occurs.

So, apart from fixing the permission error as explained above, we also need to fix the underlying problem.

In this case, the git repository (for example: myproj) is not setup as shared repository for groups. It might just be a bare repository.

If it is not setup as shared repository, you’ll see the above “insufficient permission on objects directory” issue starts to show-up again.

To verify whether your repository is already setup for group sharing, do the following git config -l option inside your git repository that has the problem.

In the above output, we don’t see a parameter called “core.sharedrepository”. So, this particular repository (i.e myproj is not setup as shared repository).

The above command displays the configuration values from the “config” file that is located under your git repository.

The above is setup as a bare repository. To convert a bare repository to shared repository, do the following:

Note: In the above command, don’t replace the keyword “group” with your groupname (for example: git). Use the above above command exactly as shown without changing anything. The “group” in the above command should be typed exactly as it is.

Now, if you view the git config as shown below, you’ll see the “core.sharedrepository” parameter set to group.

The above will solve the insufficient permission issue permanently.

After you set the sharedrepository, if you view the config file under your git repository, you’ll notice that the value of sharedrepository parameter is set to 2 (which is group) as shown below.

Источник

Remote unpack failed: unpack-objects abnormal exit #13203

  • Gitea version (or commit ref): 1.12.4
  • Git version: 2.28.0
  • Operating system: Linux
  • Go version: 1.15.3
  • Database (use [x] ):
    • PostgreSQL
    • MySQL
    • MSSQL
    • SQLite
  • Can you reproduce the bug at https://try.gitea.io:
    • Yes (provide example URL)
    • No
  • Log gist:
    I have not found any errors in gitea.log.

Description

After updating Gitea from 1.12.1 to 1.12.4 I am unable to push changes. Everytime I try to do that I got the following error:

Enter passphrase for key ‘/path/to/.ssh/id_rsa’:
Enumerating objects: 29, done.
Counting objects: 100% (29/29), done.
Delta compression using up to 16 threads
Compressing objects: 100% (14/14), done.
Writing objects: 100% (15/15), 5.13 KiB | 5.13 MiB/s, done.
Total 15 (delta 13), reused 3 (delta 1), pack-reused 0
remote: fatal: not a git repository: ‘.’
error: remote unpack failed: unpack-objects abnormal exit
To ssh://git.com:9999/group/repo.git
! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to ‘ssh://git.com:9999/group/repo.git’

This happens to all repositories hosted at Gitea. I tried to launch git fsck on server side and found no errors. I can clone repository, browse it via webui, etc, just cannot push changes back to remote.
I am pretty sure, you will need some additional data. Please let me know what I can do in order to investigate this.

The text was updated successfully, but these errors were encountered:

@belliash do you use the build in ssh server?

Yes, I use ssh server that is built into gitea, listening on custom port.
In logs I found just this:

2020/10/18 21:49:43 modules/ssh/ssh.go:63:sessionHandler() [T] SSH: Payload: git-receive-pack ‘/group/repo.git’
2020/10/18 21:49:43 modules/ssh/ssh.go:66:sessionHandler() [T] SSH: Arguments: [serv key-5 —config=/path/to/app.ini]

There are also some SQL queries like:
SELECT id , owner_id , name , fingerprint , content , mode , type , login_source_id , created_unix , updated_unix FROM public_key WHERE (content like ?) LIMIT 1

and permissions loaded:
2020/10/18 21:49:44 . s/repo_permission.go:154:func1() [T] Permission Loaded for 1:user in 41:group/repo:
Permissions: AccessMode: 4:owner, 5 Units, 0 UnitsMode(s): [
Units[0]: ID: 281 RepoID: ? Type: 1:UnitTypeCode Config: <>
Units[1]: ID: 326 RepoID: ? Type: 2:UnitTypeIssues Config: <«EnableTimetracker»:false,»AllowOnlyContributorsToTrackTime»:false,»EnableDependencies»:true>
Units[2]: ID: 327 RepoID: ? Type: 3:UnitTypePullRequests Config: <«IgnoreWhitespaceConflicts»:false,»AllowMerge»:true,»AllowRebase»:true,»AllowRebaseMerge»:true,»AllowSquash»:true>
Units[3]: ID: 282 RepoID: ? Type: 4:UnitTypeReleases Config: <>
Units[4]: ID: 325 RepoID: ? Type: 5:UnitTypeWiki Config: <> ]
2020/10/18 21:49:44 . ters/private/serv.go:363:ServCommand() [D] Serv Results:
IsWiki: false
IsDeployKey: false
KeyID: ? KeyName: user@host
UserName: user
UserID: ?
OwnerName: group
RepoName: repo
RepoID: ?

I obfuscated logs from some sensitive data.

I have just found out that I cannot edit files online via web interface, because I got another error:

I checked permissions and they look ok. I can write under that path as well as git user. On the other hand setting chmod recursively to 777 does not resolve this.

The second problem looks somehow similar to #12085 except I got xattr enabled. I wonder if both are connected.

Источник

Comments

@gitblit

Originally reported on Google Code with ID 408

What steps will reproduce the problem?
see below

What is the expected output? What do you see instead?
I am using git-flow and need to push & pull develop and master branch from gitblit.
It works fine several days ago but right now it produce
errors for develop branch (only for push, pull seems fine). The error messhage looks
like (master branch is exactly fine!!!)
 [remote rejected] develop -> develop (n/a (unpacker error))
updating local tracking ref 'refs/remotes/origin/master'
error: failed to push some refs to 'https://admin@xx.xx.xx.xx:xxxx/r/~xxx/workplace.git'

I try other branch (newly created), also shows the same message. And the same probelm
for all other repository.

I then try to restart the gitblit and windows, nothing changes...

I also try to delete the repository from the webUI, it shows error messages too. 

What version of the product are you using? On what operating system?

v1.4.1 (windows 7 64bit)

Please provide any additional information below.


Reported by ray4working on 2014-04-17 00:49:57

@gitblit



Copy link


Collaborator

Author

This appears to be a bug in JGit [1, 2].  You didn't share the server-side stacktraces,
but I will assume they each point to the same thing: missing tree or missing blob.

Newer git clients are optimized to send less data on the wire.  JGit doesn't like this
at the moment.  There is a receive pack setting which may help, but Gitblit does not
allow you to configure it.  I will take care of that later today for the upcoming 1.5.0
release, but that is just a workaround.  To really fix this issue, JGit has to be updated
to handle the newer git client optimizations.

For now, it looks like the current client-side recommendation is to downgrade your
git client to an older version that isn't as smart/optimized.  It looks like 1.8.3
or older might work.

[1]: https://code.google.com/p/gerrit/issues/detail?id=2296
[2]: https://code.google.com/p/gerrit/issues/detail?id=1582

Reported by James.Moger on 2014-04-17 13:19:03

@gitblit



Copy link


Collaborator

Author

I've pushed changes to master to expose the newer receivepack settings, but like I said,
this is a workaround. The real fix needs to be implemented by the JGit team within
JGit's internals.

Reported by James.Moger on 2014-04-17 16:07:12

  • Status changed: Started

@gitblit



Copy link


Collaborator

Author

Hi, Thank you very much.
I've done a clean installation yesterday (remove everything and push repos after clean
installation), so it is hard to directly test whether an older git client can solve
the problem(e.g. downgrade)at the moment. However, I am using sourcetree and the internal
git client is version 1.8.3 (so it seems that an even older version might be better,
though I have not tried them yet).
btw, I will built your updated version to see if it can reduce the problems(at least
temporarily). 
Do I need to also report this issue to JGIT? 

Reported by ray4working on 2014-04-18 00:45:27

@gitblit



Copy link


Collaborator

Author

It has already been reported to Bugzilla [1].  Now we'll have to see when it gets resolved.
 :)

[1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=422988

Reported by James.Moger on 2014-04-18 01:09:29

@gitblit



Copy link


Collaborator

Author

This is a shitty bug.  I get hit by it a few times a month.  Disabling the reachable
check is the workaround until a fix lands in JGit. I've updated the FAQ - this is now
the first entry.

Reported by James.Moger on 2014-06-17 00:32:21

@gitblit



Copy link


Collaborator

Author

Appears to now be fixed upstream, in link from comment 4.

Reported by soruk42 on 2014-11-24 18:29:58

@gitblit



Copy link


Collaborator

Author

Release 1.6.1 included the updated JGit with the fix.

Reported by James.Moger on 2015-03-07 15:47:32

  • Status changed: Fixed
  • Labels added: Milestone-1.6.1

2 participants

@gitblit

@flaix

Sometimes when you do a git push, you might get the following permission error message.

This error typically happens when multiple users are working on a particular git repository.

The following git push error indicates that it doesn’t have enough permission for adding a new object to the ./objects directory under your repository.

Apart from the obvious permission issue, there is also another underlying problem that needs to be addressed, which is explained in this tutorial.

$ git push
counting objects: 6, done.
Delta compression using upto 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 388 bytes, | 0 bytes/s, done.
Total: 4 (delta 1), reused 0 (delta 0)

error: insufficient permission for adding an object to repository database ./objects
fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
 ! [remote rejected] master -> master (n/a (unpacker error))
error: failed to push some refs to john@192.168.100.1:/home/git/myproj

It also shows that the git unpack failed with unpack-objects abnormal exit. Because of this error, it failed to push some refs as shown above.

First, cd to the git repository which is having this issue. If you don’t see the objects directory directly under your repository folder, then look under the .git folder as shown below.

[john@devdb]$ cd /home/git/myproj
(or)
[john@devdb]$ cd /home/git/myproj/.git

In this particular case, when john is trying to do ‘git push’, he is getting the above error because some of the directories under the objects folder of git repository are owned by lisa as shown below.

[john@devdb]$ ls -l objects
drwxr-xr-x 2 john  git 4096 Oct  8  2016 01
drwxr-xr-x 2 john  git 4096 Oct  8  2016 02
drwxr-xr-x 2 lisa lisa 4096 Oct  8  2016 03
drwxr-xr-x 2 lisa lisa 4096 May  1  2017 04
drwxr-xr-x 2 john  git 4096 May  1  2017 05
drwxr-xr-x 2 john  git 4096 May  6  2017 06

Set the Appropriate Permissions on Objects Directory

To solve this problem, execute the following, which will set the group to git (or whatever group where all the users belongs to. Also make sure the user and group has read and write permission to the directory.

cd /your/git/repo

chgrp -R git objects

chmod -R g+rws objects

In the above:

  • Make sure all your users who need access to git are part of the git group. Change the “git” in the above chgrp command to whatever group where all your developers belong to.
  • The “s” option in the “g+rws” is to set the setuid bit on the objects folder. This will make sure any new directory created under objects folder will make the group name from the objects folder which is owned by git group.

You may be tempted to execute the following on your objects directory, which will solve the problem that you are having. But, as you can imagine, it is not a good idea to do 777. Instead execute the above chgrp and chmod command.

chmod -R 777 objects

Share the Git Repository with a Group

But, even after doing the above, the same problem might return again, and you may have to do the above chgrp and chmod whenever the problem occurs.

So, apart from fixing the permission error as explained above, we also need to fix the underlying problem.

In this case, the git repository (for example: myproj) is not setup as shared repository for groups. It might just be a bare repository.

If it is not setup as shared repository, you’ll see the above “insufficient permission on objects directory” issue starts to show-up again.

To verify whether your repository is already setup for group sharing, do the following git config -l option inside your git repository that has the problem.

$ cd /home/git/myproj

$ git config -l
user.name=John Smith
user.email=john@thegeekstuff.com
core.repositoryformatversion=0
core.filemode=true
core.bare=true
core.logallrefupdates=true

In the above output, we don’t see a parameter called “core.sharedrepository”. So, this particular repository (i.e myproj is not setup as shared repository).

The above command displays the configuration values from the “config” file that is located under your git repository.

$ cd /your/git/repo

$ cat config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        logallrefupdates = true

The above is setup as a bare repository. To convert a bare repository to shared repository, do the following:

git config core.sharedRepository group

Note: In the above command, don’t replace the keyword “group” with your groupname (for example: git). Use the above above command exactly as shown without changing anything. The “group” in the above command should be typed exactly as it is.

Now, if you view the git config as shown below, you’ll see the “core.sharedrepository” parameter set to group.

$ git config -l
user.name=John Smith
user.email=john@thegeekstuff.com
core.repositoryformatversion=0
core.filemode=true
core.bare=true
core.logallrefupdates=true
core.sharedrepository=group

The above will solve the insufficient permission issue permanently.

After you set the sharedrepository, if you view the config file under your git repository, you’ll notice that the value of sharedrepository parameter is set to 2 (which is group) as shown below.

$ cat config 
[core]
        repositoryformatversion = 0
        filemode = true
        bare = true
        sharedrepository = 2
[receive]
        denyNonFastforwards = true

Also, anytime you make a git repository as sharedrepository for group using the above command, it will also set the receive.denyNonFastforwards to true automatically as shown above.

Понравилась статья? Поделить с друзьями:

Читайте также:

  • Git push error code 22
  • Git pull error your local changes to the following files would be overwritten by merge
  • Git pull error cannot lock ref
  • Git public key error
  • Git needs merge error you need to resolve your current index first

  • 0 0 голоса
    Рейтинг статьи
    Подписаться
    Уведомить о
    guest

    0 комментариев
    Старые
    Новые Популярные
    Межтекстовые Отзывы
    Посмотреть все комментарии