Quick Fix (TL;DR)
If you need a fix right now, run these three commands inside your repository root to reset permissions and force Git to play nice with your team:
# 1. Change group ownership to your team's group (e.g., 'developers')
sudo chown -R :developers .git
# 2. Grant read/write/traversal permissions to the group
sudo chmod -R g+rwX .git
# 3. Force Git to respect group permissions for all future objects
git config core.sharedRepository group
What’s Actually Happening?
It is a classic Linux permission clash. This usually happens on staging servers or shared workstations where 3 or 4 developers deploy code via SSH using their own accounts.
The conflict starts with the default umask. When Alice runs a git pull, Git creates new objects in the .git/objects folder. By default, Alice owns these files, and they are often read-only for everyone else. When Bob tries to commit a change five minutes later, Git tries to modify those same directories. Bob hits a wall because he doesn't have write access to Alice’s files.
The Permanent Solutions
1. Repair Existing File Ownership
First, you have to clean up the current mess. You need to ensure every user in your shared group can actually touch the repository database. Start by identifying your shared group name.
# See which groups you belong to
groups
# Recursively update the group of the .git folder
sudo chown -R :developers .git
# Apply 'rwX' so the group can read, write, and enter directories
sudo chmod -R g+rwX .git
2. The "Magic Bullet": Git Shared Repository Mode
Fixing permissions once is just a temporary bandage. The next time someone pushes code, Git will create new files with restrictive 0644 permissions again. You need to make the repository "shared-aware."
git config core.sharedRepository group
This config changes Git's behavior. Instead of using the user's default mask, it forces new files to be group-writable (typically 0664 or 0775). If you are on a completely open internal server, you could use world instead of group, though that is rarely the safest bet.
3. Double-Check Group Membership
The fix fails if your users aren't actually in the group you just assigned. Adding a user to the developers group is a quick one-liner:
sudo usermod -a -G developers username
Remember: group changes aren't instant. The user must log out and back in for the system to recognize their new powers.
How to Verify the Fix
Don't just take my word for it. Switch to a different user account and try to trigger a repository-wide update. A garbage collection task is the perfect test because it touches almost every object.
# Inspect the permissions of the objects directory
ls -la .git/objects
# Run a manual garbage collection
git gc
If git gc finishes without throwing an "insufficient permission" error, you have successfully tamed the repository.
Pro-Tips for Prevention
Linux permissions can be a headache, especially when you start calculating octal values like 775 or 664. If you're setting up a complex environment, use a Unix Permissions Calculator to visualize exactly who gets access. It prevents you from accidentally opening a security hole while trying to fix a workflow bottleneck.
The Sticky Bit Solution
For a "set it and forget it" approach, use the setgid bit. This ensures that any new file created inside .git/objects automatically inherits the developers group, no matter who creates it:
find .git/objects -type d -exec chmod g+s {} +