Git fatal Unable to write new index file

Question

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

User · Answer

In my case  pausing dropbox sync solved the issue

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

did you try  git add      will it all the changes   you can remove unnecessary added files by git reset HEAD

User · Answer

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

User · Answer

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

User · Answer

Here is what worked for me   Context    Building a project on a server git status returns a HEAD detached at  lt commit-SHA gt  What ever operation I did locally  I had this error  More specifically    git checkout  git reset HEAD --hard    Solution   Simply removed file  lt work-dir gt   git index   A git status would indicate that all files in the projet are not tracked  no surprise here   git reset HEAD --hard Back to HEAD detached at  lt commit-SHA gt  when doing a git status  but then you should be able to git checkout  lt some-branch gt    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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

This worked for me    rm -f    git index lock

User · Answer

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

User · Answer

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   lt   with all files   branches intact  If anyone knows why this might have work  do tell

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

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

User · Answer

Not having enough space is an issue  Cleanup and try again

[git] Git 'fatal: Unable to write new index file'

Examples related to git

Examples related to locking