Introduction

The error insufficient permission for adding an object to repository database means Git tried to write a new object and the filesystem or repository permissions blocked it. Even though it often appears during git push, the root cause is usually not the commit itself but who owns the repository storage and whether Git can write into its object database.

What Git Is Trying to Write

Before a push succeeds, Git packages commits, trees, and blobs as objects. In a normal working copy those objects live under .git/objects. In a bare repository on a server, they live in the repository directory itself.

So this error usually means one of two things:

• your local .git directory is not writable by your current user
• the remote bare repository is not writable by the account receiving the push

That is why the message mentions the repository database. Git is talking about its object store, not your application database.

Diagnose the Local Repository First

In many cases, the problem comes from running Git commands once with sudo, extracting an archive as another user, or copying a repository in a way that changed ownership.

Check ownership and permissions locally:

pwd
ls -ld .git .git/objects .git/objects/pack
find .git ! -user "$USER" | head

If files under .git are owned by root or another account, Git may fail when it tries to create new object files or pack files.

For a repository that should belong entirely to your current user, the usual fix is:

sudo chown -R "$USER":"$(id -gn)" .git
find .git -type d -exec chmod u+rwx {} +
find .git -type f -exec chmod u+rw {} +

That repair is appropriate for your own local clone. Do not apply it blindly inside shared repositories you do not administer.

If the Problem Is on the Remote Server

Sometimes the push reaches the server and then fails because the remote bare repository has bad ownership or group permissions. This is common on self-hosted Git servers, shared Unix accounts, or repositories stored on mounted volumes.

An administrator would typically inspect the bare repository like this:

ls -ld /srv/git/project.git
ls -ld /srv/git/project.git/objects /srv/git/project.git/objects/pack

If multiple users are meant to push to the same repository, the fix is usually group-based ownership plus shared write permissions:

1sudo chgrp -R devs /srv/git/project.git
2sudo chmod -R g+rwX /srv/git/project.git
3sudo find /srv/git/project.git -type d -exec chmod g+s {} +
4git --git-dir=/srv/git/project.git config core.sharedRepository group

The setgid bit on directories helps new files inherit the correct group, which prevents the same problem from coming back on the next push.

Distinguish Filesystem Problems from Auth Problems

This message is often confused with plain authentication failures. They are not the same.

• If GitHub rejects your credentials, you usually see an access denied message.
• If a filesystem rejects writes to objects, you usually see this repository-database wording.

That distinction matters because changing SSH keys will not fix a local .git/objects ownership problem, and chown will not fix missing push permission on a hosted Git service.

A quick remote sanity check is still useful:

git remote -v
ssh -T [email protected]

If authentication succeeds but the error still points at object creation, focus on repository storage permissions.

Preventing the Error

The safest habits are simple:

• avoid running git with sudo in normal working copies
• keep shared bare repositories configured with a shared group
• make sure CI jobs and deployment users do not rewrite repository ownership unexpectedly
• be careful when moving repositories across disks, containers, or network shares

Git is very tolerant of many workflow mistakes, but it is not tolerant of an unwritable object store.

Common Pitfalls

• Fixing the working tree files while forgetting that the real problem is under .git.
• Using sudo git commit once, then being surprised that future non-sudo pushes fail.
• Assuming the problem must be with GitHub or GitLab credentials when the message is actually about disk permissions.
• Applying chown -R on a shared repository without understanding who else uses it.
• Ignoring underlying storage issues such as full disks, quotas, or awkward NFS permission mapping.

Summary

• The error means Git cannot write to its object database.
• Check local .git ownership first, especially .git/objects.
• On self-hosted remotes, inspect the bare repository and shared group permissions.
• Do not confuse filesystem permission failures with authentication failures.
• Avoid sudo git in normal repositories unless you deliberately want root-owned Git metadata.