git status fails on H: disk which is mapped to a \\share\home\username directory when \\share\home is not readable

[hlovdal]

Existing issues matching what you're seeing

• I was not able to find an open or closed issue matching what I'm seeing

Git for Windows version

v2.50.0-rc2.windows.1

Windows version

Windows 10

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.19045.5965]

Options set during installation

$ cat /etc/install-options.txt
Editor Option: VIM
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Rebase
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled

Other interesting things

If I run git status on my H: drive it fails because the parent directory is not readable:

$ net use
New connections will be remembered.


Status       Local     Remote                    Network

-------------------------------------------------------------------------------
OK           H:        \\filesever.example.com\home\username
                                                Microsoft Windows Network
...
$
$ ls '\\filesever.example.com\home\username' | wc -l
27

$ ls '\\filesever.example.com\home' | wc -l
ls: cannot open directory '\\filesever.example.com\home': Permission denied
0

$ cd /h
$ ls | wc -l
27

$ git status
fatal: failed to stat '                                           //filesever.example.com/home/': Permission denied

$

So something about git's way of accessing the filesystem is different from other programs (like ls) and causes it to fail under this scenario.

Tested on both Windows 10 Pro 22H2 and Windows 11 Pro 22H2 with all updates as of today installed with version 2.49.0.windows.1.

git config --global --add safe.directory /h did not help.

Updating to v2.50.0-rc2.windows.1 did not help. I also downgraded to an older version, v2.42.0.windows.1, with the same result.

Terminal/shell

bash and powershell

Commands that trigger the issue

git status

Expected behaviour

On branch ...
...

or

fatal: not a git repository (or any of the parent directories): .git

Actual behaviour

fatal: failed to stat '                                           //filesever.example.com/home/': Permission denied

Repository

No response

[dscho]

fatal: failed to stat ' //filesever.example.com/home/': Permission denied

Those spaces between the leading single quote and the double slash are not actually printed by Git, right?

As to the actual problem, can you suppress this error by setting GIT_CEILING_DIRECTORIES to the absolute path of that home directory?

[dscho]

When trying to replicate this on Linux, I get the same error message, and this is the backtrace:

#0  die_builtin (err=0x7fffffffd810 "failed to stat '%*s%s%s': Permission denied", params=0x7fffffffd7f8) at usage.c:81
#1  0x00005555558d4bee in die_errno (fmt=0x55555599c566 "failed to stat '%*s%s%s'") at usage.c:247
#2  0x000055555588244a in get_device_or_die (path=0x555555a74310 "/a/b/c/d/e/f/g/h",
    prefix=0x0, prefix_len=0) at setup.c:1187
#3  0x0000555555882d23 in setup_git_directory_gently_1 (dir=0x7fffffffdeb0, gitdir=0x7fffffffdff0, report=0x0,
    die_on_error=0) at setup.c:1489
[...]

(I had created a repository in /a/b/c/d/e/f/g/h and then removed all permissions from /a/b/c via chmod a-rwx, then switched to h as root and then called su <user> to get a login shell for the non-administrator account.)

The reason is that Git tries to stat() the absolute path here, and I am unsure whether this can be fixed.

In any case, my finding is that this is not even a Windows-specific issue.

[hlovdal]

Those leading spaces is a verbatim copy of what git prints (string formatted in get_device_or_die).

Same permission denied with export GIT_CEILING_DIRECTORIES=' //fileserver.example.com/home: //fileserver.example.com/home/://fileserver.example.com/home://fileserver.example.com/home/:\\fileserver.example.com\home:\\fileserver.example.com\home\:/h'.

But this is indeed reproducible on linux:

$ mkdir -p /tmp/a/b
$ cd /tmp/a/b
$ git status
fatal: not a git repository (or any of the parent directories): .git
$ chmod 000 /tmp/a
$ git status
fatal: failed to stat '/tmp/a/b': Permission denied
$

So for this upstream problem, the GIT_CEILING_DIRECTORIES variable sounds like the exact solution/workaround. But it did not work on windows and not on linux either:

$ for i in /tmp /tmp/a /tmp/a/b; do env GIT_CEILING_DIRECTORIES=$i git status; done
fatal: failed to stat '/tmp/a/b': Permission denied
fatal: failed to stat '/tmp/a/b': Permission denied
fatal: failed to stat '/tmp/a/b': Permission denied
$

---

So I started looking at upstream git, running a bisect from v1.8.2-rc2 (needed a cherry-pick of 1ed2c7b11 to compile) to master, and the change that turned the expected error

fatal: Not a git repository (or any of the parent directories): .git

into

fatal: failed to stat '/tmp/a/b': Permission denied

was commit ce9b8aab5d9a40a84b4868fa890654900ab2d4cc, which changes one argument to get_device_or_die from relative path "." to absolute path dir->buf (e.g "/tmp/a/b"), and get_device_or_die calls stat which fails on the absolute path so the "failed to stat" message is as such accurate.

So the problem is that the GIT_DISCOVERY_ACROSS_FILESYSTEM handling does not consider GIT_CEILING_DIRECTORIES when doing its initial get_device_or_die call.

If I set GIT_DISCOVERY_ACROSS_FILESYSTEM=1 then git status works fine for me on the H: disk (and GIT_CEILING_DIRECTORIES value does not matter).

I am also not sure if this can be fixed, is this something to attempt to report upstream?

[dscho]

I am also not sure if this can be fixed, is this something to attempt to report upstream?

@hlovdal Yes, please send the report to the Git mailing list (send plain-text messages, HTML messages are dropped silently).