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

>
> 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@gmx.de> 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@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