Git-credential-manager-for-windows: fatal: Win32Exception encountered (Failed to write credentials)

[philonor]

System: Win 7 Professional
Shell: PowerShell
User: local user, not administrator

Problem Description:
When running git push from powershell, the GUI prompt for entering GitHub credentials appears. I can insert both the credentials and the access token before the sheel reports the following error:

fatal: Win32Exception encountered.
   Failed to write credentials

Error details (git config --global credential.writelog true)

Unbehandelte Ausnahme: System.ObjectDisposedException: Auf eine geschlossene Datei kann nicht zugegriffen werden.
   bei System.IO.__Error.FileNotOpen()
   bei System.IO.FileStream.Flush(Boolean flushToDisk)
   bei System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
   bei Microsoft.Alm.Git.Trace.Microsoft.Alm.Git.ITrace.Flush()
   bei Microsoft.Alm.Cli.ConsoleFunctions.Exit(Program program, Int32 exitcode, String message, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.Program.Exit(Int32 exitcode, String message, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.CommonFunctions.DieMessage(Program program, String message, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.Program.Die(String message, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.CommonFunctions.DieException(Program program, Exception exception, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.Program.Die(Exception exception, String path, Int32 line, String name)
   bei Microsoft.Alm.Cli.Program.Run(String[] args)
   bei Microsoft.Alm.Cli.Program.Main(String[] args)

Please tell me if more information is needed. Thank you.

[philonor]

Running git push from a powershell under admin privileges didn't work either, but running from within a normal cmd then succeeded without prompting for credentials again :question:

[velteyn]

Same problem here:
fatal: ObjectDisposedException encountered.
Impossibile accedere a un file chiuso.

Eccezione non gestita: System.ObjectDisposedException: Impossibile accedere a un file chiuso.
in System.IO.__Error.FileNotOpen()
in System.IO.FileStream.Flush(Boolean flushToDisk)
in System.IO.StreamWriter.Flush(Boolean flushStream, Boolean flushEncoder)
in Microsoft.Alm.Git.Trace.Microsoft.Alm.Git.ITrace.Flush()
in Microsoft.Alm.Cli.ConsoleFunctions.Exit(Program program, Int32 exitcode, String message, String path, Int32 line, String name)
in Microsoft.Alm.Cli.Program.Exit(Int32 exitcode, String message, String path, Int32 line, String name)
in Microsoft.Alm.Cli.CommonFunctions.DieMessage(Program program, String message, String path, Int32 line, String name)
in Microsoft.Alm.Cli.Program.Die(String message, String path, Int32 line, String name)
in Microsoft.Alm.Cli.CommonFunctions.DieException(Program program, Exception exception, String path, Int32 line, String name)
in Microsoft.Alm.Cli.Program.Die(Exception exception, String path, Int32 line, String name)
in Microsoft.Alm.Cli.Program.Run(String[] args)
in Microsoft.Alm.Cli.Program.Main(String[] args)

This happened after I changed the password on our corporate server... Everything disrupted...

[whoisj]

The error usually comes from the current user not having access to the OS provided credential vault. I most often see this on VMs or setups where Git is being run as a user different from the user who logged onto the desktop.

Is either of these situations the case?

[philonor]

@whoisj I checked, but it isn't the case. $env:username is the desktop logon user within powershell I run git from

[whoisj]

@philonor the username is only one part of the story. Since you're using powershell you can get additional information via [Security.Principal.WindowsIdentity]::GetCurrent().

Part of the response should look like:

AuthenticationType : Kerberos
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
...
Owner              : S-1-5-21-2127521184-1604012920-1887927527-11437848
...

In my experience if the Owner value isn't a very long value, then you're in a form of impersonation and thus do not have access to the account's encryption keys - effectively locking you out of the Windows Credential Manager which is where the GCM persists all credentials and tokens.

[philonor]

@whoisj Thanks for the info. The output looks as follows.

AuthenticationType : Kerberos
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
...
Owner              : S-1-5-32-***
User                 : S-1-5-21-1801674531-***
...

As you point out, Owner and User differ. For me the reason seems to be an embedded terminal session within ConEmu. I added an issue at their repository and will keep this updated to document the problem if somebody else runs into it.

[philonor]

Ensuring powershell output of [Security.Principal.WindowsIdentity]::GetCurrent() lists the same ids for Owner and User fixed the problem.

AuthenticationType : Kerberos
ImpersonationLevel : None
IsAuthenticated    : True
IsGuest            : False
IsSystem           : False
IsAnonymous        : False
...
Owner              : S-1-5-21-1801674531-1957994488-***
User               : S-1-5-21-1801674531-1957994488-***
...

Thanks for your help!

[whoisj]

Ensuring powershell output of [Security.Principal.WindowsIdentity]::GetCurrent() lists the same ids for Owner and User fixed the problem.

How did you achieve this? Since I don't know how either, I'm sure several other users will be excited to find a solution. Thanks!

[philonor]

Sorry, I posted the solution in the linked issue of ConEmu as it's rather ConEmu-related.

Follow up:

• ConEmu starts automatically on my machine using a bash script

start "" "C:\Program Files\ConEmu\ConEmu64.exe" -dir %MP%

• The script is run on startup using Windows Task Scheduler
• Although the loaded account is a non-admin account, the Windows Task Scheduler option Run with highest privileges seems to force admin-privileges
• This resulted in ConEmu always spawning terminals with admin priviliges (even when selecting a non-admin console)
• In the ConEmu "Create new console" window, Run as administrator was always checked and greyed out
  
• Deactivating the Run with highest privileges option in Windows Task Scheduler fixed my problem

Your initial guess was correct.

The error usually comes from the current user not having access to the OS provided credential vault. I most often see this on VMs or setups where Git is being run as a user different from the user who logged onto the desktop.

ConEmu is spawning terminals with a principal different from the logon user if badly configured.
Although $env:username (executed within powershell) outputs the logon user, Owner and User details of [Security.Principal.WindowsIdentity]::GetCurrent() differ.
The ConEmu-specific solution is, in short, to not start the ConEmu root process with administrator privileges, but to spawn terminals with admin priviliges only if needed.

In general I'd recommend to check the [Security.Principal.WindowsIdentity]::GetCurrent() output for equal User and Owner ids. When starting the terminal git is run within from a startup script or a Windows Task Scheduler job on logon automatically, it's likely that the two ids are not the same.

Recommended steps:

• Run powershell from windows run (Windows + R)
• git push/pull should work, check the [Security.Principal.WindowsIdentity]::GetCurrent() output, User and Owner ids should be the same
• Run [Security.Principal.WindowsIdentity]::GetCurrent() from a terminal that fails to run git push/pull
• Compare the output with the one from the working powershell terminal
• User and Owner ids should differ

[shawnparslow]

I am using Jenkins to run CI builds on a windows server. We have the latest version of git (2.15) with the git credential manager enabled. There are two aspects to our CI relating to git (1) is git to GitHub Enterprise (via the Jenkins git connector) and (2) is the actual CI jobs that run in headless under the NT AUTHORITY\SYSTEM user which make git calls to clone/push to production deployment repositories. With this (#2)/CI approach I see that any git clone or git push calls (with passwords in the clone commands) triggers the credential manager under the SYSTEM user which results in the same "fatal: Win32Exception encountered", "Failed to write credentials" as others. I see errors in my error log (despite the clone and push working fine) and Event View Applications errors which I assume is due to the SYSTEM user and lack of access to the credential vault in trying to store/fetch credentials it sees. Is there any way to suppress use of credential management in scenarios where you know you wont have access to the credential vault?

[whoisj]

@shawnparslow the next release ought to at least not fault like the current version does. As for configuration options, there's no great ones for the AUTHORITY\SYSTEM user. Suppose we could add an environment variable or something to disable the GCM.