On September 18, 2024 12:16 PM, Marcos Del Sol Vives wrote: >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; >+ } I am not certain this is either necessary or important to platforms other than Windows. The /tmp directory is often, and properly set with the sticky bit +t. This ensures that only The creating user has access to the temp file regardless of create ownership or security. I would prefer that this be put into a compat layer rather than made general change. > /* > * 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
