After you add some stuff… commit them and after all finished push it! BANG!! Start all problems… As you should notice there are some differences in the way both new and existent projects were defined. If some other person tries to add/commit/push same files, or content (git keep both as same objects), we will face the following 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
To solve this problem you have to have something in mind operational system’s permissions system as you are restricted by it in this case. Tu understand better the problem, go ahead and check your git object’s folder (.git/objects). You will probably see something like that:
<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
*Note that those file’s permissions were granted only for your users, no one will never can changed it… *
Level u g o
Permission rwx r-x ---
Binary 111 101 000
Octal 7 5 0
SOLVING THE PROBLEM
If you have super user permission, you can go forward and change all permissions by yourself using the step two, in any-other case you will need to ask all users with objects created with their users, use the following command to know who they are:
$ ls -la | awk '{print $3}' | sort -u
<your user_name>
<his user_name>
Now you and all file’s owner users will have to change those files permission, doing:
$ chmod -R 774 .
After that you will need to add a new property that is equivalent to —shared=group done for the new repository, according to the documentation, this make the repository group-writable, do it executing:
$ git config core.sharedRepository group
https://coderwall.com/p/8b3ksg
After you add some stuff… commit them and after all finished push it! BANG!! Start all problems… As you should notice there are some differences in the way both new and existent projects were defined. If some other person tries to add/commit/push same files, or content (git keep both as same objects), we will face the following 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
To solve this problem you have to have something in mind operational system’s permissions system as you are restricted by it in this case. Tu understand better the problem, go ahead and check your git object’s folder (.git/objects). You will probably see something like that:
<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
*Note that those file’s permissions were granted only for your users, no one will never can changed it… *
Level u g o
Permission rwx r-x ---
Binary 111 101 000
Octal 7 5 0
SOLVING THE PROBLEM
If you have super user permission, you can go forward and change all permissions by yourself using the step two, in any-other case you will need to ask all users with objects created with their users, use the following command to know who they are:
$ ls -la | awk '{print $3}' | sort -u
<your user_name>
<his user_name>
Now you and all file’s owner users will have to change those files permission, doing:
$ chmod -R 774 .
After that you will need to add a new property that is equivalent to —shared=group done for the new repository, according to the documentation, this make the repository group-writable, do it executing:
$ git config core.sharedRepository group
https://coderwall.com/p/8b3ksg
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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.
Already on GitHub?
Sign in
to your account
Closed
MartinX3 opened this issue
Feb 27, 2020
· 11 comments
Comments
Sadly it did not change the error @peaceiris
It seems that rarely the checkout put wrong file permissions into the .git folder
And I don’t see a way to workaround it.
It looks like the step «repo-sync-sodp» is running in a container. If it is running as root, then git fetch
files created as root.
To mitigate you can add a step after «repo-sync-sodp» to recursively change file permissions.
- run: | chmod -R ugo+rwX .
Thank you
I will try it today evening
What just wonder me is that I have 8 repos with exact the same workflow file and just this single one has this bug.
Yes @ericsciple
ls -lha .git
in the worflow file shows me
total 60K
drwxr-xr-x 8 runner docker 4.0K Feb 28 21:03 .
drwxr-xr-x 4 runner docker 4.0K Feb 28 21:03 ..
-rw-r--r-- 1 runner docker 249 Feb 28 21:03 FETCH_HEAD
-rw-r--r-- 1 runner docker 40 Feb 28 21:03 HEAD
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 branches
-rw-r--r-- 1 root root 555 Feb 28 21:03 config
-rwxr-xr-x 1 runner docker 73 Feb 28 21:03 description
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 hooks
-rw-r--r-- 1 runner docker 227 Feb 28 21:03 index
drwxr-xr-x 2 runner docker 4.0K Feb 28 21:03 info
drwxr-xr-x 3 runner docker 4.0K Feb 28 21:03 logs
drwxr-xr-x 82 runner docker 4.0K Feb 28 21:03 objects
-rw-r--r-- 1 root root 46 Feb 28 21:03 packed-refs
drwxr-xr-x 5 runner docker 4.0K Feb 28 21:03 refs
-rw-r--r-- 1 runner docker 41 Feb 28 21:03 shallow
But only this single repository has this weird behaviour.
chmod -R ugo+rwX .
results sadly into Operation not permitted
.
Is there anything I can do?
Like somehow removing the files in the container?
Or do they already get new generated on every new action run?
But then I don’t understand why this weird bug (only in this single repo) persist.
oh you might need to sudo chmod -R ugo+rwX .
dooleyb1, damon-demon, and britel-chaimaa20 reacted with hooray emoji
dooleyb1, damon-demon, and dpshelio reacted with rocket emoji
error: insufficient permission for adding an object to repository database .git/objects
My guess is the step «repo-sync-sodp» created one of the git object directories — e.g. .git/objects/ab
— and the next step tried to write to the same folder?
Thank you, that did fix his special/rare bug
Hmmm, but shouldn’t it then happen in every repo and modify the entire .git folder?
It is repo-sync/github-sync@v2
which simply reset my own branches with the ones in the upstream fork (which forces me to use a branch with a special name not existing in the upstream repo) to stay in sync for easy rebasing of my own fork changes.
But again, thank you for fixing it and saving me from the email every 15 minutes.
Glad to hear
The other repos might have enough objects initially that all .git/objects/__
folders are created during checkout (i.e. .git/objects/00/
through .git/objects/ff/
.
If you run ls -la .git/objects
i’m guessing only a subset have a different owner or different permissions (due to creation during «repo-sync-sodp»)
i’m just guessing but error message sounds something like that 🤷♂
wicksome
referenced
this issue
in wicksome/TIL
Dec 8, 2022
Today, when I was pulling changes from a remote repository, the error busted out:
error: insufficient permission for adding an object to repository database .git/objects
The error message indicates the problem itself, current user does not have insufficient permission to add objects to .git/objects folder.
If you’re familiar with Linux ownership and permission, it’s so easy for you. In case of not, read the following topic, it’s really interesting though: Linux Ownership and Permissions
So, we need to grant permission to the folder. We have 2 approaches:
1. Change owner of the folder and its sub-folders to current user
$chown [current-user-name]:[group-name] .git/objects -R
In my case:
$chown ducfilan:root .git/objects -R
Note: current username can be gotten from:
$echo $USER
2. Chmod the folder and its sub-folders to grant write permission to the current user
If you execute the below command, you will see your permission to the objects folder:
$ll .git | grep objects $ll .git/objects
If you faced with the mentioned problem, you will see that you don’t have permission to that folder. Depends on your decision, you can grant which permissions to the folder you want. Maybe:
$chmod 766 .git/objects -R
Now you are ready to pull it down.
P/s: Personally, I recommend the first approach, it’s a natural and secure way.