Git Push Error: insufficient permission for adding an object to repository database

Question

When I try to push to a shared git remote, I get the following error: insufficient permission for adding an object to repository database

Then I read about a fix here: Fix This worked for the next push, since all of the files were of the correct group, but the next time someone pushed up a change it made a new item in the objects folder that had their default group as the group. The only thing I can think of is to change all of the developer's default group for items they check in, but that seems like a hack. Any ideas? Thanks.

I got this error after accidentally `git add` and `git commit`-ing as root user. I fixed it with a `git reset` and this question's answer to fix the `.git` directory permissions. — StockB, Jun 14 '16 at 18:54
How can I find out *which* object it was trying to create (when manually debugging such permission problems)? The error message is much too vague. — mirabilos, Mar 15 '17 at 14:30
I got this error while copy pasting another .git file first using sudo. therefore, files had sudo sudo as name and group. — Vincent, Apr 10 '20 at 13:09

score 1132 · Accepted Answer · edited May 11 '22 at 13:39

1132

Repair Permissions

After you have identified and fixed the underlying cause (see below), you'll want to repair the permissions:

cd /path/to/repo/.git
sudo chgrp -R groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

Note if you want everyone to be able to modify the repository, you don't need the chgrp and you will want to change the chmod to sudo chmod -R a+rwX .

If you do not fix the underlying cause, the error will keep coming back and you'll have to keep re-running the above commands over and over again.

Underlying Causes

The error could be caused by one of the following:

The repository isn't configured to be a shared repository (see core.sharedRepository in git help config). If the output of:
```
 git config core.sharedRepository
```
is not group or true or 1 or some mask, try running:
```
 git config core.sharedRepository group
```
and then re-run the recursive chmod and chgrp (see "Repair Permissions" above).
The operating system doesn't interpret a setgid bit on directories as "all new files and subdirectories should inherit the group owner".

