How to fix fatal: cannot mkdir: Permission denied in Git

GitBEGINNERMEDIUMUpdated Dec 6, 2025· 252 views

This error occurs when Git cannot create a directory due to insufficient filesystem permissions. The fix involves checking directory ownership, adjusting permissions, or initializing the repository in a location where you have write access.

Quick fix

Fixes EACCES

ls -la .
  1. Check current directory permissions
  2. Navigate to a directory where you have write access
  3. Change directory ownership (Linux/macOS)
  4. Adjust directory permissions
git — error
ls -la .
fatal: cannot mkdir: Permission denied

What this error means

When you run `git init`, Git attempts to create a `.git` directory (with subdirectories for objects, refs, hooks, etc.) in your specified location. If the operating system denies this directory creation, you get the "cannot mkdir: Permission denied" error. This error is entirely about filesystem permissions—Git itself has no special permission system. It relies on the underlying OS to grant or deny access to directories. The error means your current user account doesn't have write permission to the parent directory where you're trying to initialize the repository. Common scenarios include trying to create a repository in system directories (like `/var`, `/etc`, or `C:\Program Files`), directories owned by root or another user, or locations protected by security policies like SELinux or Windows UAC.

Typical symptoms

  • Running git init in a directory fails immediately with 'fatal: cannot mkdir'
  • The error occurs before any repository files are created
  • The same command works when run with sudo (Linux/macOS) or as Administrator (Windows)
  • Other file operations like touch or mkdir also fail in the same directory
  • CI/CD pipelines fail when trying to initialize Git repositories in restricted paths

Common causes

  1. The parent directory is owned by root or another user (most common on Linux/macOS)
  2. You're trying to initialize a repository in a system-protected location like /var or /etc
  3. On Windows, running Git Bash in a restricted location like C:\Program Files or the root of C:\
  4. Directory permissions don't include write access for your user (e.g., 755 owned by another user)
  5. SELinux or AppArmor is enforcing access controls that block directory creation
  6. Windows UAC is preventing modifications without administrator privileges
  7. ACL (Access Control List) settings explicitly deny write access to your user
  8. The filesystem is mounted as read-only or with restrictive options

How to fix "fatal: cannot mkdir: Permission denied"

1Check current directory permissions

First, verify who owns the directory and what permissions are set:

On Linux/macOS:

bash
ls -la .

Look at the output—the third and fourth columns show owner and group:

bash
drwxr-xr-x 2 root root 4096 Jan 15 10:00 .

If it shows root root and you're not root, that's your problem.

On Windows (Git Bash):

bash
pwd

If you're at / or /c/Program Files, navigate elsewhere:

bash
cd ~
2Navigate to a directory where you have write access

The simplest solution is to create your repository in your home directory or a subdirectory you own:

Linux/macOS:

bash
cd ~
mkdir -p projects/my-repo
cd projects/my-repo
git init

Windows (Git Bash):

bash
cd /c/Users/$USERNAME
mkdir -p projects/my-repo
cd projects/my-repo
git init

Windows (Command Prompt/PowerShell):

powershell
cd %USERPROFILE%
mkdir projects\my-repo
cd projects\my-repo
git init
3Change directory ownership (Linux/macOS)

If you need to use a specific directory and you have sudo access, change ownership:

bash
sudo chown -R $USER:$USER /path/to/directory

For example, to take ownership of a directory in /var:

bash
sudo chown -R $USER:$USER /var/www/my-project

Verify the change:

bash
ls -la /var/www/my-project

Now you should be able to run git init without sudo.

4Adjust directory permissions

If changing ownership isn't appropriate (shared directories), modify permissions instead:

Grant write access to your group:

bash
sudo chmod g+w /path/to/directory
sudo usermod -aG groupname $USER

Or set more permissive permissions (use cautiously):

bash
sudo chmod 775 /path/to/directory

After adding yourself to a group, log out and back in, or use:

bash
newgrp groupname
5Run as Administrator (Windows only)

If you must initialize a repository in a protected Windows location:

1. Right-click on Git Bash and select "Run as administrator"
2. Navigate to your target directory
3. Run git init

Better alternative: Use a directory under your user profile:

bash
cd /c/Users/YourUsername/Documents
mkdir my-repo && cd my-repo
git init

Avoid running Git as administrator unless absolutely necessary—it can create files owned by the Administrator account that your normal user can't modify later.

6Verify the repository was created

After successfully running git init, verify the repository:

bash
ls -la .git

You should see the Git directory structure:

bash
drwxr-xr-x  7 youruser youruser 4096 Jan 15 10:00 .
-rw-r--r--  1 youruser youruser   23 Jan 15 10:00 HEAD
drwxr-xr-x  2 youruser youruser 4096 Jan 15 10:00 branches
-rw-r--r--  1 youruser youruser   92 Jan 15 10:00 config
...

Also verify Git recognizes it:

bash
git status

Advanced notes

### SELinux Considerations (RHEL/CentOS/Fedora)

If you've fixed file permissions but still get "Permission denied," SELinux might be blocking access:

bash
# Check if SELinux is enforcing
getenforce

# Check for recent SELinux denials
sudo ausearch -m avc -ts recent | grep git

# Temporarily set to permissive to test
sudo setenforce 0
git init
sudo setenforce 1

If it works in permissive mode, you need to set the correct SELinux context:

bash
# Restore default SELinux context
sudo restorecon -Rv /path/to/directory

### ACL (Access Control Lists)

Some systems use ACLs for fine-grained permissions. Check with:

bash
getfacl /path/to/directory

If ACLs are blocking you, modify them:

bash
sudo setfacl -m u:$USER:rwx /path/to/directory

### Network/Mounted Filesystems

If the directory is on an NFS mount, CIFS/SMB share, or other network filesystem:
- Permissions might be controlled by the server, not local settings
- Root squashing on NFS can prevent even sudo from working
- Check mount options: mount | grep /path/to/mount

### umask Settings

Your umask affects default permissions for new files and directories:

bash
# Check current umask
umask

# Temporarily set more permissive umask
umask 002
git init

### Avoid sudo git init

Running sudo git init is generally a bad idea because:
1. The .git directory will be owned by root
2. Subsequent git add and git commit commands will fail without sudo
3. It creates a maintenance burden

Instead, fix the underlying permission issue or use a different directory.

### Docker/Container Environments

In containers, permission issues often stem from:
- UID/GID mismatches between container and host
- Volume mounts with incorrect permissions
- Non-root container users without write access

Solutions:

bash
# Run container with your user's UID
docker run -u $(id -u):$(id -g) -v $(pwd):/app image

# Or fix permissions on the mounted volume
docker run -v $(pwd):/app image chown -R node:node /app

Frequently asked questions

What does "EACCES" mean?
) in your specified location. If the operating system denies this directory creation, you get the "cannot mkdir: Permission denied" error. This error is entirely about filesystem permissions—Git itself has no special permission system.
How do I fix "EACCES"?
This error occurs when Git cannot create a directory due to insufficient filesystem permissions. The fix involves checking directory ownership, adjusting permissions, or initializing the repository in a location where you have write access.
What causes "EACCES"?
The parent directory is owned by root or another user (most common on Linux/macOS) You're trying to initialize a repository in a system-protected location like /var or /etc On Windows, running Git Bash in a restricted location like C:\Program Files or the root of C:\
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