Git 'fatal: Unable to write new index file'

I've seen many of the other threads about this and they don't help.

I have a very simple repo - two JavaScript files. I have 100+ GB on Macbook. When I try to move the files into a subdirectory and stage locally the changes I get ...

>fatal: Unable to write new index file

This happens whether I do all actions in terminal or if I use a GUI like SourceTree. Additionally, one of the files becomes locked and I cannot delete the working directory until I log off and back in.

Why is this happening? Is the lock preventing something from staging? If so, what/how do I unlock the problem file on OS X?? The remote repo is Google Code, if that makes a difference, though I am not pushing to the remote yet. Everything is local.

In my case, the disk ran out of space, so I had to delete files from the hard drive to make space.

I've been having this same problem for the last few days. Basically, without my knowledge the entire repo had been moved to a new filesystem, when I tried to run git status, it was suddenly reporting that every file in the repo had been udpated.

Possible solutions

So, after much google scouring, I tried the following:

• changing .git permssions (same issue)
• changing .git/index permissions (same issue)
• git add-ing all the changes to commit (same issue)
• git rm-ing deleted files, since they were reporting file name too long errors (same issue)
• git reset (soft|Head|Hard) (same issue)
• git clean (same issue)
• turning off windows defender (same issue)
• updating git (same issue)
• different git clients (i use gitbash) (same issue)
• drinking 2 coffees instead of 1 (same issue)

tl:dr - dirty solution

The only thing that managed to solve the issue was to copy the index file, delete the original and rename the copy.

I know its not really a 'solution' but now its magically working ><, with all files / branches intact. If anyone knows why this might have work, do tell.

In my case, pausing dropbox sync solved the issue

I had the same issue on a Mac. It seems to be caused by filesystem ACLs. Try chmod -RN /path/to/repo to clear the ACLs. After doing this I was able to commit changes. Using the trick to copy the index file, delete the original and move the copy back achieved the same result.

If you have your github setup in some sort of online syncing service, such as google drive or dropbox, try disabling the syncing as the syncing service tries to read/write to the file as github tries to do the same, leading to github not working correctly.

Closing Visual Studio Code (that in my case has an auto-uploader background job running on file-save) solved the issue for me.

Credit for the solution: my friend and colleague Arnel.

In my case, the solution was only adding permission to the new user.

When I installed new OS, moved my repos around and it was showing this exact error I selected the root folder and then added authenticated the user to check all

It happened to me that the file .git/index was in use by another process (my local development web server). I shut down the process and then it worked.

This worked for me:

rm -f ./.git/index.lock

The error message fatal: Unable to write new index file means that we could not write the new content to the git index file .git\index (See here for more information about git index). After reviewing all the answers to this question, I summarize the following root causes:

• The size of new content exceeds the disk available capacity. (Solution: Clean the disk spaces)
• Users do not have access right to this file. (Solution: Grant the permission)
• Users have permission but .git\index is locked by other users or processes. (Solution: Unlock the file)

The link Find out which process is locking a file or folder in Windows specifies the following approach to find out the process which is locking a specific file:

>SysInternals Process Explorer - Go to Find > Find Handle or DLL. In the "Handle or DLL substring:" text box, type the path to the file (e.g. "C:\path\to\file.txt") and click "Search". All processes which have an open handle to that file should be listed.

Use the above approach to find which process locked .git\index and then stop the locking executable. This unlocks .git\index.

For example, Process Explorer Search shows that .git\index is locked by vmware-vmx.exe. Suspending the VMWare Player virtual machine (which accessed the git repo via a shared folder) solved the issue.

I had ACL (somehow) attached to all files in the .git folder.

Check it with ls -le in the .git folder.

You can remove the ACL with chmod -N (for a folder/file) or chmod -RN (recursive)

I think some background backup solutions like Google Backup and Sync block access to the index file. I closed the application and Sourcetree had no issues at all. Seems that Dropbox does the same (@tonymayoral).

In my case it was a concurrent running EGit. After restarting eclipse it works as usual.

If you're on a Windows box, make sure the program you're using, whether it's Source Tree or a git terminal, is running as administrator. I was getting the same exact error message. You can either right click on the program to run as administrator or change its properties to always run as administrator.

IF YOU GET THIS DURING A REBASE:

This is most likely caused by some software locking the index file of your repo, such as backup software, anti-viruses, IDEs or other git clients.

In most cases the lock is just for a brief moment and so it just happens out of bad-timing and bad luck.

However, git rebase --continue will complain about the next command being an empty commit:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

To fix this, just run git reset and try git rebase --continue again.

Not having enough space is an issue. Cleanup and try again

I had the same problem. I restarted my computer and the issue was resolved.

did you try 'git add .' . will it all the changes? (you can remove unnecessary added files by git reset HEAD )

In my case it was a nodemon instance watching filesystem for changes.

I had/have this problem too. In my case, none of the explanations applied:

• enough disk room
• I had sufficient privileges, I can write the index file, I can rename it, I can create it, the workaround did nothing
• restarting windows didn't work
• index not locked by processes

Until I found out that once I accessed the windows folder via another (linux) computer, git worked without complaints. It must have something to do with the git version I use from my normal debian buster computer: git 1.2.20 is giving me the 'unable to write new index' error, whereas from a ubuntu fuzzy virtualbox (git 1.2.2) adds the file without problems.

For some reason, doing git add from wsl terminal was working fine. But the sublime merge would always give me this error. Turned out VS code was preventing it somehow. Closing VS code made it work. Someone also solved this problem same way - https://stackoverflow.com/a/47871586/6236710

i ran the commit again and it worked....

    sbe:/var/xxxxx/rmm/sprcg2/app3536847/sas % git commit -m "My summary"
[master a2257ec] My summary
 9 files changed, 2747 insertions(+), 7047 deletions(-)
 rename ish_extracts/prog/{t.sas => query.sas} (55%)
 rewrite ish_extracts/prog/t.sas (98%)

Issue: When I was checking out some modified files in git, got this error. I was having two users ABC and XYZ. files are having uid:gid of ABC but it doesn't have git access and trying to checkout the files with same.

The solution I have tried: XYZ is having git access, tried checking out files with sudo and it worked..!!

Here is what worked for me:

Context:

1. Building a project on a server

2. git status returns a HEAD detached at <commit-SHA>

3. What ever operation I did locally, I had this error. More specifically:

• git checkout
• git reset HEAD --hard

Solution

1. Simply removed file <work-dir>/.git/index.
2. A git status would indicate that all files in the projet are not tracked (no surprise here).
3. git reset HEAD --hard
4. Back to HEAD detached at <commit-SHA> when doing a git status, but then you should be able to
5. git checkout <some-branch>

and you're back on track!

!! IMPORTANT !!

This works only because I am "merly" building. No precious modification has been performed on the code. If you are actually in "dev-time", then I would recommand to save your work first or go for another method.

Hope it will help :).

I had this problem using GitExtensions on windows. Fixed by granting full permission for the current user (me) on the folder that contained the repo.

Another time, I even though I was getting the error from Git Extensions, I was able to commit the same files from Visual Studio 2015.

Another time I had to delete the "index" file from the .git folder

My case is a bit interesting:

I run git log to check a certain commit, then I didn't quit it properly, I press ctrl+c to exit it.

Then the index seems been locked. So I run git log again, then press Q to quit it.

Problem fixed. :)

I faced the same issue after installing Anaconda. I tried all solutions like permission and disk-free. So, I simply removed the repo and clone it again from the remote. It solved the issue.

running with sudo worked for me.

for example: sudo git add -r