Git permission denied on Linux: 5 ways to fix access rights

What the EACCES Error Means

The permission denied error (or EACCES on Linux) occurs when a Git process lacks sufficient operating system permissions to read, write, or perform an operation on a file or directory. Typical Git messages:

fatal: could not create work tree dir 'project' : Permission denied
error: unable to create file (Permission denied)

This error blocks all Git operations: cloning, commits, branch creation, status checks. The symptom is always the same—Git reports insufficient permissions but does not specify which ones are missing.

Common Causes

1. Incorrect permissions on repository files/folders — your user lacks write (w) permission in the repository directory or on its files.
2. Files belong to another user — for example, you cloned the repository using sudo, so all files now belong to root.
3. Parent directories are inaccessible — you lack execute (x) permission on one of the parent folders in the repository path.
4. File is locked by another process — another Git instance or program is holding the file (rare but possible).
5. Attempting to write to a system/protected folder — for example, trying to create a repository in /usr/share without administrator rights.
6. Incorrect permissions on the .git directory — especially after crashes or repository moves.

Solution 1: Change Permissions (chmod)

The most common scenario is that your user lacks write permission in the repository folder.

1. Identify the problematic folder from the error text. Suppose it's /home/user/projects/myapp.
2. Check current permissions:

   ls -la /home/user/projects/myapp
   

   
   Example output:

   drwxr--r-- 2 root root 4096 Feb 16 10:00 myapp
   

   
   Here, the owner is root, and the group/others have no write permission.
3. Add permissions for your user (assuming your user is user):

   chmod -R u+rwx /home/user/projects/myapp
   

   
   The -R flag applies changes recursively to all nested files and folders.
   • u+rwx — grants the owner read, write, and execute permissions.
   • If you work within a group, you can add g+rwx.
4. Verify the result:

   ls -la /home/user/projects/myapp
   

   
   The owner should now have rwx.

⚠️ Important: Do not grant 777 permissions (full access to everyone) — this is a security risk. Always restrict permissions to only necessary users.

Solution 2: Change File Ownership (chown)

If repository files belong to another user (e.g., root), you need to change the owner to your current user.

1. Check current ownership:

   ls -la /path/to/repository
   

2. Change ownership recursively:

   sudo chown -R $USER:$USER /path/to/repository
   

   • $USER — automatically inserts your username.
   • :$USER — similarly for the group.
   • To specify explicitly: sudo chown -R username:groupname /path.
3. Verify:

   ls -la /path/to/repository
   

   
   Your user should now be the owner.

Solution 3: Check and Fix Permissions on Parent Directories

Git might lack access not to the repository itself, but to one of the parent folders in the path.

1. Check the full path:

   namei -l /full/path/to/repository
   

   
   Example output:

   f: /home/user/projects/myapp
    drwxr-xr-x root root /
    drwxr-xr-x root root home
    drwxr-xr-x user user user
    drwxr-xr-x root root projects
    drwxr--r-- root root myapp
   

   
   Here, the projects folder is owned by root and group/others lack execute (x) permission. This blocks access.
2. Fix permissions on the problematic directory (in the example — projects):

   sudo chmod 755 /home/user/projects
   

   
   Or, if ownership should be changed:

   sudo chown user:user /home/user/projects
   

3. Repeat for all levels where permissions are incorrect.

Solution 4: Work in the Correct Directory

Sometimes the error occurs because of attempting to create a repository in a system folder requiring root privileges.

1. Avoid working in /usr, /opt, /var and similar unless necessary.
2. Use your home directory (~/) or folders with write permissions:

   cd ~/projects
   git clone <url>
   

3. If the repository already exists in a protected folder, move it:

   sudo mv /usr/local/repo ~/repo
   sudo chown -R $USER:$USER ~/repo
   

Solution 5: Using sudo (with Caution)

If the repository must reside in a system folder and requires root permissions, use sudo for Git operations. This is not recommended for daily work, as it will create file ownership issues.

1. Run Git commands with sudo:

   sudo git commit -m "message"
   sudo git push origin main
   

2. Afterwards, fix the ownership to avoid dependency on sudo:

   sudo chown -R $USER:$USER /path/to/repository
   

3. In the future, work without sudo.

⚠️ Important: Regularly using sudo with Git is dangerous — you might accidentally modify system files. It's better to configure permissions correctly (Solutions 1-3).

Solution 6: Configuring Group Permissions for Collaboration

If multiple users work with the same repository (e.g., on a server), set up group permissions.

1. Create a shared group (if it doesn't exist):

   sudo groupadd devteam
   sudo usermod -aG devteam user1
   sudo usermod -aG devteam user2
   

2. Set the group for the repository:

   sudo chgrp -R devteam /path/to/repository
   

3. Grant the group read and write permissions:

   sudo chmod -R g+rwX /path/to/repository
   

4. Set the setgid bit on folders so new files inherit the group:

   sudo find /path/to/repository -type d -exec chmod g+s {} \;
   

5. Verify:

   ls -la /path/to/repository
   

   Folders should show drwxrwsr-x (note the s in the group permissions).

Prevention

To avoid the permission denied error in the future:

1. Always clone repositories into folders where you have permissions (home directory, /tmp, /var/tmp).
2. Never use sudo git clone — this creates ownership problems.
3. Regularly check permissions on important repositories:

   ls -la ~/projects/
   

4. When collaborating, configure group permissions (Solution 6) immediately after creating the repository.
5. Avoid moving repositories between different users without changing ownership (chown).
6. Use .gitignore to exclude system files (e.g., IDE configs) that might have unusual permissions.
7. Update Git — newer versions have improved permission handling.

If the problem occurs repeatedly, check whether background processes (e.g., antivirus or version control systems) might be locking files. Use lsof | grep <file> to find processes holding the file.