Hi Johannes Thanks for your answer. I'll do my best to explain our network setup, unfortunately it's rather specific so reproducing it might be difficult, and I'm also not IT so I might be missing a few details. At the base we have a few Samba shares that each live on a different server. These are mounted on Windows as UNC paths. That would be the `\\atl-xx\Basecamp` mentioned above. That one is the one for our Atlanta office. Those all work with Git. Then we have a DFS server, which would expose a different UNC path for each office, but also allows us to move things between servers without having every path change. This would expose everything under `\\xxx.local\Basecamp`, but under the hood resolves to the UNC path of the real server. This is where Git starts to have issues. Finally, the DFS path is mounted as our Y drive, which is what most employees use to access the data. This also doesn't work with Git, but I assume it's simply because that resolves to the non-functional DFS path. Another drive letter that points to a local drive works perfectly fine. Thanks for the build Snapshots, I'll take a look at those, if I can narrow the issue down to a single build I'm sure it would make finding the issue a lot easier. Best Erwan On Mon, Jun 30, 2025 at 8:41 AM Erwan Leroy <erwan@xxxxxxxxxxxxxx> wrote: > > Hi Johannes > > Thanks for your answer. > I'll do my best to explain our network setup, unfortunately it's rather specific so reproducing it might be difficult, and I'm also not IT so I might be missing a few details. > > At the base we have a few Samba shares that each live on a different server. > These are mounted on Windows as UNC paths. That would be the `\\atl-xx\Basecamp` mentioned above. > That one is the one for our Atlanta office. Those all work with Git. > > Then we have a DFS server, which would expose a different UNC path for each office, but also allows us to move things between servers without having every path change. This would expose everything under `\\xxx.local\Basecamp`, but under the hood resolves to the UNC path of the real server. This is where Git starts to have issues. > > Finally, the DFS path is mounted as our Y drive, which is what most employees use to access the data. This also doesn't work with Git, but I assume it's simply because that resolves to the non-functional DFS path. Another drive letter that points to a local drive works perfectly fine. > > Thanks for the build Snapshots, I'll take a look at those, if I can narrow the issue down to a single build I'm sure it would make finding the issue a lot easier. > > Best > Erwan > > > On Mon, Jun 30, 2025, 03:48 Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: >> >> 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
