{"thread":{"id":"63702","subject":"Git \"Permission Denied\" errors on DFS path only with newer versions","startedAt":"2025-06-27T00:14:15Z","lastAt":"2025-07-01T06:18:45Z","messageCount":5,"participants":["Erwan Leroy","brian m. carlson","D. Ben Knoble","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"520789","messageId":"CADT1yYmQGG5mQnWk=+19UOEvcDyiUQmWsib9jUJsPDc=A27vMw@mail.gmail.com","threadId":"63702","inReplyTo":null,"subject":"Git \"Permission Denied\" errors on DFS path only with newer versions","fromName":"Erwan Leroy","fromEmail":"erwan@erwanleroy.com","sentAt":"2025-06-27T00:14:02Z","receivedAt":"2025-06-27T00:14:15Z","isPatch":false,"sender":{"key":"erwan@erwanleroy.com","avatar":null},"body":"Hello.\n\nI'm writing to see if maybe this is a known issue, or if there is a\npossible known workaround. I've not been part of this mailing list\nbefore so I hope the format I'm using for reporting is going to be\ncorrect/helpful (this is attempt #2, I did not set plain text the\nfirst time).\n\nA bit of context:\nAt work, we are fully Windows-based, and mount our network drives\nthrough DFS. We are fully cut-off from the internet so everything we\nrun is local to the internal network, which makes certain tests a bit\nmore time-consuming than they should be.\nWe have been working for years with Git and a self-hosted gitlab\nserver, and have had no issues.\nRecently, some of the new hires started reporting lots of Git errors,\nmostly apparent permission denied errors.\n\nOne of the errors:\nPS Y:\\Users\\xx\\Public\\dev\\test_for_it> git remote add origin\ngit@gitlab.xx.local:xx/test.git\nRename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock'\nto '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config'\nfailed. Should I try again? (y/n) n\nerror: could not write config file .git/config: Permission denied\nfatal: could not set 'remote.origin.url' to 'git@gitlab.xx.local:xx/test.git'\n\n\nWhat we found out:\n- The first thing we found out was that only network drives were affected.\n- The second thing we noticed was that not only new employees after a\ncertain date were getting issues, but also longer employees getting\nnew workstations. This started to make an actual permission issue less\nlikely, as there was no change to their user permissions.\n- Then we noticed that the delimiting factor was the Git version:\nUsers on Git 2.21 and older had no problems. Users on Git 2.36 and\nnewer (we also had some users on 2.47, and today downloaded and tested\nthe latest 2.50). I would have tested every version in the range 2.21\nto 2.36 to help narrow exactly where it breaks, but I can't find\npre-compiled versions for old versions and I'm not currently set up\nfor compiling from source.\n- We also recently found out it only breaks when accessing through\nDFS, if we directly access the corresponding UNC path (what DFS\nresolves to), we do not get the same error.\n\n\nIt's not excluded that there is something wrong with our network, but\nthe fact that it works with older git versions and not with newer ones\nmakes me think git has a role to play in our issues.\nI wasn't able to find a changelog, if nobody is able to look into our\nissue closer I'd love to at least be pointed in the right direction to\nsee the changes that happened between 2.21 and 2.36.\n\nThank you in advance,\nErwan\n"},{"id":"520818","messageId":"aF7nTwI6dufVZLr9@fruit.crustytoothpaste.net","threadId":"63702","inReplyTo":"CADT1yYmQGG5mQnWk=+19UOEvcDyiUQmWsib9jUJsPDc=A27vMw@mail.gmail.com","subject":"Re: Git \"Permission Denied\" errors on DFS path only with newer versions","fromName":"brian m. carlson","fromEmail":"sandals@crustytoothpaste.net","sentAt":"2025-06-27T18:47:43Z","receivedAt":"2025-06-27T18:47:52Z","isPatch":false,"sender":{"key":"sandals@crustytoothpaste.net","avatar":"https://avatars.githubusercontent.com/u/497054?v=4"},"body":"On 2025-06-27 at 00:14:02, Erwan Leroy wrote:\n> Hello.\n> \n> I'm writing to see if maybe this is a known issue, or if there is a\n> possible known workaround. I've not been part of this mailing list\n> before so I hope the format I'm using for reporting is going to be\n> correct/helpful (this is attempt #2, I did not set plain text the\n> first time).\n> \n> A bit of context:\n> At work, we are fully Windows-based, and mount our network drives\n> through DFS. We are fully cut-off from the internet so everything we\n> run is local to the internal network, which makes certain tests a bit\n> more time-consuming than they should be.\n> We have been working for years with Git and a self-hosted gitlab\n> server, and have had no issues.\n> Recently, some of the new hires started reporting lots of Git errors,\n> mostly apparent permission denied errors.\n> \n> One of the errors:\n> PS Y:\\Users\\xx\\Public\\dev\\test_for_it> git remote add origin\n> git@gitlab.xx.local:xx/test.git\n> Rename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock'\n> to '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config'\n> failed. Should I try again? (y/n) n\n> error: could not write config file .git/config: Permission denied\n> fatal: could not set 'remote.origin.url' to 'git@gitlab.xx.local:xx/test.git'\n> \n> \n> What we found out:\n> - The first thing we found out was that only network drives were affected.\n> - The second thing we noticed was that not only new employees after a\n> certain date were getting issues, but also longer employees getting\n> new workstations. This started to make an actual permission issue less\n> likely, as there was no change to their user permissions.\n> - Then we noticed that the delimiting factor was the Git version:\n> Users on Git 2.21 and older had no problems. Users on Git 2.36 and\n> newer (we also had some users on 2.47, and today downloaded and tested\n> the latest 2.50). I would have tested every version in the range 2.21\n> to 2.36 to help narrow exactly where it breaks, but I can't find\n> pre-compiled versions for old versions and I'm not currently set up\n> for compiling from source.\n> - We also recently found out it only breaks when accessing through\n> DFS, if we directly access the corresponding UNC path (what DFS\n> resolves to), we do not get the same error.\n\nI would suggest looking at the Git for Windows issue tracker.  There are\na couple of DFS-related issues, including\nhttps://github.com/git-for-windows/git/issues/3825, which seems\npotentially relevant.\n\nUnfortunately, I don't use Windows, so I'm afraid I can't be of more\nhelp, but this definitely seems like a Windows-specific issue, so the\nGit for Windows issue tracker would be the best place to discuss it.\nDscho, the maintainer, is very capable and will likely know how to\nhandle this problem.\n\nIf you need a workaround and the one in that issue doesn't work, you may\nwish to try using the Windows Subsystem for Linux for accessing the\nrepository after configuring it for Unix metadata support as outlined in\n[0].  In that case, it will be Windows itself that will be doing the\nconversion to POSIX-style path handling and it's likely that it will be\nperhaps a little less brittle than MSYS2 in handling some of the more\nesoteric Windows file system features (such as DFS).\n\nBest of luck in getting this to work.\n\n[0] https://stackoverflow.com/questions/78997348/git-shows-all-files-changed-when-git-init-was-used-in-wsl-and-git-diff-in-wi\n-- \nbrian m. carlson (they/them)\nToronto, Ontario, CA\n"},{"id":"520824","messageId":"CALnO6CAdftdE7uCrrRPRvqS5J8G_iFxoTY8GffxGEOZkJ98aWA@mail.gmail.com","threadId":"63702","inReplyTo":"CADT1yYmQGG5mQnWk=+19UOEvcDyiUQmWsib9jUJsPDc=A27vMw@mail.gmail.com","subject":"Re: Git \"Permission Denied\" errors on DFS path only with newer versions","fromName":"D. Ben Knoble","fromEmail":"ben.knoble@gmail.com","sentAt":"2025-06-27T19:50:02Z","receivedAt":"2025-06-27T19:50:15Z","isPatch":false,"sender":{"key":"ben.knoble@gmail.com","avatar":"https://avatars.githubusercontent.com/u/22802209?v=4"},"body":"On Thu, Jun 26, 2025 at 8:14 PM Erwan Leroy <erwan@erwanleroy.com> wrote:\n>\n> Hello.\n>\n> I'm writing to see if maybe this is a known issue, or if there is a\n> possible known workaround. I've not been part of this mailing list\n> before so I hope the format I'm using for reporting is going to be\n> correct/helpful (this is attempt #2, I did not set plain text the\n> first time).\n>\n> A bit of context:\n> At work, we are fully Windows-based, and mount our network drives\n> through DFS. We are fully cut-off from the internet so everything we\n> run is local to the internal network, which makes certain tests a bit\n> more time-consuming than they should be.\n> We have been working for years with Git and a self-hosted gitlab\n> server, and have had no issues.\n> Recently, some of the new hires started reporting lots of Git errors,\n> mostly apparent permission denied errors.\n>\n> One of the errors:\n> PS Y:\\Users\\xx\\Public\\dev\\test_for_it> git remote add origin\n> git@gitlab.xx.local:xx/test.git\n> Rename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock'\n> to '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config'\n> failed. Should I try again? (y/n) n\n> error: could not write config file .git/config: Permission denied\n> fatal: could not set 'remote.origin.url' to 'git@gitlab.xx.local:xx/test.git'\n>\n>\n> What we found out:\n> - The first thing we found out was that only network drives were affected.\n> - The second thing we noticed was that not only new employees after a\n> certain date were getting issues, but also longer employees getting\n> new workstations. This started to make an actual permission issue less\n> likely, as there was no change to their user permissions.\n> - Then we noticed that the delimiting factor was the Git version:\n> Users on Git 2.21 and older had no problems. Users on Git 2.36 and\n> newer (we also had some users on 2.47, and today downloaded and tested\n> the latest 2.50). I would have tested every version in the range 2.21\n> to 2.36 to help narrow exactly where it breaks, but I can't find\n> pre-compiled versions for old versions and I'm not currently set up\n> for compiling from source.\n> - We also recently found out it only breaks when accessing through\n> DFS, if we directly access the corresponding UNC path (what DFS\n> resolves to), we do not get the same error.\n>\n>\n> It's not excluded that there is something wrong with our network, but\n> the fact that it works with older git versions and not with newer ones\n> makes me think git has a role to play in our issues.\n> I wasn't able to find a changelog, if nobody is able to look into our\n> issue closer I'd love to at least be pointed in the right direction to\n> see the changes that happened between 2.21 and 2.36.\n\nChangelogs are available with the source, for example on GitHub:\n\nhttps://github.com/git/git/tree/master/Documentation/RelNotes\n\n>\n> Thank you in advance,\n> Erwan\n>\n\n\n-- \nD. Ben Knoble\n"},{"id":"520911","messageId":"3bb920aa-5bb9-b9ca-64ed-cd8b3aecdce2@gmx.de","threadId":"63702","inReplyTo":"CADT1yYmQGG5mQnWk=+19UOEvcDyiUQmWsib9jUJsPDc=A27vMw@mail.gmail.com","subject":"Re: Git \"Permission Denied\" errors on DFS path only with newer versions","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2025-06-30T10:48:29Z","receivedAt":"2025-06-30T10:48:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Erwan,\n\nOn Thu, 26 Jun 2025, Erwan Leroy wrote:\n\n> I'm writing to see if maybe this is a known issue, or if there is a\n> possible known workaround. I've not been part of this mailing list\n> before so I hope the format I'm using for reporting is going to be\n> correct/helpful (this is attempt #2, I did not set plain text the\n> first time).\n> \n> A bit of context:\n> At work, we are fully Windows-based, and mount our network drives\n> through DFS. We are fully cut-off from the internet so everything we\n> run is local to the internal network, which makes certain tests a bit\n> more time-consuming than they should be.\n> We have been working for years with Git and a self-hosted gitlab\n> server, and have had no issues.\n> Recently, some of the new hires started reporting lots of Git errors,\n> mostly apparent permission denied errors.\n> \n> One of the errors:\n> PS Y:\\Users\\xx\\Public\\dev\\test_for_it> git remote add origin\n> git@gitlab.xx.local:xx/test.git\n> Rename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock'\n> to '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config'\n> failed. Should I try again? (y/n) n\n> error: could not write config file .git/config: Permission denied\n> fatal: could not set 'remote.origin.url' to 'git@gitlab.xx.local:xx/test.git'\n\nInteresting. I would have expected a different type of error message than\n\"Permission denied\", as I had initially expected Git's new `rename()`\nemulation that uses POSIX semantics on Windows to be the culprit. But Git\nv2.36 pre-dates that feature, and you said below that even that Git\nversion is affected.\n\n> What we found out:\n> - The first thing we found out was that only network drives were affected.\n> - The second thing we noticed was that not only new employees after a\n> certain date were getting issues, but also longer employees getting\n> new workstations. This started to make an actual permission issue less\n> likely, as there was no change to their user permissions.\n> - Then we noticed that the delimiting factor was the Git version:\n> Users on Git 2.21 and older had no problems. Users on Git 2.36 and\n> newer (we also had some users on 2.47, and today downloaded and tested\n> the latest 2.50). I would have tested every version in the range 2.21\n> to 2.36 to help narrow exactly where it breaks, but I can't find\n> pre-compiled versions for old versions and I'm not currently set up\n> for compiling from source.\n\nThere is a _huge_ list of pre-compiled versions, ordered chronologically,\nat https://gitforwindows.org/git-snapshots/. It is admittedly a bit\ncumbersome to find a particular version by version number; I have been\nmeaning to add something there but keep being \"distracted\" by more\npressing problems like the one you reported.\n\n> - We also recently found out it only breaks when accessing through\n> DFS, if we directly access the corresponding UNC path (what DFS\n> resolves to), we do not get the same error.\n\nCould you describe this in a bit more detail? I see in the quoted text\nabove that you were accessing the worktree via `Y:\\` and that its error\nmessage references `\\\\atl-xx\\Basecamp` instead, are you referring to the\nlatter as UNC path and the former as the DFS path?\n\n> It's not excluded that there is something wrong with our network, but\n> the fact that it works with older git versions and not with newer ones\n> makes me think git has a role to play in our issues.\n> I wasn't able to find a changelog, if nobody is able to look into our\n> issue closer I'd love to at least be pointed in the right direction to\n> see the changes that happened between 2.21 and 2.36.\n\nThe ChangeLog is rather huge, Git's changes are described in\nhttps://github.com/git/git/tree/HEAD/Documentation/RelNotes and Git for\nWindows' (substantially fewer) changes are described at\nhttps://github.com/git-for-windows/build-extra/blob/HEAD/ReleaseNotes.md.\n\nHopefully we can figure this out soon,\nJohannes\n"},{"id":"520989","messageId":"CADT1yYn3q_y7eOnQqzcjXiS8uGNwgxe36k9Tgo39nb8=Dk4PzA@mail.gmail.com","threadId":"63702","inReplyTo":"CADT1yYndhgvj+AUB3PyWnSOZJ3uwvqjJSajJ-Y+7hVOzqUBHpw@mail.gmail.com","subject":"Re: Git \"Permission Denied\" errors on DFS path only with newer versions","fromName":"Erwan Leroy","fromEmail":"erwan@erwanleroy.com","sentAt":"2025-07-01T06:18:33Z","receivedAt":"2025-07-01T06:18:45Z","isPatch":false,"sender":{"key":"erwan@erwanleroy.com","avatar":null},"body":"Hi Johannes\n\nThanks for your answer.\nI'll do my best to explain our network setup, unfortunately it's\nrather specific so reproducing it might be difficult, and I'm also not\nIT so I might be missing a few details.\n\nAt the base we have a few Samba shares that each live on a different server.\nThese are mounted on Windows as UNC paths. That would be the\n`\\\\atl-xx\\Basecamp` mentioned above.\nThat one is the one for our Atlanta office. Those all work with Git.\n\nThen we have a DFS server, which would expose a different UNC path for\neach office, but also allows us to move things between servers without\nhaving every path change. This would expose everything under\n`\\\\xxx.local\\Basecamp`, but under the hood resolves to the UNC path of\nthe real server. This is where Git starts to have issues.\n\nFinally, the DFS path is mounted as our Y drive, which is what most\nemployees use to access the data. This also doesn't work with Git, but\nI assume it's simply because that resolves to the non-functional DFS\npath. Another drive letter that points to a local drive works\nperfectly fine.\n\nThanks for the build Snapshots, I'll take a look at those, if I can\nnarrow the issue down to a single build I'm sure it would make finding\nthe issue a lot easier.\n\nBest\nErwan\n\nOn Mon, Jun 30, 2025 at 8:41 AM Erwan Leroy <erwan@erwanleroy.com> wrote:\n>\n> Hi Johannes\n>\n> Thanks for your answer.\n> 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.\n>\n> At the base we have a few Samba shares that each live on a different server.\n> These are mounted on Windows as UNC paths. That would be the `\\\\atl-xx\\Basecamp` mentioned above.\n> That one is the one for our Atlanta office. Those all work with Git.\n>\n> 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.\n>\n> 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.\n>\n> 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.\n>\n> Best\n> Erwan\n>\n>\n> On Mon, Jun 30, 2025, 03:48 Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n>>\n>> Hi Erwan,\n>>\n>> On Thu, 26 Jun 2025, Erwan Leroy wrote:\n>>\n>> > I'm writing to see if maybe this is a known issue, or if there is a\n>> > possible known workaround. I've not been part of this mailing list\n>> > before so I hope the format I'm using for reporting is going to be\n>> > correct/helpful (this is attempt #2, I did not set plain text the\n>> > first time).\n>> >\n>> > A bit of context:\n>> > At work, we are fully Windows-based, and mount our network drives\n>> > through DFS. We are fully cut-off from the internet so everything we\n>> > run is local to the internal network, which makes certain tests a bit\n>> > more time-consuming than they should be.\n>> > We have been working for years with Git and a self-hosted gitlab\n>> > server, and have had no issues.\n>> > Recently, some of the new hires started reporting lots of Git errors,\n>> > mostly apparent permission denied errors.\n>> >\n>> > One of the errors:\n>> > PS Y:\\Users\\xx\\Public\\dev\\test_for_it> git remote add origin\n>> > git@gitlab.xx.local:xx/test.git\n>> > Rename from '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config.lock'\n>> > to '//atl-xx/Basecamp_Atl/Users/xx/Public/dev/test_for_it/.git/config'\n>> > failed. Should I try again? (y/n) n\n>> > error: could not write config file .git/config: Permission denied\n>> > fatal: could not set 'remote.origin.url' to 'git@gitlab.xx.local:xx/test.git'\n>>\n>> Interesting. I would have expected a different type of error message than\n>> \"Permission denied\", as I had initially expected Git's new `rename()`\n>> emulation that uses POSIX semantics on Windows to be the culprit. But Git\n>> v2.36 pre-dates that feature, and you said below that even that Git\n>> version is affected.\n>>\n>> > What we found out:\n>> > - The first thing we found out was that only network drives were affected.\n>> > - The second thing we noticed was that not only new employees after a\n>> > certain date were getting issues, but also longer employees getting\n>> > new workstations. This started to make an actual permission issue less\n>> > likely, as there was no change to their user permissions.\n>> > - Then we noticed that the delimiting factor was the Git version:\n>> > Users on Git 2.21 and older had no problems. Users on Git 2.36 and\n>> > newer (we also had some users on 2.47, and today downloaded and tested\n>> > the latest 2.50). I would have tested every version in the range 2.21\n>> > to 2.36 to help narrow exactly where it breaks, but I can't find\n>> > pre-compiled versions for old versions and I'm not currently set up\n>> > for compiling from source.\n>>\n>> There is a _huge_ list of pre-compiled versions, ordered chronologically,\n>> at https://gitforwindows.org/git-snapshots/. It is admittedly a bit\n>> cumbersome to find a particular version by version number; I have been\n>> meaning to add something there but keep being \"distracted\" by more\n>> pressing problems like the one you reported.\n>>\n>> > - We also recently found out it only breaks when accessing through\n>> > DFS, if we directly access the corresponding UNC path (what DFS\n>> > resolves to), we do not get the same error.\n>>\n>> Could you describe this in a bit more detail? I see in the quoted text\n>> above that you were accessing the worktree via `Y:\\` and that its error\n>> message references `\\\\atl-xx\\Basecamp` instead, are you referring to the\n>> latter as UNC path and the former as the DFS path?\n>>\n>> > It's not excluded that there is something wrong with our network, but\n>> > the fact that it works with older git versions and not with newer ones\n>> > makes me think git has a role to play in our issues.\n>> > I wasn't able to find a changelog, if nobody is able to look into our\n>> > issue closer I'd love to at least be pointed in the right direction to\n>> > see the changes that happened between 2.21 and 2.36.\n>>\n>> The ChangeLog is rather huge, Git's changes are described in\n>> https://github.com/git/git/tree/HEAD/Documentation/RelNotes and Git for\n>> Windows' (substantially fewer) changes are described at\n>> https://github.com/git-for-windows/build-extra/blob/HEAD/ReleaseNotes.md.\n>>\n>> Hopefully we can figure this out soon,\n>> Johannes\n"}]}