When core.sharedRepository is true or group, Git relies on a feature of GNU operating systems (e.g., every Linux distribution) to ensure that newly created subdirectories are owned by the correct group (the group that all of the repository's users are in). This feature is documented in the GNU coreutils documentation:

... [If] a directory's set-group-ID bit is set, newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. ... [This mechanism lets] users share files more easily, by lessening the need to use chmod or chown to share new files.

However, not all operating systems have this feature (NetBSD is one example). For those operating systems, you should make sure that all of your Git users have the same default group. Alternatively, you can make the repository world-writable by running git config core.sharedRepository world (but be careful—this is less secure).
The file system doesn't support the setgid bit (e.g., FAT). ext2, ext3, ext4 all support the setgid bit. As far as I know, the file systems that don't support the setgid bit also don't support the concept of group ownership so all files and directories will be owned by the same group anyway (which group is a mount option). In this case, make sure all Git users are in the group that owns all the files in the file system.
Not all of the Git users are in the same group that owns the repository directories. Make sure the group owner on the directories is correct and that all users are in that group.

edited May 11 '22 at 13:39

Black

18,150
39
158
271

answered Jun 23 '11 at 01:13

Richard Hansen

51,690
20
90
97

@Richard Hansen - the result of running that is 'true' – skaz Jun 23 '11 at 02:05
1

@Richard Hansen - I don't really know what you mean by forcing the ownership. I'm looking at the man for chmod but don't know enough about this to have the words make sense :) Any tips? – skaz Jun 23 '11 at 02:08
@skaz: I updated the answer to try to explain the setgid bit some. Please let me know if it is still unclear. – Richard Hansen Jun 23 '11 at 03:21
@skaz: What operating system are you running? What file system? – Richard Hansen Jun 23 '11 at 03:22
@Richard Hansen - I am running Ubuntu Server 10.10. I don't know what file system is running. How can I check? – skaz Jun 23 '11 at 14:59
@skaz: Ubuntu has that setgid feature, so either it's the file system or something else is going on. To determine the file system, `cd` to the directory containing the Git repository and run `df -T .` – Richard Hansen Jun 23 '11 at 17:21
@Richard Hansen - Looks like it is ext4. – skaz Jun 24 '11 at 00:18
@skaz: ext4 should work. Double check that the group owner of all of the repository directories is correct and that all Git users are in that group. – Richard Hansen Jun 24 '11 at 05:39
1

why when i run `git config core.sharedRepository` I get nothing? I'm doing it from the root of my local repo – GiH Aug 02 '12 at 00:25
8

@GiH: You will get nothing if it is unset (which is the same as `false` or `umask`). See `git help config` for more details. – Richard Hansen Aug 02 '12 at 04:22
19

I must had issued `git push` using **root** account in my working directory. I found the owner of some git repository files is **root** (`-r--r--r--. 1 root root 6380 5月 25 12:39 9b44bd22f81b9a8d0a244fd16f7787a1b1d424`) according this answer. – LiuYan 刘研 Jun 06 '13 at 05:09
I think `chmod -R g+rwX .` may be setting the permissions too liberally...that makes all files executable; only directories should be executable. According to another answer on SO you only need to use `g+rw` (it seems that directories in git repos that started as non-shared repos are executable by default even though they're not writable). Also I noticed that files were read-only before running this command so it may be better to omit the first chmod command and just do this: `chmod g+ws \`find . -type d\`` – Matt Browne May 30 '14 at 12:55
5

@MattBrowne: Note that it's a capital `X`, not a lowercase `x`. A capital `X` means "set `S_IXGRP` if the file is a directory (or if any other `S_IX*` bit is set)", so it won't make all files executable. It may be unnecessary, but maybe not if `core.sharedRepository` was set to `0600` at some point in the past. – Richard Hansen May 30 '14 at 21:37
@RichardHansen, Ah, you're right, I didn't realize the upper case. But I still wonder if there's any disadvantage of making all files group-writable, since that's not how git would have set it up if the repo were shared from the beginning. Maybe it doesn't matter, but it doesn't seem necessary. I just changed the permissions on my repo (thanks to your answer) but without making it writable and my colleague can push changes now without a problem. – Matt Browne May 31 '14 at 00:25
I get: `Sorry, user myuser is not allowed to execute '/bin/chown'...` – Francisco Corrales Morales Jul 17 '14 at 15:21
This didn't work for me at all. My users can only push to the remote if the remote repo's folder is owned by them, group permissions (regardless of the chmod setting for that group) are not sufficient and I can't figure out why. – geoidesic Oct 28 '15 at 15:15
@GiH: it must be run in the root folder of the remote repository, not local. – geoidesic Oct 28 '15 at 15:21
Thanks for the solution. My question is what stupid thing I have done to mess up permissions. TIA. – toddwz May 12 '16 at 16:32
This pushed me in the right direction. I have a git repo on a development server with the group set to allow the web server to read/write the files whilst I can read/write as I am the owner. I had to go into the .git directory and set everything to my own group, then it all worked. – Shane Mar 17 '17 at 04:14
what is this line doing? `find . -type d -exec chmod g+s '{}' +` – François Romain May 11 '17 at 19:56
2

@francoisromain: That line sets the setgid bit on all of the directories. See https://www.gnu.org/software/coreutils/manual/html_node/Directory-Setuid-and-Setgid.html – Richard Hansen May 11 '17 at 21:02
@RichardHansen Ok thank you. Now I think I understand until `g+s`, but what is `'{}' +`? – François Romain May 11 '17 at 21:28
1

@francoisromain: See http://pubs.opengroup.org/onlinepubs/9699919799/utilities/find.html – Richard Hansen May 12 '17 at 01:07
My root cause was that I had the repositories stored on external media, and the "git" user on the original host machine had a different uid than the "git" user on the new host machine. – sffc May 14 '17 at 16:12
Been fighting with trying to figure out why I kept being asked for passwords when my ssh key is set up. Turns out that this was the issue, git has to be run with sudo, so the ssh key wasn't being looked up when doing git operations. Thanks man! – kiwicomb123 Jan 09 '18 at 09:01
I cloned an empty repository (created by a different user), added files to the clone, then pushed. For me, before doing step 1 to the new repo as the owner, I had to follow the steps described here: https://gist.github.com/joahking/780877 under the heading "For the impatient" – MrMas Feb 13 '18 at 22:41
All of this worked except the `find` command resulted in errors: `chmod: changing permissions of './objects/##': Operation not permitted` – Brian D Apr 24 '20 at 17:10
Owner was set to 'root', had to change that – Brian D Apr 24 '20 at 20:17
from inside the repos .git folder i did `sudo chmod -R a+rwX .` and then `find . -type d -exec chmod g+s '{}' +` then I could pull from bitbucket: `git pull ssh://git@bitbucket.org/yourUser/your-repo.git`, phew. – Ron Oct 25 '20 at 01:33
I could not get any of these to work on an exFAT formatted drive – user5359531 May 02 '21 at 10:39
I also had to set the user, you are only setting the group: https://stackoverflow.com/a/72202226/4684797 – Black May 11 '22 at 13:49
Thanks, this helped. I believe that in my case the cause was different: I have added some changes in the code in container on share volume. So after adding changes in container then the root synchronized changes to primary location of the volume, therefore .git entries on local volume location were owned by root, as root copied them there from the container. – PtrZlnk Jun 22 '23 at 16:08

score 654 · Answer 2 · edited May 12 '21 at 22:23

654

For Ubuntu (or any Linux)

From project root,

cd .git/objects
ls -al
sudo chown -R yourname:yourgroup *

You can tell yourname and yourgroup by:

# for yourname
whoami
# for yourgroup
id -g -n <yourname>

Note: remember the star at the end of the sudo line

edited May 12 '21 at 22:23

Zois Tasoulas

1,242
1
11
23

answered Oct 21 '11 at 13:04

TerryS

7,169
1
17
13

8

Worked great! Yes, for some reason some of the folders were assigned a different name and group (root). – Peter Arandorenko Jun 17 '14 at 18:57
2

I get: `Sorry, user myuser is not allowed to execute '/bin/chown` – Francisco Corrales Morales Jun 23 '14 at 22:03
11

My problem was I had once done a "git pull" as root, which I think screwed up the permissions...you can check by doing an `ls .git` – rogerdpack Jul 23 '15 at 13:46
1

where can i find yourname:yourgroup? – Grald Dec 25 '16 at 02:29
On my Ubuntu server, this solution worked for me as well. Ty @TerryS – Eric Milliot-Martinez Apr 17 '17 at 18:58
This was my issue as well, because i had previously run `git` commands with a `sudo` prefix, so I had a mixed bag of ownership between my `username group` and `root root. This fix worked perfectly! – Jon Hendershot Dec 30 '18 at 15:30
This worked for me! I prefere this solution to other solutions, that recursively give all permissions to all files in the repository, what might not be desired in some cases. – Andreas Gschossmann Jun 17 '20 at 13:51
Sounds so stupid but in my case I was trying to pull from a user which is not the repository's onwer – tpalanques Nov 23 '20 at 08:49
this happened to me on a WSL2 Ubuntu installation when I did some stuff through a windows git UI (other than VS Code, which is ok) – Gabi Lee Dec 12 '20 at 10:54
2

Nice addition on how to find yourname:yourgroup, @zois - thank you: appreciated – TerryS May 12 '21 at 22:26
Don't remember ever issuing any commands as root, but alas when I booted up this morning and tried a `git pull` I encountered this issue. An `ls -al` showed some of the directories owned by root. Your fix worked. Thank you! – Stetzon Aug 11 '21 at 12:59
My user and group was already set correctly but permissions where missing. `sudo chmod -R 775 .git/objects/*` did the trick! – CodeNinja Sep 24 '21 at 09:38

score 212 · Answer 3 · edited Jan 09 '23 at 15:32

212

use the following command, works like magic

sudo chown -R "${USER:-$(id -un)}" .

type the command exactly as it is (with extra spaces and one dot at the end)

breakdown of command

sudo

run as root user

chown

change ownership

-R

Recursive action against all files and folders

"${USER:-$(id -un)}"

Get the user name from $USER and if that is not set get the value from running id -un

Target the current directory

edited Jan 09 '23 at 15:32

rob

8,134
8
58
68

answered Feb 19 '18 at 12:39

Code_Worm

4,069
2
30
35

2

Can you please explain what this part does: "${USER:-$(id -un)}" . – Neerkoli Mar 10 '21 at 05:30
4

This answer should specify which directory to execute the command. Either root of repo or the .git folder. – MikeKulls Sep 06 '22 at 02:53
@MikeKulls Good point. I'm afraid to run it without knowing which folder. – Justin Breen Jan 06 '23 at 22:47
1

I run it in project folder and it worked – christk May 23 '23 at 21:26

score 61 · Answer 4 · edited Jun 06 '17 at 00:18

61

sudo chmod -R ug+w .;

Basically, .git/objects file does not have write permissions. The above line grants permission to all the files and folders in the directory.

edited Jun 06 '17 at 00:18

Henry

564
3
22

answered Dec 23 '15 at 06:40

Rajendra kumar Vankadari

2,247
1
16
16

4

This is what worked for me. The accepted answer sadly didn't. Thanks Rajendra! – revelt Nov 30 '16 at 17:33

score 30 · Answer 5 · answered Feb 14 '12 at 18:18

30

I just wanted to add my solution. I had a repo on OS X that had ownership of root on some directories and Home (which is my user directory) on others which caused the same error listed above.

The solution was simple thankfully. From terminal:

sudo chown -R Home projectdirectory

answered Feb 14 '12 at 18:18

Brandon

1,399
4
20
37

Same thing happened to me. I can't figure out how some of the objects got root ownership, but they did. – vy32 Jun 09 '14 at 02:05

score 22 · Answer 6 · edited Sep 04 '15 at 10:53

22

Solved for me... just this:

sudo chmod 777 -R .git/objects

edited Sep 04 '15 at 10:53

Arnaud

7,259
10
50
71

answered Sep 04 '15 at 10:47

GUSTAVO BERBERT

445
4
3

28

`Chmod 777` isn't recommended as it exposes all of your file to the rest of the world making your machine vulnerable – Elena Oct 19 '15 at 12:27
28

If your advice is ``chmod 777``, 99 times out of 100 you do not understand the issue and you are likely to cause more problems than you help solve. As the accepted answer above shows, this issue is no different. – jonatan Oct 27 '15 at 14:45
1

Why do you guys do not propose an acceptable answer instead say that's a wrong choice? – Giovani Mar 09 '17 at 16:28
4

Because even though there are acceptable answers on the page, this unacceptable answer is still here. – Teh JoE Aug 24 '17 at 16:00
sudo chmod -R 777 .git/objects – Nabeel Ahmed Apr 09 '18 at 09:31
2

777 permission is not recommend. – Pyae Sone May 14 '20 at 08:33

Mauvis Ledford · Answer 7 · 2011-06-23T04:43:11.953

A good way to debug this is the next time it happens, SSH into the remote repo, cd into the objects folder and do an ls -al.

If you see 2-3 files with different user:group ownership than this is the problem.

It's happened to me in the past with some legacy scripts access our git repo and usually means a different (unix) user pushed / modified files last and your user doesn't have permissions to overwrite those files. You should create a shared git group that all git-enabled users are in and then recursively chgrp the objects folder and it's contents so that it's group ownership is the shared git group.

You should also add a sticky bit on the folder so that all the files created in the folder will always have the group of git.

chmod g+s directory-name

Update: I didn't know about core.sharedRepository. Good to know, though it probably just does the above.

score 18 · Answer 8 · answered Oct 02 '20 at 09:52

18

The sumplest solution is:

From the project dir:

sudo chmod 777 -R .git/objects

answered Oct 02 '20 at 09:52

Jackkobec

5,889
34
34

This same answer is proposed above by arnaud. For reasons explained there, it is a Bad Idea. – Mike Maxwell Oct 26 '21 at 18:24
This is a quick solution to solve this problem without dancing with a tambourine – Jackkobec Oct 27 '21 at 10:25
3

it's a quick solution in the same sense that removing your door is a quick solution to you not getting into your home. It works, but it's very much not where your mind should go – Jujinko Nov 18 '22 at 13:44
Doors removing is the quickest way to enter)In fact this is quick bypass way to solve this problem. There are a lot of alternatives, some of them we can see in this topic. – Jackkobec Nov 18 '22 at 15:46

score 14 · Answer 9 · answered Jul 09 '21 at 12:16

14

just copy and paste this into your own terminal.

sudo chown -R "${USER:-$(id -un)}" .

answered Jul 09 '21 at 12:16

Павел Манкевич

171
1
3

score 9 · Answer 10 · answered Sep 05 '14 at 12:12

This can easily happen if you ran git init with a different user from the one you are planning to use when pushing changes.

If you blindly follow the instructions on [1] this will happen as you probably created the git-user as root and then immediately moved on to git init without changing user in between.

[1] http://git-scm.com/book/en/Git-on-the-Server-Setting-Up-the-Server

score 9 · Answer 11 · answered Dec 02 '16 at 15:26

9

Linux, macOS:

cd .git/
sudo chown -R name:group *

where name is your username and group is the group that your username belongs to.

answered Dec 02 '16 at 15:26

Afshin Mehrabani

33,262
29
136
201

Vaibhav Jain · Answer 12 · 2022-06-29T18:37:22.040

9

You need to copy and paste this command on your terminal :-

sudo chmod 777 -R .git/objects

edited Jun 29 '22 at 18:37

answered Jan 10 '22 at 11:51

Vaibhav Jain

305
3
8

score 5 · Answer 13 · answered Feb 14 '14 at 00:04

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

I had all the same `username:groupname` for mine, but when I tried `chmod -R 774 .`, I could then run `git add --all` successfully. — skilbjo, Jul 15 '15 at 20:32

tuxErrante · Answer 14 · 2020-12-17T15:14:06.727

I'll add my two cents just as a way to discover files with a specific ownership inside a directory.

The issue was caused by running some git command as root. The received message was:

$ git commit -a -m "fix xxx"
error: insufficient permission for adding an object to repository database .git/objects
error: setup.sh: failed to insert into database

I first looked at git config -l, then I resolved with:

find .git/ -exec stat --format="%G %n" {} + |grep root

chown -R $(id -un):$(id -gn) .git/objects/

git commit -a -m "fixed git objects ownership"

score 3 · Answer 15 · answered Feb 20 '15 at 15:20

For my case none of the suggestions worked. I'm on Windows and this worked for me:

Copy the remote repo into another folder
Share the folder and give appropriate permissions.
Make sure you can access the folder from your local machine.
Add this repo as another remote repo in your local repo. (git remote add foo //SERVERNAME/path/to/copied/git)
Push to foo. git push foo master. Did it worked? Great! Now delete not-working repo and rename this into whatever it was before. Make sure permissions and share property remains the same.

In my case, simply copying the local folder to a new folder, deleting the old one, and renaming the new one to the old name fixed the permissions issues. — mgiuffrida, Jan 30 '17 at 21:33

score 2 · Answer 16 · answered Nov 20 '13 at 17:06

I hit this same issue. Reading around here I realised it was file permissions the message was referring to. The fix , for me, was in:

/etc/inetd.d/git-gpv

It was starting git-daemon as user 'nobody' so lacked the write permission.

# 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

(I doubt other call their inetd conf file git-gpv . Commonly it would be directly in /etc/inetd.conf)

score 2 · Answer 17 · answered Apr 18 '19 at 09:25

2

Works for me

sudo chmod -R g+rwX .

answered Apr 18 '19 at 09:25

Nitin .

808
9
12

score 1 · Answer 18 · answered Dec 04 '14 at 19:06

You need the sufficient write permissions on the directory that you are pushing to.

In my case: Windows 2008 server

right click on git repo directory or parent directory.

Properties > Sharing tab > Advanced Sharing > Permissions > make sure the user has appropriate access rights.

score 1 · Answer 19 · answered Nov 19 '18 at 08:00

There is a possibility also that you added another local repository with the same alias. As an example, you now have 2 local folders referred to as origin so when you try to push, the remote repository will not accept you credentials.

Rename the local repository aliases, you can follow this link https://stackoverflow.com/a/26651835/2270348

Maybe you can leave 1 local repository of your liking as origin and the others rename them for example from origin to anotherorigin. Remember these are just aliases and all you need to do is remember the new aliases and their respective remote branches.

score 1 · Answer 20 · answered May 11 '22 at 13:47

1

Repair Permissions

I used this to repair my .git folder, the answer of @richard-hansen was missing the user.

First you need to go into the .git folder.

cd /path/to/repo/.git

Then execute these commands.

sudo chown -R user:groupname .
sudo chmod -R g+rwX .
sudo find . -type d -exec chmod g+s '{}' +

This will also fix all submodules.

answered May 11 '22 at 13:47

Black

18,150
39
158
271

This worked on my MacOS Ventura – dirtyqwerty Jan 06 '23 at 16:00

score 1 · Answer 21 · answered Jun 01 '22 at 16:06

There is one more solution to this problem which can be reproduced when you work with multiple running docker containers and try to change and commit/push something.

In my case I could not commit anything while all the containers where up. But as soon as I killed them - I was able to commit without any issues.

I did not study the reason for such a behavior much, but I can guess that the code which you are changing locally is reused in a docker container and as it's being run from root user and thus it can change some permissions of the files it works with - this can cause an issue.

score 0 · Answer 22 · answered Jun 26 '19 at 22:11

0

I got this when pulling into an Rstudio project. I realised I forgot to do:

sudo rstudio

on program startup. In fact as there's another bug I've got, I need to actually do:

sudo rstudio --no-sandbox

answered Jun 26 '19 at 22:11

Timothy M Pollington

103
5

score 0 · Answer 23 · answered Oct 23 '20 at 19:32

After using git for a long time without problems, I encountered this problem today. After some reflection, I realized I changed my umask earlier today from 022 to something else.

All the answers by other people are helpful, i.e., do chmod for the offending directories. But the root cause is my new umask which will always cause a new problem down the road whenever a new directory is created under .git/object/. So, the long term solution for me is to change umask back to 022.

score 0 · Answer 24 · answered Jan 14 '21 at 10:37

I was getting this error when running a remote development development machine using Vagrant. None of the above solutions worked because all the files had the correct permissions.

I fixed it by changing config.vm.box = "hasicorp/bionic64" to config.vm.box = "bento/ubuntu-20.10".

score 0 · Answer 25 · answered Jun 26 '21 at 04:26

In my case, the solution was simply to git commit again.

The problem went away automatically.

What happened? I used ^C (Control-C) to break out of writing a bad commit message. (I pasted the wrong message from the wrong clipboard.) So I assume the process was temporarily frozen in the background, which locked up the database temporarily.

score 0 · Answer 26 · answered Sep 22 '21 at 12:50

I got this issue resolved by making use of ssh:// based URL instead of http:// based URL.

I had cloned the repository quite a few days earlier using the http:// based URL. In between the cloning and pushing, I had to enable 2FA on my account and subsequently get my public key added to the code repository.

Due to enabled 2FA the http:// URL was not working properly.

score 0 · Answer 27 · answered Feb 13 '22 at 13:30

Make sure you open the command line prompt as admin. Then, make sure project files are not read-only.

In windows, you can check this by right-clicking on project folder -> click "Show more options" -> click "Properties" -> deselect "Read-only" -> click "Apply"

score 0 · Answer 28 · answered Apr 15 '22 at 12:43

0

I faced this problem too many times but every time it occurs I try to push or commit using the sudo command and the after typing my password i push or commit without sudo for example

sudo git commit -m "message"

then after typing my password i again

git commit -m "message"

answered Apr 15 '22 at 12:43

sharif

23
2

This does not really answer the question. If you have a different question, you can ask it by clicking [Ask Question](https://stackoverflow.com/questions/ask). To get notified when this question gets new answers, you can [follow this question](https://meta.stackexchange.com/q/345661). Once you have enough [reputation](https://stackoverflow.com/help/whats-reputation), you can also [add a bounty](https://stackoverflow.com/help/privileges/set-bounties) to draw more attention to this question. - [From Review](/review/late-answers/31544778) – Ethan Apr 18 '22 at 00:07
1

@Ethan, it actually does. It even works. – Black May 09 '22 at 15:36
@Black No, it doesn’t work. In fact, it screws things up even worse. **Never** do this. Fix your file permissions instead (basically, do `chown -R $(id -u):$(id -g) .` and, only if that doesn’t work, rerun the `chown` command with `sudo`). As a general rule, don’t randomly run `sudo` without understanding the consequences. – Konrad Rudolph May 12 '22 at 11:17

score 0 · Answer 29 · answered May 09 '22 at 15:36

0

I just tried sudo git commit -m "XY" then I canceled it with CTRL + C and tried again with git commit -m "XY" then it suddenly worked.

answered May 09 '22 at 15:36

Black

18,150
39
158
271

score 0 · Answer 30 · answered Mar 13 '23 at 14:42

0

EASIEST & SIMPLEST SOLUTION ↓

sudo chmod 777 -R /path/to/your/git/repository/.git/objects

answered Mar 13 '23 at 14:42

Rizwan

363
3
10

score 0 · Answer 31 · answered Jul 15 '23 at 06:13

0

If you are facing this issue in git bash, EC2 instance or any linux, ubuntu, macOS system. You can try to run:

sudo git add .

It works for me in AWS EC2 ubuntu instance.

answered Jul 15 '23 at 06:13

Shubhanshu Kashiva

136
1
1
7

score -1 · Answer 32 · answered Jan 06 '20 at 15:08

-1

I was getting this problem with a remote repository on a Samba share; I pulled successfully from this remote, but failed when pushing to it.

The cause of the error was incorrect credentials in my ~/.smbcredentials file.

answered Jan 06 '20 at 15:08

Josh

7,936
5
41
63

Git Push Error: insufficient permission for adding an object to repository database

32 Answers32

Repair Permissions

Underlying Causes

Repair Permissions

Linked

Related