Remote error unpack failed unpack objects abnormal exit

Remote unpack failed: unpack-objects abnormal exit #13203

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.

Источник

Bitbucket Support

Knowledge base

Products

Jira Software

Project and issue tracking

Jira Service Management

Service management and customer support

Jira Work Management

Manage any business project

Confluence

Bitbucket

Git code management

Resources

Documentation

Usage and admin help

Answers, support, and inspiration

Suggestions and bugs

Feature suggestions and bug reports

Marketplace

Billing and licensing

Frequently asked questions

Viewport

Confluence

Error: Unpack Failed: Unpack-objects Abnormal Exit

Related content

Still need help?

The Atlassian Community is here for you.

Symptoms

Trying to GIT push to remote repository gets to the following error (in command prompt/terminal)

Diagnosis

1. Single user failed to push to remote repository. See #1 cause and resolution.
2. Multiple users failed to push to remote repository. See #2 cause and resolution.

Cause

1. The local repository may be corrupted. See #1 resolution.
2. Disk space in the server hosting Bitbucket Server is full. See #2 resolution.

Resolution

The following resolution shown are referring to the respective cause above.

1. To verify that the local repository is corrupted, you can clone your remote repository to another new directory and then push again. Running git repack might help in case the local repository is indeed corrupted.
2. If disk space is indeed full for Bitbucket Server, clear them and push again.

Источник

Error 500 — error: remote unpack failed: unpack-objects abnormal exit #3373

Description

After a fresh installation, when our fist repository is created, there is an error 500.
This seems to be a permission problem, and we surely need to set the access/write rights inside our Docker-like container (nanobox use Docker but we can’t directly use docker image).
We’ve set theses folders r/w access:

We can found a new folder « repositories/my-company/ » created, so there is no problem to write inside this folder. We can also run « git » command without any problem.

Could you tell me the exact shell command that Gitea try to execute please? There is surely missing rights somewhere.

Thanks
.
PS: BTW, I could share the « boxfile.yml » configuration file when all is ok, to help other nanobox users to install Gitea in few seconds.

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

Источник

If you are a developer, I am sure you heavily depend on VCS (version control systems) to maintain versions of new features with the flexibility to add, merge, and revert changes.

Git is an integral part of a developer’s life. But, unfortunately, errors and failures are imminent when you immensely depend on something.

The tough part is a lot of research is involved in finding a quick and relevant solution. I know this from personal experience.

So, I thought I could try and make it a little less painful by curating some of the most common git network-related errors that one can encounter and see how to fix them easily.

Let’s note some of the troublesome network-related git errors:

1. failed to write object error: remote unpack failed: unpack-objects abnormal exit
2. unable to get local issuer certificate
3. early EOF fatal: index-pack failed
4. the remote end hung up unexpectedly fatal: index-pack failed

The errors mentioned above are some of the common ones that occur. So let’s find out how to fix them.

1. failed to write object error: remote unpack failed: unpack-objects abnormal exit

This error message might scare you. But trust me, the error is quite common when your git local and remote versions are constantly getting appended with new commits.

This error might occur either if your local repo is corrupted or your remote repo space is exhausted.

We have more than one way to fix this.

Fix 1- git-repack: Create a new directory, clone the errored repo, repack, and push.

Pack is a collection of individual delta compressed objects with an associated index stored in a single file.

Repack is used to combine all objects that do not currently reside in a “pack” into a pack.

git repack -a -d -f — depth=250 — window=250

Fix 2- Free up space in a remote repo or buy more space.

2. unable to get local issuer certificate

Configuration is the key to getting better results. When something is misconfigured, you might end up with errors that are hard to trace or fix.

When working with any REST service, an HTTPS handshake is mandated at both the client and the server to establish a secure connection for communication. If the SSL certificate cannot be verified, git cannot complete the HTTPS handshake with the server that hosts the repository. This is when the unable to get local issuer certificate error occurs.

Fix 1- Add the certificate to the trusted certificate store.

On Windows, go to trusted certificate store located at:

Modify ca-bundle.crt by pasting the git SSL certificate to the end of the file. After this, you can perform git pull, push, or clone commands.

Fix 2- Disable SSL certificate validation (not recommended)

Disable the git SSL certificate validation locally.

git -c http.sslVerify=false clone [URL]

You can also disable SSL certificate validation at a global level.

git config — global http.sslVerify false

To re-enable SSL certificate validation, use the following command:

git config — global http.sslVerify false

Fix 3- Reinstall git and choose the SSL transport backend option during the installation process.

3. early EOF fatal: index-pack failed

This error comes up when you are trying to clone a repo from one machine by connecting to the remote server and running the fetch command from another machine due to the memory needs of git.

Fix 1- To truncate the amount of info coming down, you should first turn off compression and do a partial clone. Then, when that works, go into the new directory and retrieve the rest of the clone:

