Re: Git "Permission Denied" errors on DFS path only with newer versions

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

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@gitlab.xx.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@gitlab.xx.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