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

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 157 views

This error occurs when Git cannot read or write to the .git/config file due to file system permission restrictions. The fix typically involves correcting the ownership of the .git directory to match your current user.

Quick fix

Fixes EACCES

ls -la .git/
  1. Check current ownership of the .git directory
  2. Change ownership of the .git directory
  3. Verify the fix and test Git commands
  4. Check for SELinux or AppArmor issues
git — error
ls -la .git/
fatal: unable to access '/path/to/repo/.git/config': Permission denied

What this error means

When you run a Git command, Git needs to access the `.git/config` file to read repository-level settings such as remote URLs, branch tracking information, and user configurations. This fatal error appears when your current user lacks the necessary read or write permissions to access this configuration file. The error message `fatal: unable to access '/path/to/repo/.git/config': Permission denied` indicates that the Linux kernel denied your request to open the file. This is a file system permission issue, not a Git bug. The most common scenario is when the `.git` directory (or files within it) are owned by a different user than the one running the Git command. This often happens when: 1. The repository was cloned or initialized with `sudo` 2. Files were created by a different user or process (such as a Docker container running as root) 3. The repository was copied or extracted from an archive with preserved permissions from another system 4. A backup/restore operation did not preserve correct ownership

Typical symptoms

  • Any git command fails with 'Permission denied' when accessing .git/config
  • git status, git pull, git push, git log all fail with the same error
  • Commands work when run with sudo but fail as a regular user
  • The error appears immediately when entering the repository directory and running any git command
  • Other files in the repository are accessible, but git operations fail
  • Error occurs after cloning a repository with sudo
  • Error appears after running git operations inside a Docker container

Common causes

  1. Repository was cloned or initialized using sudo, creating root-owned files (most common)
  2. Git operations were performed inside a Docker container running as root with a mounted volume
  3. Repository was copied or moved by a different user (e.g., root)
  4. Backup restoration did not preserve correct ownership
  5. Filesystem permissions were changed by an external process or script
  6. Repository is on a mounted filesystem (NFS, CIFS) with incorrect ownership mapping
  7. Multiple users accessing the same repository with conflicting permissions
  8. SELinux or AppArmor security policies are blocking access

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

1Check current ownership of the .git directory

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

bash
ls -la .git/

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

bash
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:

bash
whoami
id
2Change ownership of the .git directory

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

bash
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:

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

Or change ownership of the entire repository including working directory:

bash
sudo chown -R $(whoami):$(whoami) .
3Verify the fix and test Git commands

After changing ownership, verify the permissions are correct:

bash
ls -la .git/

You should now see your username in the owner column:

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

Test that Git commands work:

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

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

4Check for SELinux or AppArmor issues

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

For SELinux (RHEL, CentOS, Fedora):

bash
# 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:

bash
# Restore default SELinux contexts
restorecon -Rv .git/

For AppArmor (Ubuntu, Debian):

bash
# Check AppArmor status
sudo aa-status

# Check system logs for denials
sudo dmesg | grep apparmor
5Fix permissions if ownership is correct

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

bash
# 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).

6Handle mounted filesystems (NFS, CIFS)

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:

bash
/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:

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

Or in /etc/fstab:

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

Advanced notes

### Preventing This Issue in the Future

Never use sudo with git for user repositories:

bash
# BAD - creates root-owned files
sudo git clone https://github.com/user/repo.git

# GOOD - clone as your user
git clone https://github.com/user/repo.git

If you need to clone to a location that requires elevated privileges, create the directory first with correct ownership:

bash
sudo mkdir /opt/myproject
sudo chown $(whoami):$(whoami) /opt/myproject
git clone https://github.com/user/repo.git /opt/myproject

### Docker Volume Permissions

When using Git inside Docker containers with mounted volumes, the container often runs as root. Solutions:

Run container as your user:

bash
docker run --user $(id -u):$(id -g) -v $(pwd):/repo -w /repo git-image git pull

In docker-compose.yml:

yaml
services:
  app:
    image: myimage
    user: "${UID}:${GID}"
    volumes:
      - .:/app

Run with: UID=$(id -u) GID=$(id -g) docker-compose up

### WSL (Windows Subsystem for Linux)

On WSL1, Windows filesystem mounts (/mnt/c/) have known permission issues. Upgrade to WSL2:

powershell
wsl --set-version Ubuntu 2

Or clone repositories to the Linux filesystem (/home/user/) instead of Windows mounts.

### Git Safe Directory Feature

Git 2.35.2+ added a security feature that rejects repositories owned by different users. You may also see:

bash
fatal: detected dubious ownership in repository

This is a related but different error. Fix with:

bash
git config --global --add safe.directory /path/to/repo

However, fixing ownership (as described above) is the preferred solution.

### Checking Immutable or Append-Only Attributes

On some systems, files may have special attributes that prevent modification:

bash
# Check for immutable attribute
lsattr .git/config

# Remove immutable attribute if present
sudo chattr -i .git/config

### ACL (Access Control Lists)

If your filesystem uses ACLs, standard Unix permissions may be overridden:

bash
# Check ACLs
getfacl .git/config

# Remove all ACLs and use standard permissions
setfacl -b .git/config

Frequently asked questions

What does "EACCES" mean?
git/config file to read repository-level settings such as remote URLs, branch tracking information, and user configurations. This fatal error appears when your current user lacks the necessary read or write permissions to access this configuration file. git/config': Permission denied indicates that the Linux kernel denied your request to open the file.
How do I fix "EACCES"?
This error occurs when Git cannot read or write to the .git/config file due to file system permission restrictions. The fix typically involves correcting the ownership of the .git directory to match your current user.
What causes "EACCES"?
Repository was cloned or initialized using sudo, creating root-owned files (most common) Git operations were performed inside a Docker container running as root with a mounted volume Repository was copied or moved by a different user (e.g., root)
Is the "EACCES" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading