Hi Erwan, On Thu, 26 Jun 2025, Erwan Leroy wrote: > I'm writing to see if maybe this is a known issue, or if there is a > possible known workaround. I've not been part of this mailing list > before so I hope the format I'm using for reporting is going to be > correct/helpful (this is attempt #2, I did not set plain text the > first time). > > A bit of context: > At work, we are fully Windows-based, and mount our network drives > through DFS. We are fully cut-off from the internet so everything we > run is local to the internal network, which makes certain tests a bit > more time-consuming than they should be. > We have been working for years with Git and a self-hosted gitlab > server, and have had no issues. > Recently, some of the new hires started reporting lots of Git errors, > mostly apparent permission denied errors. > > One of the errors: > PS Y:\Users\xx\Public\dev\test_for_it> git remote add origin > git@xxxxxxxxx.local:xx/test.git > Rename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock' > to '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config' > failed. Should I try again? (y/n) n > error: could not write config file .git/config: Permission denied > fatal: could not set 'remote.origin.url' to 'git@xxxxxxxxx.local:xx/test.git' Interesting. I would have expected a different type of error message than "Permission denied", as I had initially expected Git's new `rename()` emulation that uses POSIX semantics on Windows to be the culprit. But Git v2.36 pre-dates that feature, and you said below that even that Git version is affected. > What we found out: > - The first thing we found out was that only network drives were affected. > - The second thing we noticed was that not only new employees after a > certain date were getting issues, but also longer employees getting > new workstations. This started to make an actual permission issue less > likely, as there was no change to their user permissions. > - Then we noticed that the delimiting factor was the Git version: > Users on Git 2.21 and older had no problems. Users on Git 2.36 and > newer (we also had some users on 2.47, and today downloaded and tested > the latest 2.50). I would have tested every version in the range 2.21 > to 2.36 to help narrow exactly where it breaks, but I can't find > pre-compiled versions for old versions and I'm not currently set up > for compiling from source. There is a _huge_ list of pre-compiled versions, ordered chronologically, at https://gitforwindows.org/git-snapshots/. It is admittedly a bit cumbersome to find a particular version by version number; I have been meaning to add something there but keep being "distracted" by more pressing problems like the one you reported. > - We also recently found out it only breaks when accessing through > DFS, if we directly access the corresponding UNC path (what DFS > resolves to), we do not get the same error. Could you describe this in a bit more detail? I see in the quoted text above that you were accessing the worktree via `Y:\` and that its error message references `\\atl-xx\Basecamp` instead, are you referring to the latter as UNC path and the former as the DFS path? > It's not excluded that there is something wrong with our network, but > the fact that it works with older git versions and not with newer ones > makes me think git has a role to play in our issues. > I wasn't able to find a changelog, if nobody is able to look into our > issue closer I'd love to at least be pointed in the right direction to > see the changes that happened between 2.21 and 2.36. The ChangeLog is rather huge, Git's changes are described in https://github.com/git/git/tree/HEAD/Documentation/RelNotes and Git for Windows' (substantially fewer) changes are described at https://github.com/git-for-windows/build-extra/blob/HEAD/ReleaseNotes.md. Hopefully we can figure this out soon, Johannes
