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 at 8:41 AM Erwan Leroy [off-list ref] 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 [off-list ref] wrote:

quoted

Hi Erwan,

On Thu, 26 Jun 2025, Erwan Leroy wrote:

quoted

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.

quoted

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.

quoted

- 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?

quoted

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