19

I am having a constant issue with one of my git repos. I keep getting the following error:

    fatal: Unable to create 'v:/path/to/files/.git/index.lock': File exists.

    If no other git process is currently running, this probably means a
    git process crashed in this repository earlier. Make sure no other git
    process is running and remove the file manually to continue.

I have tried: rm -f ./.git/index.lock as per another thread on stackoverflow but I get this error each time: rm: cannot unlink `./.git/index.lock': Permission denied

When I close down aptana (I am using git in the terminal) I cannot delete the file still.

Any ideas how to get around this?

Another thing to note is this git repo is very slow when I do occasionally get to commit within it (it allows me every 10 tries or so)

Thanks

sluggerdog
  • 843
  • 4
  • 12
  • 35
  • It works for me http://stackoverflow.com/questions/17916339/error-in-deleting-addind-file-from-appharbor-using-git-unable-to-create-f-git – Shailesh Jul 29 '13 at 05:41
  • Do you have root or superuser access to the system you are using? In other words, do you own the computer or are you on a public computer, such as in a campus lab? – Code-Apprentice Oct 08 '13 at 17:59
  • these commands are for unix and osx systems. you can go to the index.lock file in the explorer and delete it. if you dont see .git folder. you need to set show hidden files in your file folder manager first – Jinxi Dec 05 '14 at 08:21
  • Try using "rm .git/index.lock"or refer this https://robots.thoughtbot.com/how-to-fix-rm-f-git-index – Ajay Sharma Nov 30 '16 at 10:21

7 Answers7

33

Sudo the command:

sudo rm -f ./.git/index.lock

Both errors suggest index.lock is owned by another user. Run the rm as a superuser, then try your commands again. You might also consider setting core.sharedRepository to true if that is, in fact, the case with your repo:

core.sharedRepository

When group (or true), the repository is made shareable between several users in a group (making sure all the files and objects are group-writable).

When all (or world or everybody), the repository will be readable by all users, additionally to being group-shareable. When umask (or false), git will use permissions reported by umask(2). When 0xxx, where 0xxx is an octal number, files in the repository will have this mode value. 0xxx will override user's umask value (whereas the other options will only override requested parts of the user's umask value). Examples: 0660 will make the repo read/write-able for the owner and group, but inaccessible to others (equivalent to group unless umask is e.g. 0022). 0640 is a repository that is group-readable but not group-writable.

See git-init(1).

False by default.

Brandon
  • 16,382
  • 12
  • 55
  • 88
Christopher
  • 42,720
  • 11
  • 81
  • 99
  • Thanks, I tried to sudo, I got this: sh: sudo: command not found. Also I don't know how to log in as a super user, I only just started using git this week. – sluggerdog Aug 07 '12 at 06:46
  • I am still having huge issues with this, every day when I try I get the index.lock error. I am still getting the sh: sudo: command not found and cannot manually delete the file, always permission denied. Any ideas? Thanks! – sluggerdog Aug 24 '12 at 05:21
  • 1
    @sluggerdog What operating system are you on? Also, how are you running the git commands? – Christopher Aug 24 '12 at 12:06
  • I'm using windows 7, 64bit. Thanks – sluggerdog Aug 25 '12 at 20:23
  • This is a permissions problem; specifically, you're running the `git` command with inconsistently permissioned users. I know how to fix this on POSIX, not on Windows, I'm afraid, but it can't be difficult. – Christopher Aug 27 '12 at 13:38
4

The issue ended up being Aptana, everytime I ran this it would cause this error when I tried to commit in git.

I stopped using aptana studio and I don't have this issue anymore.

sluggerdog
  • 843
  • 4
  • 12
  • 35
1

You also get this error if you are using Aptanta Git and other git clients, like f.e. TortoiseGit. So it is likely that this other Git software locked your Git, making it unavailable for Aptana.

Johan Van de Merwe
  • 312
  • 2
  • 8
1

Do this:

rm index.lock

followed by

git reset

SEAFERN
  • 53
  • 3
1

Be careful with

rm -f .git/index.lock
git reset

Doing a git reset will delete any uncommitted changes that you've made.

Deleting your index.lock will mean that git will not be able to track any local changes.

One alternative for restoring your index.lock could be to git stash your last commit (if it's not yet pushed), and then do a git stash pop to add it back in.

So:

rm -f .git/index.lock
git stash
git stash pop

This will create a new index.lock without doing a git reset.

If you had previously git added some files without committing, you will need to git add those files again.

It's a bit of a hack. Comments?

Steve
  • 93
  • 1
  • 9
0

This may be an old reply but I'm hoping this is more useful on next who need this solution.

On linux/unix/gitbash/cygwin, try

rm -f .git/index.lock

On Windows Command Prompt, try:

del .git\index.lock

Hope that helps, I found this solution here: fatal: Unable to create 'project_path/.git/index.lock': File exists.

Community
  • 1
  • 1
krishnaisdinesh
  • 379
  • 4
  • 17
  • `rm` won't work since they don't have permissions - as it's owned by someone else - unless you `sudo` the command. *"I have tried: rm -f ./.git/index.lock as per another thread on stackoverflow but I get this error each time: rm: cannot unlink `./.git/index.lock': Permission denied"* – ʰᵈˑ Apr 19 '16 at 09:48
  • sudo is needed only project is own by some other user otherwise won't. So it's not mandatory part. – krishnaisdinesh Apr 19 '16 at 10:34
  • It is owned by someone else, specifically used by Aptana. – ʰᵈˑ Apr 19 '16 at 10:35
  • When project having 777 permission it doesn't matter used by aptana or any other ide . – krishnaisdinesh Apr 19 '16 at 11:12
  • ..and where does it say OP permissions are 777? Your answer gives no real help to the OP; it's re-iterating what they've tried. – ʰᵈˑ Apr 19 '16 at 11:14
0

In git version 2.11.0, .git folder may not include the index.lock file. I figured out in the .git/refs/heads/ folder contains a .lock file and removing it using rm command works.

Also be sure to kill the process that might be using git repo using ps -aef | grep git and kill -9.

Harshit Garg
  • 2,137
  • 21
  • 23