Fixing Git: 'insufficient permission for adding an object'

Overview

This error means Git cannot write a new object into .git/objects. It usually comes from incorrect file ownership, restrictive permissions, a read-only filesystem, or security policies (SELinux/AppArmor). It often appears after using sudo, on shared repositories, or on network filesystems.

Common message:

• error: insufficient permission for adding an object to repository database

Your goal: ensure the user running Git can create files inside .git/objects (and .git/objects/pack) and update lock files.

Quickstart (most cases on Linux/macOS)

Run from the repository root:

# 1) Fix ownership (replace user:group as needed)
sudo chown -R "$USER":"$(id -gn)" .git

# 2) For shared repos, make group-writable and set setgid bit on dirs
find .git -type d -exec chmod 2775 {} +
find .git -type f -exec chmod 664 {} +

# 3) Prevent future mismatches in shared setups
git config core.sharedRepository group
# or for a bare central repo:
# git config --global init.defaultBranch main
# git config core.sharedRepository 0660

# 4) If a stale lock exists (after verifying no Git is running)
rm -f .git/index.lock

# 5) Retry your operation
git add -A && git commit -m "test"

If the repository is on SELinux-enforcing hosts and was moved/restored manually:

sudo restorecon -R -v "$(pwd)"

If the filesystem is read-only, remount or move the repo to a writable location.

Minimal working example (reproduce and fix)

# Create a repo and deliberately break permissions
mkdir demo && cd demo
git init
printf 'x\n' > file.txt
# Make objects directory non-writable
chmod a-w .git/objects

# This will fail
set +e
git add file.txt || echo "Observed: insufficient permission error"
set -e

# Fix: restore write permission for the owner
chmod u+rwX -R .git/objects

# Try again
git add file.txt && git commit -m "ok"

Step-by-step diagnosis

1. Confirm the path and error

• Ensure you are in the repository root (contains .git).

1. Check if the repo is bare or non-bare

• Bare repos have objects directly under repo/objects. Non-bare repos have .git/objects.

1. Inspect ownership and permissions

ls -ld .git .git/objects .git/objects/pack
find .git -maxdepth 2 -printf "%M %u:%g %p\n" | head -n 20

• Mismatched owners (e.g., root) indicate prior sudo use.

1. Detect read-only filesystem

mount | grep " $(pwd | cut -d/ -f1-2) "
# or
test -w .git/objects && echo writable || echo read-only

1. Look for stale locks

ls -l .git/index.lock .git/refs/*.lock 2>/dev/null || true

• Remove only if you’re sure no Git process is active.

1. On SELinux systems

getenforce
# If Enforcing and contexts look wrong:
sudo restorecon -R -v .

1. On Windows

• Check if the repo folder or .git is Read-only.
• Ensure antivirus isn’t locking .git/objects.
• Re-run from Git Bash or PowerShell with user write permissions.

Typical fixes by scenario

• After using sudo in a repo

  • sudo chown -R "$USER":"$(id -gn)" .git
  • Avoid running Git as root in working copies.

• Shared repo for a team (group collaboration)

  • chgrp -R <group> .git
  • find .git -type d -exec chmod 2775 {} +
  • find .git -type f -exec chmod 664 {} +
  • git config core.sharedRepository group
  • Set umask 002 for all collaborators.

• Bare central repository

  • Ensure repo and parent dirs are owned by the service user/group.
  • Set 2775 on directories to preserve group ownership.
  • core.sharedRepository 0660 or group.

• Network shares (NFS/SMB)

  • Use NFS options that allow file creation and locking (avoid root_squash for admin-only ops or use a non-root service user).
  • Ensure consistent UID/GID mapping across clients.
  • Prefer a local filesystem for performance and reliability of Git objects.

• SELinux/AppArmor

  • restorecon -R -v /path/to/repo
  • For services (e.g., git-daemon, sshd), ensure the service contexts permit writes.

• Windows

  • Clear Read-only attribute on the repo directory.
  • Run the shell as a normal user with write access to the folder.
  • Check for locked files by security software; exclude the repo if needed.

Quick reference table

Pitfalls to avoid

• Using chmod 777: overly permissive and risky; prefer 2775/664 with correct group.
• Fixing only .git/objects but ignoring .git/objects/pack and .git/index.lock.
• Running mixed Git operations as different users (root vs regular).
• Deleting lock files while another Git process is active.
• Recursing permission changes over the entire working tree unnecessarily; limit to .git when possible.

Performance notes

• Recursive chown/chmod on very large repos can be slow. Target the .git directory to minimize work.
• Network filesystems add latency and may serialize metadata updates; Git operations (especially fetching/packing) can be much slower. Prefer local storage for active clones.
• After fixing permissions, a quick git gc may repack objects for better performance:

git gc --prune=now --aggressive

Use aggressive with care on very large repos; it is CPU-intensive.

Preventing recurrence

• Avoid sudo inside working copies; if needed, isolate roots-only scripts outside the repo.
• Standardize umask (002) for users collaborating via a shared group.
• Initialize shared/bare repos with core.sharedRepository set appropriately.
• In CI/CD, ensure the runner user consistently owns the workspace.

Tiny FAQ

• Why did this start after I used sudo?

  • sudo created files owned by root in .git, blocking your user later. Fix with chown and stop using sudo for Git.

• Do I need to chmod 777?

  • No. Set correct ownership and group-writable bits instead (2775 for dirs, 664 for files).

• Is my repository corrupted?

  • Usually not. Once permissions are fixed, run git fsck to verify:

git fsck --full

• How do I handle a central bare repo for a team?

  • Ensure group ownership, setgid on directories, and core.sharedRepository group or 0660; use a shared service account.

• Does SELinux block Git writes?

  • It can if contexts are wrong. Use restorecon to restore correct labels or adjust policy for your service user.