Introduction

The cannot stat ... Permission denied error during git rebase usually means Git tried to read, move, or replace a file and the operating system blocked access. The underlying cause is rarely Git itself; it is usually a permission problem, a locked file, or a filesystem that is not behaving like a normal local working tree.

What cannot stat means during rebase

During a rebase, Git repeatedly checks out files, applies patches, updates the index, and rewrites commit history. To do that, it needs reliable access to every path involved in the operation.

On Unix-like systems, "stat" refers to reading file metadata such as permissions, ownership, and timestamps. If that metadata cannot be read, or if Git cannot replace the file afterward, the rebase stops because continuing would risk corrupting the working tree.

A typical failure looks like this:

git rebase main
# error: cannot stat 'src/config.json': Permission denied

That message tells you which file triggered the problem. Start there instead of trying random Git commands.

The most common causes

The first category is ownership and permission mismatch. This often happens if some files were created with sudo, copied from another user account, or checked out on a shared mount. Git runs as your current user, so it cannot manage files it does not have permission to read and write.

The second category is a file lock. Editors, IDEs, antivirus tools, sync clients, and preview applications sometimes hold an exclusive lock on a file. Windows users see this more often, but it can happen elsewhere too.

The third category is filesystem behavior. Rebasing inside a network share, container mount, WSL boundary, or cloud-synced folder can expose incomplete permission support or delayed file updates.

Diagnose the failing path directly

Start by checking repository state and then inspect the file that Git named in the error:

git status
ls -l src/config.json
id

If ownership looks wrong, compare it with surrounding files in the same directory. A single outlier is a strong signal that the file was created by another user or process.

On macOS or Linux, you can also ask which process currently has the file open:

lsof src/config.json

If the file is open in an editor, archive tool, preview app, or synchronization daemon, close that program and retry the rebase.

Fix permissions before retrying

If the problem is ownership, correct ownership first. If the file is yours but lacks write permission, fix the mode. These commands are common examples:

chown "$USER" src/config.json
chmod u+rw src/config.json

For a whole repository affected by a bad copy or sudo command, you may need to repair the tree recursively:

chown -R "$USER" /path/to/repo
chmod -R u+rw /path/to/repo

Use recursive permission changes carefully. They are appropriate when the repository is entirely yours, but not on shared directories you do not control.

Resume the interrupted rebase

Once the filesystem issue is fixed, continue the rebase instead of starting from scratch:

git rebase --continue

If the rebase stopped in a messy state because the file is still blocked, abort only after you have captured any important local edits:

git diff
git rebase --abort

Aborting is not the first fix. It just returns the repository to its pre-rebase state so you can solve the OS-level problem and try again cleanly.

Example troubleshooting flow

Here is a practical sequence that avoids destructive steps:

1git status
2ls -l path/to/file
3lsof path/to/file
4chmod u+rw path/to/file
5git rebase --continue

If lsof shows an IDE helper or sync tool holding the file, close that application first. If ls -l shows the file belongs to root, fix ownership and rerun git rebase --continue.

Common Pitfalls

One common mistake is retrying the same rebase command repeatedly without inspecting the named file. Git is reporting the exact path that failed, so that file is where you should focus.

Another mistake is using sudo git rebase. That can appear to solve the problem temporarily, but it usually creates more root-owned files and makes the repository harder to fix later.

People also overlook background tools. Dropbox-style sync clients, antivirus scanners, and editor watchers can lock files intermittently. If the error only appears sometimes, a background process is a likely cause.

Finally, do not jump to git clean, hard resets, or recloning unless basic permission checks fail. This is usually a workspace access issue, not a Git history issue.

Summary

• 'cannot stat ... Permission denied usually points to an OS-level access problem, not a broken rebase algorithm.'
• Check the exact file named in the error with ls -l, git status, and, if available, lsof.
• Fix ownership or write permissions before retrying the rebase.
• Close editors, sync tools, or antivirus processes that may be locking the file.
• Prefer git rebase --continue after the fix; avoid sudo git and destructive cleanup unless absolutely necessary.