How to fix fatal: could not create work tree dir 'repo': Permission denied in Git

GitBEGINNERMEDIUMUpdated Sep 23, 2026· 653 views

Git's "could not create work tree dir: Permission denied" means it cannot create the clone target folder because your user lacks write access to the parent directory. Fix it by cloning to a directory you own.

Quick fix

Fixes EACCES

pwd
ls -la .
  1. Check your current directory and its permissions
  2. Clone into a directory you own
  3. Create the target directory with proper ownership
  4. Fix ownership of a specific directory you accidentally root-owned
git — error
pwd
ls -la .
fatal: could not create work tree dir 'repo': Permission denied

What this error means

When you run `git clone`, Git tries to create a new directory (the "work tree") at the path you specified or in your current working directory. This fatal error appears when your user account does not have write permission on the parent directory where Git is trying to create the repository folder. The message names exactly which directory Git tried to create (in quotes) and reports that the operating system denied the operation. This is a filesystem-level permission error reported by the OS, not a Git-specific bug, so the same failure would occur with a plain `mkdir` in that location. Common scenarios where this occurs: 1. **Cloning into protected system directories** - Attempting to clone into `/`, `/opt`, `/var`, or other root-owned locations. 2. **Incorrect current directory** - Being in a directory you do not have write access to. 3. **Shared servers** - Working on multi-user systems where your home or working directory is misconfigured. 4. **Network-mounted filesystems** - NFS, CIFS, or other mounts with restrictive permissions. 5. **Read-only or full filesystems** - A drive mounted read-only, or a disk-full condition surfacing as a write failure.

Typical symptoms

  • git clone fails immediately with a 'could not create work tree dir' message
  • The error gives 'Permission denied' as the reason
  • The same clone command works in your home directory but fails in another location
  • Clone operations fail on shared servers or network drives
  • The error occurs with any repository URL (the problem is local, not remote)
  • Other file operations like mkdir or touch also fail in the same directory

Common causes

  1. Attempting to clone into a directory owned by root or another user (most common)
  2. The current working directory is a protected system location such as / or /opt
  3. Parent directory permissions do not allow your user to create subdirectories
  4. A network filesystem (NFS, CIFS) is mounted with restrictive permissions
  5. The disk is full, causing write operations to fail (sometimes with a misleading error)
  6. Home or project directory ownership was changed, often after running an earlier command with sudo
  7. The filesystem is mounted read-only (USB drive, disk issues, or intentionally mounted ro)
  8. SELinux or AppArmor policy blocking the write operation

How to fix "fatal: could not create work tree dir 'repo': Permission denied"

1Check your current directory and its permissions

First, confirm where you are cloning and whether you can write there:

bash
pwd
ls -la .

Look at the owner and permission bits of . (the current directory). If it is owned by root or another user and others have no write bit, that is your problem:

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

Here r-x for "other" (the last three characters) means you can read and execute but not write, so you cannot create a new subdirectory. A quick confirmation:

bash
# Succeeds only if you can write here
mkdir _writetest && rmdir _writetest && echo "writable" || echo "not writable"
2Clone into a directory you own

The simplest and safest fix is to clone somewhere your user owns, such as your home directory:

bash
cd ~
git clone https://github.com/username/repo.git

Or give an explicit target path inside your home directory:

bash
git clone https://github.com/username/repo.git ~/projects/repo

A dedicated projects directory keeps things tidy:

bash
mkdir -p ~/projects
cd ~/projects
git clone https://github.com/username/repo.git
3Create the target directory with proper ownership

If you genuinely need the repo outside your home directory (for example under /opt), create the directory once with sudo and hand ownership to your user, then clone normally:

bash
# Create the parent directory with sudo
sudo mkdir -p /opt/projects

# Give ownership to your user
sudo chown $USER:$USER /opt/projects

# Now clone runs as your normal user, no sudo needed
git clone https://github.com/username/repo.git /opt/projects/repo

Important: Do not run git clone itself with sudo. That makes the entire repository owned by root and forces every later Git command to need sudo, which leads to more permission problems.

4Fix ownership of a specific directory you accidentally root-owned

Sometimes a directory you own was previously created or written by root (for example after an earlier sudo git clone or sudo npm install), leaving root-owned files inside. Fix only the affected directory, not your whole home folder.

First, inspect what is actually root-owned so you change the minimum necessary:

bash
# List items in the directory and their owners
ls -la ~/projects

# Find files NOT owned by you under a specific path
find ~/projects -not -user "$USER" -print

Then correct ownership for just that path:

bash
sudo chown -R "$USER:$USER" ~/projects/repo

Avoid `sudo chown -R $USER ~` (the entire home directory). A recursive chown of all of ~ can clobber the intended ownership of files that are supposed to differ, such as ~/.gnupg, ~/.ssh socket/agent files, snap or cache directories owned by services, and mounted subdirectories. Target the exact subdirectory instead.

