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.

Not sure is this should go to [SuperUser](http://superuser.com) instead? — MMM, Apr 17 '13 at 15:48
most probably a problem with access rights (the user running git doesnt have write permission to all of the repo) — Nevik Rehnel, Apr 17 '13 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. — Jeff, Apr 17 '13 at 15:51
When do you see this issue ? Is it when you do a "git mv" or "git add" ? — Mayur Nagekar, Mar 12 '14 at 04:54

score 342 · Accepted Answer · answered Jan 16 '15 at 14:23

342

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

answered Jan 16 '15 at 14:23

Alexander Bird

38,679
42
124
159

full in source? or full in destination? (repo) – jim Dec 21 '21 at 17:35
Full in source, if I remember correctly. – Alexander Bird Dec 22 '21 at 13:49

score 76 · Answer 2 · answered Mar 12 '14 at 04:09

76

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.

answered Mar 12 '14 at 04:09

theatlasroom

1,126
9
12

88

Found yet another cause: you may be out of disk space. – lennartcl Nov 17 '14 at 09:57
26

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. – Kristjan O. Jan 09 '17 at 17:23
7

Thanks for the tip about Google Drive. I had the same issue, but with Dropbox. – hgolov Feb 19 '17 at 09:42
1

Restart worked for me. Working on a half empty, 22 TB shared drive, so space wasn't an issue. – Wayne F. Kaskie Apr 18 '17 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. – Drew Reese May 24 '18 at 15:33
2

your "dirty solution" worked for me (returned to a previous index file, re-added and re-committed all changes since then) – salouri Jun 11 '18 at 09:21
Dirty solution works when, say, SourceTree and PhpStorm are both displaying git logs at the same time – Drakes Oct 22 '18 at 23:10
Another possibility is Google Backup & Sync being in a bad state. Force-kill the process and try again. – Creos Mar 25 '19 at 06: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! – JGlass Jul 30 '19 at 18:15

score 31 · Answer 3 · answered Mar 04 '17 at 02:47

31

In my case, pausing dropbox sync solved the issue

answered Mar 04 '17 at 02:47

tonymayoral

4,797
2
26
27

score 24 · Answer 4 · answered Sep 19 '15 at 02:31

24

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.

answered Sep 19 '15 at 02:31

user2465454

241
2
3

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. – kris Oct 31 '16 at 19:28

Cornchip · Answer 5 · 2019-05-25T22:42:37.003

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.

edited May 25 '19 at 22:42

answered Apr 30 '17 at 12:58

Cornchip

334
3
12

score 15 · Answer 6 · answered Mar 26 '19 at 13:27

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

answered Mar 26 '19 at 13:27

Md. Alim Ul Karim

2,401
2
27
36

1

Thanks! Very helpful, just installed windows 11 and got the same error since I moved my repos on a external hard-drive. – Dynamic Games Mar 03 '22 at 19:00

score 11 · Answer 7 · answered Dec 18 '17 at 15:31

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.

answered Dec 18 '17 at 15:31

Spyryto

1,107
12
17

I've closed the nodeJs server where my angularJs app was running and the index was unlocked – Radu Linu Oct 19 '18 at 09:41

score 9 · Answer 8 · answered Mar 27 '15 at 15:36

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.

answered Mar 27 '15 at 15:36

gls123

5,467
2
28
28

same for me, it seems that when you have angular development server running and you try to commit then this error occurs – Nitin Sawant Jan 29 '21 at 03:35

score 7 · Answer 9 · answered Feb 11 '18 at 14:45

7

This worked for me:

rm -f ./.git/index.lock

answered Feb 11 '18 at 14:45

ForTheWin

617
1
8
15

Fan · Answer 10 · 2019-10-31T13:43:43.527

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.

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](/review/low-quality-posts/16412148) — Al Sweigart, Jun 15 '17 at 00:35

score 4 · Answer 11 · answered Feb 02 '16 at 13:50

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)

answered Feb 02 '16 at 13:50

Tim

41
1

ruud · Answer 12 · 2022-07-19T12:11:17.527

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.

score 3 · Answer 13 · answered Jul 05 '18 at 13:25

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

answered Jul 05 '18 at 13:25

J-Schaefer

129
1
3

score 2 · Answer 14 · answered Feb 25 '15 at 14:27

2

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

answered Feb 25 '15 at 14:27

Phil R.

21
1

the question is 'why is the error message happening?' and this answer describes another potential cause. – robm Mar 18 '16 at 10:24

score 2 · Answer 15 · answered Jul 28 '16 at 21:22

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.

score 2 · Answer 16 · answered Nov 16 '16 at 01:43

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.

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. — Dominic Clifton, Jun 15 '21 at 11:33

score 2 · Answer 17 · edited Feb 28 '18 at 00:25

2

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

edited Feb 28 '18 at 00:25

Leonardo Alves Machado

2,747
10
38
53

answered Jun 02 '17 at 04:24

Vijay S B

1,251
1
13
24

score 2 · Answer 18 · answered Aug 21 '19 at 19:48

2

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

answered Aug 21 '19 at 19:48

Enayat

3,904
1
33
47

score 1 · Answer 19 · answered Jan 16 '14 at 05:29

1

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

answered Jan 16 '14 at 05:29

User123456

2,492
3
30
44

score 1 · Answer 20 · answered Dec 04 '19 at 15:13

1

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

answered Dec 04 '19 at 15:13

Stephan Ahlf

3,310
5
39
68

Piyush Bansal · Answer 21 · 2021-08-31T16:14:38.457

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://stackoverflow.com/a/47871586/6236710

edited Aug 31 '21 at 16:14

answered Aug 30 '21 at 08:38

Piyush Bansal

31
1
7

score 1 · Answer 22 · answered Dec 21 '21 at 17:37

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

score 0 · Answer 23 · answered Jan 08 '18 at 05:58

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

score 0 · Answer 24 · answered Jan 18 '18 at 10:30

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

Rob Bowman · Answer 25 · 2018-06-21T12:41:50.960

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

edited Jun 21 '18 at 12:41

answered Mar 15 '18 at 10:38

Rob Bowman

7,632
22
93
200

score 0 · Answer 26 · answered Jun 27 '18 at 05:19

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

answered Jun 27 '18 at 05:19

Jim Yu

131
1
6

score 0 · Answer 27 · answered Oct 24 '21 at 08:37

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.

answered Oct 24 '21 at 08:37

Awsaf

66
5

score 0 · Answer 28 · answered Oct 04 '22 at 05:09

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.

answered Oct 04 '22 at 05:09

vr_driver

1,867
28
39

score -1 · Answer 29 · answered Jul 14 '21 at 06:10

-1

running with sudo worked for me.

for example: sudo git add -r

answered Jul 14 '21 at 06:10

Manor Zvi

29
3

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. – KymikoLoco Oct 15 '21 at 19:56

Git 'fatal: Unable to write new index file'

29 Answers29

Possible solutions

tl:dr - dirty solution

Linked