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

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

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:

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:

# Succeeds only if you can write here
mkdir _writetest && rmdir _writetest && echo "writable" || echo "not writable"

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

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

Or give an explicit target path inside your home directory:

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

A dedicated projects directory keeps things tidy:

mkdir -p ~/projects
cd ~/projects
git clone https://github.com/username/repo.git

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:

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

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:

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

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.

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

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

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

sudo mount -o remount,rw /mountpoint

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

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:

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

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.