Git 'fatal: Unable to write new index file'

E

30

207

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.

Exclamation answered 17/4, 2013 at 15:44 Comment(5)

Not sure is this should go to SuperUser instead? – Orchard 17/4, 2013 at 15:48

most probably a problem with access rights (the user running git doesnt have write permission to all of the repo) – Deserved 17/4, 2013 at 15:48

There's threads about this in SO and SU. I think question works equally well in either. Nevik, the permissions for the repo are 777, including the ./git folder. – Exclamation 17/4, 2013 at 15:51

When do you see this issue ? Is it when you do a "git mv" or "git add" ? – Tetrapody 12/3, 2014 at 4:54

You may have run out of disk spaceю. Use: df -h – Prindle 10/6, 2022 at 10:56

Y

350

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

Yaya answered 16/1, 2015 at 14:23 Comment(2)

full in source? or full in destination? (repo) – Valenciavalenciennes 21/12, 2021 at 17:35

Full in source, if I remember correctly. – Yaya 22/12, 2021 at 13:49

R

78

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.

Renny answered 12/3, 2014 at 4:9 Comment(9)

Found yet another cause: you may be out of disk space. – Oast 17/11, 2014 at 9:57

In my case, Google Drive was uploading (backing up) files and they were locked during the process. After it has done uploading, the commit worked. – Guntar 9/1, 2017 at 17:23

Thanks for the tip about Google Drive. I had the same issue, but with Dropbox. – Landis 19/2, 2017 at 9:42

Restart worked for me. Working on a half empty, 22 TB shared drive, so space wasn't an issue. – Server 18/4, 2017 at 14:20

Thanks @KristjanO. This was the issue I was having. My repo just happened to live in my My Documents directory and while I was offline I deleted a build directory to fix an issue with my IDE and google drive had apparently been silently waiting for a delete confirmation for a while (weeks??). I removed My Documents from syncing via preferences and was able to resume normal git operations. – Onfre 24/5, 2018 at 15:33

your "dirty solution" worked for me (returned to a previous index file, re-added and re-committed all changes since then) – Manslaughter 11/6, 2018 at 9:21

Dirty solution works when, say, SourceTree and PhpStorm are both displaying git logs at the same time – Arturo 22/10, 2018 at 23:10

Another possibility is Google Backup & Sync being in a bad state. Force-kill the process and try again. – Haycock 25/3, 2019 at 6:20

I was low on disk space, but still had 5GB, either way, freed up 2.5 GB, still getting the error. So renamed the index file to .bak as this is a new push to a remote repo so nothing would really be lost and now git add . works and doesnt throw that error - thanks! – Revengeful 30/7, 2019 at 18:15

T

39

In my case, pausing dropbox sync solved the issue

Transcendentalistic answered 4/3, 2017 at 2:47 Comment(0)

A

26

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.

Abuttal answered 19/9, 2015 at 2:31 Comment(2)

If your user account recently had any permissions issues, it could cause you to run into this issue. In my case, it was an Active Directory integration issue that left me with the problematic ACLs. – Piccadilly 31/10, 2016 at 19:28

worked in 2024. Thanks. – Steed 17/2, 2024 at 7:36

E

20

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.

Equalizer answered 30/4, 2017 at 12:58 Comment(0)

S

15

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

Supposed answered 26/3, 2019 at 13:27 Comment(1)

Thanks! Very helpful, just installed windows 11 and got the same error since I moved my repos on a external hard-drive. – Votaw 3/3, 2022 at 19:0

E

11

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.

Entreat answered 18/12, 2017 at 15:31 Comment(1)

I've closed the nodeJs server where my angularJs app was running and the index was unlocked – Ictus 19/10, 2018 at 9:41

A

9

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.

Antecedency answered 27/3, 2015 at 15:36 Comment(1)

same for me, it seems that when you have angular development server running and you try to commit then this error occurs – Abandon 29/1, 2021 at 3:35

T

7

This worked for me:

rm -f ./.git/index.lock

Talie answered 11/2, 2018 at 14:45 Comment(0)

L

6

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.

Luttrell answered 13/6, 2017 at 18:37 Comment(2)

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - From Review – Insensate 15/6, 2017 at 0:35

@Al, I updated my answer according to your suggestion. – Luttrell 16/6, 2017 at 14:47

L

5

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 focal virtualbox (git 1.2.2) adds the file without problems.

Laurentia answered 8/9, 2020 at 8:17 Comment(0)

H

4

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)

Headcloth answered 2/2, 2016 at 13:50 Comment(0)

E

3

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

Entitle answered 5/7, 2018 at 13:25 Comment(0)

H

2

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

Hospitable answered 25/2, 2015 at 14:27 Comment(1)

the question is 'why is the error message happening?' and this answer describes another potential cause. – Extraneous 18/3, 2016 at 10:24

K

2

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.

Karaite answered 28/7, 2016 at 21:22 Comment(0)

P

2

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.

Poll answered 16/11, 2016 at 1:43 Comment(1)

if new files were created or some modified content exists use git reset --hard before git rebase --continue. --hard is destructive, so do a git status to see what might be deleted first. – Encephaloma 15/6, 2021 at 11:33

L

2

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

Liberate answered 2/6, 2017 at 4:24 Comment(0)

M

2

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

Mientao answered 21/8, 2019 at 19:48 Comment(0)

G

1

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

Gaelic answered 16/1, 2014 at 5:29 Comment(0)

T

1

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

Tiber answered 4/12, 2019 at 15:13 Comment(0)

O

1

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://mcmap.net/q/126518/-git-39-fatal-unable-to-write-new-index-file-39

Ohalloran answered 30/8, 2021 at 8:38 Comment(0)

V

1

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%)

Valenciavalenciennes answered 21/12, 2021 at 17:37 Comment(0)

B

0

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

Basidium answered 8/1, 2018 at 5:58 Comment(0)

S

0

Here is what worked for me:

Context:

Building a project on a server
git status returns a HEAD detached at <commit-SHA>
What ever operation I did locally, I had this error. More specifically:
- git checkout
- git reset HEAD --hard

Solution

Simply removed file <work-dir>/.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 <commit-SHA> when doing a git status, but then you should be able to
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 :).

Seepage answered 18/1, 2018 at 10:30 Comment(0)

O

0

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

Oink answered 15/3, 2018 at 10:38 Comment(0)

I

0

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

Inexecution answered 27/6, 2018 at 5:19 Comment(0)

B

0

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.

Barbbarba answered 24/10, 2021 at 8:37 Comment(0)

T

0

I know there's so many causes, but my solution was to disconnect from my mac SMB share and reconnect it. I've found that AFP shares do not work at all, but SMB ones do. Go figure.

Tessler answered 4/10, 2022 at 5:9 Comment(0)

D

0

The same error happend for me using Ubuntu installed on VirtualBox (host is Windows). Git repositories are on shared folder. To be precise I got the following error while committing my changes:

warning: unable to unlink '[repo path]/.git/index.lock': Text file busy
fatal: unable to write new_index file

I could solve it by manually deleting [repo path]/.git/index.lock and committing the changes.

Demivolt answered 21/12, 2023 at 11:44 Comment(0)

R

-1

running with sudo worked for me.

for example: sudo git add -r

Revolution answered 14/7, 2021 at 6:10 Comment(1)

This is a stop-gap solution that will just cascade into more permission issues. It's better to fix permissions than act as a super user to simply add a file to the index. – Surge 15/10, 2021 at 19:56

Possible solutions

tl:dr - dirty solution

Recommended topics

Hot tags