git commit -m "<message>" returns fatal: cannot lock ref 'HEAD' - non-directory in the way

Question

git for windows, git version 2.41.windows.3

git init --separate-git-dir=///

I've had this problem very occasionally where git commit fails

fatal: cannot lock ref 'HEAD': unable to create lock file //<NAS>/<path>/.../<repo>/refs/heads/main.lock; non-directory in the way TortoiseGit reports lib2git problem to the effect that "cannot get head hash"

A few minutes after this failure, I tried again and it succeeded.

I now recall, but cannot confirm, that this may be because I have other connections (SMB?) to my NAS such as a Macrium scheduled backup using my credentials, or my host device (I'm in an RDP session) also connected to the NAS.

Anyone seen this problem before?

Is it a git problem, or a NAS/SMB issue?

What did I do in response...

1. Patience -- waited in case other connections were active (I didn't actively check to see) and miraculously the problem went away and commits started working

2. Played around with 'HEAD' and refs and backed off --- no need to muck with git when the problem is a 'non-directory'.

3. I'm tweaking my NAS to support SMB multi - see if the problem returns

Answer 1

Disclaimer: This answer does not solve your problem, but tries to explain why it occurs.

---

If you did git init with an separate git dir, you would not expect it to be at //<NAS>/<path>/.../<repo>/refs/heads/main.lock, would you? Tortoise seems to not recognize that.

Using --separate-git-dir when initializing creates a file named .git in the worktree directory. That file contains a link to the actual git-dir. Therefore, when tortoise looks for the .git-directory locally (in the worktree directory), it stumbles across a file .git rather than a directory, which is why you get the "not a directory"-error.

This question here says that tortoise should recognize what you want to do, but I presume that it cannot handle the SMB stuff inbetween.