Under WSL1 (Windows Subsystem for Linux), when using a network share mounted via DrvFs, Git fails to add any files to a new or an existing repository. The reason is that Git tries to open a temporary file as with RW permissions but mode 0444, which causes WSL1 (or Samba, unsure who's here to blame) to create first an file empty with the read-only DOS attribute set that prevents any writes, and then actually trying to opening it in write mode, which of course fails. Seems to be a pretty common issue that nobody has yet reported officially, judging by the amount of posts on Stackoverflow, impacting not only WSL but also CIFS under Linux (hence why sending to this mailing list and not the Windows-specific one): - https://superuser.com/questions/681196/debugging-git-repo-permissions-on-samba-share - https://superuser.com/questions/1450094/git-on-wsl-commands-fail-despite-permissions-seeming-fine - https://superuser.com/questions/1491499/use-git-on-a-shared-drive-within-wsl As a workaround, opening the file with permissions 0600 and then using a fchmod with the final desired mode works, which is a very small change that should cause no issues under neither real Linux nor WSL: --- git-2.39.5.orig/wrapper.c +++ git-2.39.5/wrapper.c @@ -484,9 +484,11 @@ int git_mkstemps_mode(char *pattern, int v /= num_letters; } - fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, mode); - if (fd >= 0) + fd = open(pattern, O_CREAT | O_EXCL | O_RDWR, 0600); + if (fd >= 0) { + fchmod(fd, mode); return fd; + } /* * Fatal error (EPERM, ENOSPC etc). * It doesn't make sense to loop. The WSL team at Microsoft has been already informed as well: https://github.com/microsoft/WSL/issues/12051