#turn off compression
git config — global core.compression 0
#perform partial clone
git clone — depth 1
#fetch and complete the clone
git fetch — unshallow

Fix 2- Modify your global git configuration file, which is .gitconfig in $USER_HOME.

packedGitLimit = 512m
packedGitWindowSize = 512m
[pack]
deltaCacheSize = 2047m
packetSizeLimit = 2047m
windowMemory = 2047m

4. the remote end hung up unexpectedly fatal: index-pack failed

When trying to clone or fetch a repo, this error might come up if you are under a corporate network or VPN or if Nginx is configured as a reverse proxy.

Fix 1- Disable the anti-virus settings, firewall settings, or VPN client so that the connection can bypass the error.

Fix 2- Change the default value of temp file size in .gitconfig.

Syntax: proxy_max_temp_file_size size;
Default:
Proxy_max_temp_file_size 1024m;
Context: http, server, location

Conclusion

When working on project deadlines, git errors can be a nightmarish roadblock as they require hours of your time troubleshooting and finding a fix. As we all choose to work with our preferred OSs and configurations, solutions that worked for me might not work in your case. There are many underlying factors, and there will always be more than one fix to recover from your state and proceed.

I hope this article will help you with your errors and get back on your development track.

Источник

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.

Источник

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.

This problem is getting weirder.

My original post follows, but here is the new thing I discovered:

I executed

git push

and it gave me its usual error:

Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 588 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: error: unable to create temporary file: No such file or directory
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To USER@REMOTE:/git/PROJECT.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'USER@REMOTE:/git/PROJECT.git'

So being overly optimistic, I thought maybe the «—verbose» option would give me some details, so I immediately tried again:

git push --verbose

and this time it worked:

Pushing to USER@REMOTE:/git/PROJECT.git
Counting objects: 9, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 588 bytes, done.
Total 5 (delta 4), reused 0 (delta 0)
To USER@REMOTE:/git/PROJECT.git
    87d6996..1cae8b3  master -> master
updating local tracking ref 'refs/remotes/origin/master'

so it’s just totally flaky. I’m starting to suspect that git just doesn’t like LDAP.

Original post:

We’re transitioning from cvs to git, and I have a test setup where I have a git server that authenticates users with LDAP, let’s call it REMOTE, and then my personal machine, let’s call it LOCAL. Both machines are Macs. All employees of the company (including me) are members of a group I’ll cleverly call GROUP.

I ssh’d to REMOTE as me and created a git repository there in a folder named /git/PROJECT.git using cvs2git.

Then, back on LOCAL, I did:

git clone USER@REMOTE:/git/PROJECT.git

which was fine. On my Mac («LOCAL») I then edited a few files, deleted a couple, and did

git -a FILES
git rm FILES
git commit -m 'COMMENT'

and life was good.

Then (still on LOCAL) I executed:

git push

to push my changes from LOCAL back to REMOTE and got this:

Counting objects: 19, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (9/9), done.
Writing objects: 100% (10/10), 1.46 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
remote: error: unable to create temporary file: No such file or directory
remote: fatal: failed to write object
error: unpack failed: unpack-objects abnormal exit
To USER@git-server-co.local:/git/PROJECT.git
 ! [remote rejected] master -> master (unpacker error)
error: failed to push some refs to 'USER@git-server-co.local:/git/PROJECT.git'

I researched this problem and it sounded like it might be that might $TMPDIR is wrong, so I ssh’ed to REMOTE, created a directory named /git/tmp, made sure it had write permissions, edited my .bashrc, and set $TMPDIR to /git/tmp.

Back on LOCAL, if I execute

ssh USER@REMOTE echo $TMPDIR

I correctly see the response

/git/tmp

If I ssh to REMOTE and check file permissions, here’s what I see:

ls -l /git
drwxrwxrwx  USER GROUP   tmp
drwxrwsr-x  USER  GROUP   PROJECT.git

ls -l /git/PROJECT.git

all files are rw for owner (me) and group

What else could be causing this error?

p.s. As is the standard on Macs, if I execute:

ssh ADMIN@REMOTE
cd /
ls -l

I see symbolic links: tmp -> /private/tmp, var -> /private/var, and etc -> /private/etc. I adjusted the permissions and ownership so now they are set to:

lrwxr-xr-x   USER   GROUP   etc -> /private/etc
lrwxr-xr-x   USER   GROUP   tmp -> /private/tmp
lrwxr-xr-x   USER   GROUP   var -> /private/var

I also updated the permissions of the actual folders, so if I execute:

cd /private
ls -al

I see:

drwxr-xr-x   USER   GROUP   etc
drwxrwxrwt   USER   GROUP   tmp
drwxr-xr-x   USER   GROUP   var

And finally, if I :

cd /private/var
ls -al

I see:

drwxrwxrwt    USER   GROUP   tmp