Existing issues matching what you're seeing
Git for Windows version
git version 2.53.0.windows.3
cpu: x86_64
built from commit: f8165afd89b0c190677a093f20894f5fce12f97a
sizeof-long: 4
sizeof-size_t: 8
shell-path: D:/git-sdk-64/usr/bin/sh
rust: disabled
feature: fsmonitor--daemon
gettext: enabled
libcurl: 8.18.0
OpenSSL: OpenSSL 3.5.5 27 Jan 2026
zlib: 1.3.1
SHA-1: SHA1_DC
SHA-256: SHA256_BLK
default-ref-format: files
default-hash: sha1
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Microsoft Windows [Version 10.0.26200.8037]
Options set during installation
Editor Option: VisualStudioCode
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: ExternalOpenSSH
Tortoise Option: false
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable FSMonitor: Disabled
Other interesting things
No response
Terminal/shell
PowerShell/GitBash
Commands that trigger the issue
All commands related to remote repo - clone, pull, push etc.
Expected behaviour
I initially expected group membership to be honoured on remote repo, but as that seems to not be the case I opted to set the safe.directory wildcard, at least as a first measure to then further lock things down:
PS C:\development\docker\build\temp>git config get --global --all safe.directory
*
But even with this, no commands against the remote repo works.
Remote:
git remote -v
origin DOMAIN\test_user@server_name:/srv/git/test_repo.git (fetch)
origin DOMAIN\test_user@server_name:/srv/git/test_repo.git (push)
I've read a few discussions about the safe.directory feature, especially #3798, but don't really understand how it improves security in an environment where multiple users are working against the same remote? Isn't the only viable option then to setup a generic user as owner, shared among all users that needs to access the repo, which further obscures the ability to audit security. Why exactly would the current solution be any better than allowing access control through group membership?
A global disable config option that doesn't rely on path resolution would be nice.
Actual behaviour
fatal: detected dubious ownership in repository at '/srv/git/test_repo.git'
To add an exception for this directory, call:
git config --global --add safe.directory /srv/git/test_repo.git
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Repository
Non-public repository.
Existing issues matching what you're seeing
Git for Windows version
Windows version
Windows 11
Windows CPU architecture
x86_64 (64-bit)
Additional Windows version information
Options set during installation
Editor Option: VisualStudioCode Custom Editor Path: Default Branch Option: Path Option: Cmd SSH Option: ExternalOpenSSH Tortoise Option: false CURL Option: WinSSL CRLF Option: CRLFAlways Bash Terminal Option: ConHost Git Pull Behavior Option: Merge Use Credential Manager: Enabled Performance Tweaks FSCache: Enabled Enable Symlinks: Disabled Enable FSMonitor: DisabledOther interesting things
No response
Terminal/shell
PowerShell/GitBash
Commands that trigger the issue
Expected behaviour
I initially expected group membership to be honoured on remote repo, but as that seems to not be the case I opted to set the safe.directory wildcard, at least as a first measure to then further lock things down:
But even with this, no commands against the remote repo works.
Remote:
I've read a few discussions about the safe.directory feature, especially #3798, but don't really understand how it improves security in an environment where multiple users are working against the same remote? Isn't the only viable option then to setup a generic user as owner, shared among all users that needs to access the repo, which further obscures the ability to audit security. Why exactly would the current solution be any better than allowing access control through group membership?
A global disable config option that doesn't rely on path resolution would be nice.
Actual behaviour
Repository
Non-public repository.