How to fix fatal: unable to access '/path/to/repo/.git/config': Permission denied in Git

First, examine who owns the .git directory and its contents:

ls -la .git/

Look at the third and fourth columns which show the owner and group. Example output:

total 52
drwxr-xr-x  8 root   root   4096 Jan 15 10:30 .
drwxr-xr-x  5 jonas  jonas  4096 Jan 15 10:30 ..
-rw-r--r--  1 root   root    307 Jan 15 10:30 config
-rw-r--r--  1 root   root     73 Jan 15 10:30 description
...

If you see root or another user instead of your username, that's the problem.

Also check your current user:

whoami
id

The standard fix is to change ownership of the entire .git directory to your current user:

sudo chown -R $(whoami):$(whoami) .git/

This command:
- Uses sudo to run with root privileges (required to change ownership from root)
- chown -R recursively changes ownership
- $(whoami) substitutes your current username

Alternatively, you can specify user and group explicitly:

sudo chown -R $USER:$USER .git/

Or change ownership of the entire repository including working directory:

sudo chown -R $(whoami):$(whoami) .

After changing ownership, verify the permissions are correct:

ls -la .git/

You should now see your username in the owner column:

-rw-r--r--  1 jonas  jonas    307 Jan 15 10:30 config

Test that Git commands work:

git status
git log --oneline -5
git remote -v

If these commands work without errors, the issue is resolved.

If changing ownership doesn't resolve the issue, security modules like SELinux or AppArmor might be blocking access.

For SELinux (RHEL, CentOS, Fedora):

# Check if SELinux is enforcing
getenforce

# Check for recent denials
sudo ausearch -m avc -ts recent

# Temporarily set to permissive to test
sudo setenforce 0

If the error goes away in permissive mode, you need to fix the SELinux context:

# Restore default SELinux contexts
restorecon -Rv .git/

For AppArmor (Ubuntu, Debian):

# Check AppArmor status
sudo aa-status

# Check system logs for denials
sudo dmesg | grep apparmor

If you own the files but still get permission denied, the file permissions themselves may be wrong:

# Check current permissions
ls -la .git/config

# Fix: make config readable and writable by owner
chmod 644 .git/config

# Fix all files in .git recursively
find .git -type f -exec chmod 644 {} \;
find .git -type d -exec chmod 755 {} \;

The .git/config file should have at least read permissions (mode 644 or similar).

If the repository is on a network filesystem, ownership may not map correctly between systems.

For NFS:

Check that UID/GID mapping is consistent between the NFS server and client. On the server's exports file:

/export/repos 192.168.1.0/24(rw,sync,no_subtree_check,all_squash,anonuid=1000,anongid=1000)

For CIFS/SMB (Samba):

Mount with explicit UID and GID:

sudo mount -t cifs //server/share /mnt/repo -o username=user,uid=$(id -u),gid=$(id -g)

Or in /etc/fstab:

//server/share /mnt/repo cifs username=user,uid=1000,gid=1000 0 0