TIL: Obsidian Git macht unter Windows einfach Windows Authentication

Stand: September 2026

Problem

Beim Start von Obsidian meldet das Plugin Obsidian Git beim ersten automatischen Pull:

remote: Credentials are incorrect or have expired.
Retry your command or see
https://codeberg.org/forgejo/forgejo/issues/2809
for more information
fatal: Authentication failed for
'https://forgejo.example.org/user/repository.git/'

Unmittelbar danach funktionieren jedoch weitere Git-Operationen problemlos:

Pull   → erfolgreich
Commit → erfolgreich
Push   → erfolgreich

Der verwendete Forgejo Personal Access Token bzw. API-Key funktioniert.

Ursache

In diesem Fall lag das Problem nicht am Forgejo-Token, sondern am Git Credential Manager unter Windows.

Für den selbst betriebenen Forgejo-Server war bereits der generische Credential-Provider konfiguriert:

credential.https://forgejo.example.org.provider generic

Der Generic Provider des Git Credential Managers kann unter Windows zusätzlich versuchen, Windows Integrated Authentication zu verwenden.

Dazu gehören insbesondere:

Kerberos
NTLM
Negotiate

Bei einem normalen Forgejo-Zugriff über HTTPS mit Benutzername und Personal Access Token ist diese Authentifizierung jedoch nicht erforderlich (sondern meist sogar eher hinderlich).

Beim ersten Zugriff nach dem Start kam es dadurch offenbar zu einem fehlgeschlagenen Authentifizierungsversuch. Forgejo beantwortete diesen mit HTTP 401 und Git zeigte entsprechend:

Credentials are incorrect or have expired.

Beim folgenden Versuch wurde anschließend die funktionierende PAT-basierte Authentifizierung verwendet.

Diagnose

Obsidian Developer Console öffnen

In Obsidian:

Ctrl + Shift + I

Unter Console war direkt nach dem Start zu sehen:

obsidian-git: Pulling....

obsidian-git: Error: remote: Credentials are incorrect or have expired.
fatal: Authentication failed for
'https://forgejo.example.org/user/repository.git/'

Direkt danach funktionierte ein weiterer Pull und auch ein Push.

Das war ein deutlicher Hinweis darauf, dass die Credentials grundsätzlich gültig waren und nur der erste Authentifizierungsversuch fehlschlug.

---

Git-Credential-Konfiguration prüfen

Im lokalen Repository:

git config --show-origin --get-all credential.helper

Zusätzlich:

git config --show-origin --get-regexp '^credential\.'

Beispiel:

file:C:/Program Files/Git/etc/gitconfig
    credential.helper manager

file:C:/Users/<USER>/.gitconfig
    credential.https://forgejo.example.org.provider generic

Für einen selbst betriebenen Forgejo-Server ist der Provider generic sinnvoll:

git config --global credential.https://forgejo.example.org.provider generic

Lösung

Windows Integrated Authentication für den Forgejo-Host explizit deaktivieren:

git config --global credential.https://forgejo.example.org.allowWindowsAuth false

Anschließend die Konfiguration kontrollieren:

git config --show-origin --get-regexp '^credential\.'

Erwarteter zusätzlicher Eintrag:

credential.https://forgejo.example.org.allowwindowsauth false

Damit versucht der Git Credential Manager für diesen Host nicht mehr, Kerberos, NTLM oder andere Windows-Authentifizierungsmechanismen zu verwenden.

Die normale HTTPS-Authentifizierung mit Personal Access Token bleibt davon unberührt.

Optional: doppelte Credential Helper bereinigen

Bei der Fehlersuche fiel zusätzlich auf, dass credential.helper=manager sowohl in der Git-Systemkonfiguration als auch noch einmal in der Benutzerkonfiguration gesetzt war:

.../Git/etc/gitconfig   credential.helper manager
~/.gitconfig            credential.helper manager

Mehrere Credential Helper sind grundsätzlich zulässig, in diesem Fall aber unnötig.

Die zusätzliche globale Konfiguration kann entfernt werden:

git config --global --unset-all credential.helper

Danach prüfen:

git config --show-origin --get-all credential.helper

Übrig bleiben sollte beispielsweise nur:

file:C:/Program Files/Git/etc/gitconfig    manager

Diese Bereinigung war in diesem Fall jedoch nicht die eigentliche Lösung. Ausschlaggebend war das Deaktivieren von Windows Authentication für den Forgejo-Host.

Funktionstest

Repository-Zugriff testen:

git ls-remote origin

Eine erfolgreiche Ausgabe sieht beispielsweise so aus:

0123456789abcdef...    HEAD
0123456789abcdef...    refs/heads/main

Danach Obsidian vollständig beenden und neu starten.

Der automatische Pull des Obsidian-Git-Plugins funktionierte bei mir danach ohne die vorherige Credential-Fehlermeldung.

Empfohlene Konfiguration

Für einen selbst betriebenen Forgejo-Server unter Windows mit Git Credential Manager und PAT:

git config --global credential.https://forgejo.example.org.provider generic
git config --global credential.https://forgejo.example.org.allowWindowsAuth false

Prüfen:

git config --show-origin --get-regexp '^credential\.'

Beispiel:

credential.https://forgejo.example.org.provider generic
credential.https://forgejo.example.org.allowwindowsauth false

---

Kurzfassung

Wenn Obsidian Git beim ersten Pull nach dem Start meldet, dass die Forgejo-Credentials ungültig oder abgelaufen seien, weitere Pulls und Pushs aber funktionieren, sollte bei Windows insbesondere der Git Credential Manager geprüft werden.

Bei einem selbst betriebenen Forgejo kann das explizite Abschalten von Windows Integrated Authentication das Problem beseitigen:

git config --global credential.https://forgejo.example.org.allowWindowsAuth false

Der Zugriff erfolgt anschließend weiterhin regulär über den im Git Credential Manager gespeicherten Personal Access Token.