5Rule out a full or read-only filesystem

A "Permission denied" message can occasionally mask a disk-full or read-only condition:

bash
# Check available space on the filesystem holding the current directory
df -h .

# See how that filesystem is mounted (look for 'ro' vs 'rw')
mount | grep "$(df --output=source . | tail -1)"

If the disk is full, free space safely (review before deleting):

bash
# Find large directories to investigate
du -h -d1 / 2>/dev/null | sort -h | tail -20

# Clear package manager cache if appropriate for your distro
sudo apt clean        # Debian/Ubuntu
sudo dnf clean all    # Fedora/RHEL (or: sudo yum clean all)

If the filesystem is genuinely read-only and that is unintended, you can remount it read-write (understand why it was read-only first, as that may indicate disk errors):

bash
sudo mount -o remount,rw /mountpoint
6Handle network filesystem (NFS/CIFS) permissions

On NFS or CIFS/SMB mounts, the server's export options and your mapped user/group control whether you can write:

bash
mount | grep -E 'nfs|cifs'

For NFS, the export must be read-write and your UID must be permitted by the server; remounting locally cannot grant access the server denies:

bash
# Remount read-write (only works if the export allows it)
sudo mount -o remount,rw /nfs/share

For CIFS/SMB, mount with your UID/GID so created files belong to you:

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

On a managed system, contact your administrator if you cannot change export or mount options.

Advanced notes

### Do not run sudo git clone

You *can* run sudo git clone, but avoid it. It makes the whole repository owned by root, forces every later Git command to use sudo, and runs Git (and any clone-time hooks) as root, which is a security risk. Prefer creating the target directory and chowning it to your user first (see step 3). If a repo was already cloned as root, fix only that repo's ownership: sudo chown -R "$USER:$USER" /path/to/repo.

### macOS: System Integrity Protection

On macOS, system locations such as /, /System, and /usr (except /usr/local) are protected by System Integrity Protection, so writes there fail even with sudo. Clone into your home directory, /usr/local, or /opt instead:

bash
git clone https://github.com/user/repo.git /usr/local/src/myrepo
git clone https://github.com/user/repo.git ~/Developer/myrepo

### Docker volume permissions

When cloning into Docker volumes or bind mounts, the container's user often does not match the host UID, causing permission denied. Run the container with your UID/GID:

bash
docker run --user $(id -u):$(id -g) -v "$(pwd)":/workspace myimage \
  git clone https://github.com/user/repo.git /workspace/repo

If the mount is already root-owned, fix ownership of the mounted path (not the whole container filesystem) before cloning.

### SELinux

On RHEL/CentOS/Fedora with SELinux enforcing, a write can be blocked even when standard permissions look correct. Check for denials first:

bash
sudo ausearch -m avc -ts recent

To confirm SELinux is the cause, you can briefly set it permissive for testing, then restore enforcing immediately afterward:

bash
sudo setenforce 0   # temporary test only
# re-run your git clone
sudo setenforce 1   # restore enforcing right away

If permissive mode fixes it, do not leave SELinux disabled. Generate and install a targeted policy, or relabel the directory with the correct context (often the real fix):

bash
sudo ausearch -m avc -ts recent | audit2allow -M mypolicy
sudo semodule -i mypolicy.pp

# Often the cleaner fix is restoring the expected context:
sudo restorecon -Rv /path/to/target

### Windows / WSL

Cloning onto the Windows filesystem from WSL (paths under /mnt/c) can hit permission and metadata issues. Prefer WSL's native filesystem:

bash
cd ~
git clone https://github.com/user/repo.git

If you must use /mnt/c, enable metadata in /etc/wsl.conf and restart WSL:

ini
[automount]
options = "metadata,umask=22,fmask=11"

### A convenience alias

Git has no built-in "default clone directory" setting, but a shell alias makes a standard location easy:

bash
mkdir -p ~/repos
alias gcl='git -C ~/repos clone'

Frequently asked questions

What does "EACCES" mean?
When you run git clone, Git tries to create a new directory (the "work tree") at the path you specified or in your current working directory. This fatal error appears when your user account does not have write permission on the parent directory where Git is trying to create the repository folder. The message names exactly which directory Git tried to create (in quotes) and reports that the operating system denied the operation.
How do I fix "EACCES"?
Git's "could not create work tree dir: Permission denied" means it cannot create the clone target folder because your user lacks write access to the parent directory. Fix it by cloning to a directory you own.
What causes "EACCES"?
Attempting to clone into a directory owned by root or another user (most common) The current working directory is a protected system location such as / or /opt Parent directory permissions do not allow your user to create subdirectories
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