While in SSH, running WinGet raises the ResourceUnavailable error.

[asifmohtesham]

Brief description of your issue

While in Windows 10 Pro using SSH, running WinGet raises an error stating that the file cannot be accessed by the system. Otherwise (without SSH), the command runs just fine.

Steps to reproduce

1. Start an SSH using an administrator's credentials
2. Run WinGet

Expected behavior

Should be execute and be accessible by the system as we usually would without using SSH.

Actual behavior

ResourceUnavailable: Program 'winget.exe' failed to run: The file cannot be accessed by the system.

Environment

[winget --info]
Windows Package Manager v0.1.41821 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19041.388
Package: Microsoft.DesktopAppInstaller v1.0.41821.0

Any other software?

[belveruski]

Same problem.

Windows 10 Pro, 2004 Build 19041
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5

[bbqsrc]

This is still happening.

[JohnMcPMS]

I suspect that this is due to the App Execution Alias that is used to expose winget.exe from a UWP package. I don't know though if the issue is that SSH is doing something beyond CreateProcess and is not happy with the stub file, or if you are trying to SSH into another session/machine/user that does not have the package registered.

Generally the resolution to this falls into the category of requesting a different distribution mechanism, ie an unpackaged exe or msi to install the package manager from.

[bbqsrc]

The user I ssh into is the user that installed winget in the first place. 😄

I am happy with any installation mechanism, so the moment that is possible, let me know and I can test if it resolves this issue.

[peter-dolkens]

I believe this is actually an issue in OpenSSH:

PowerShell/Win32-OpenSSH#1632

[denelon]

I'll keep this Issue open so we can track the PowerShell Issue to see if that resolves this problem.

[ghost]

@asifmohtesham @denelon

all SSH logins are connected into windows against NT AUTHORITY\Network .
running store apps (in this case winget) requires connecting into windows againt NT AUTHORITY\Interactive aka GUI and hence they can not be run from SSH logins aka NT AUTHORITY\Network.

AFAIK, this is by design behavior and can only be changed if winget team separates winget from appInstaller or from store.

[chrisbrasington]

@asifmohtesham @denelon

all SSH logins are connected into windows against NT AUTHORITY\Network .
running store apps (in this case winget) requires connecting into windows againt NT AUTHORITY\Interactive aka GUI and hence they can not be run from SSH logins aka NT AUTHORITY\Network.

AFAIK, this is by design behavior and can only be changed if winget team separates winget from appInstaller or from store.

Thanks for the explanation. Unfortunately the main reason I installed winget was to be able to run it remotely.

[petervk]

Is there any way to get this to work? I would love to be able to SSH into my other windows machines to run winget to update them.

[ghost]

running store apps (in this case winget) requires connecting into windows againt NT AUTHORITY\Interactive aka GUI and hence they can not be run from SSH logins aka NT AUTHORITY\Network.

AFAIK, this is by design behavior and can only be changed if winget team separates winget from appInstaller or from store.

Correction :

running store apps means previously the windows 10 store apps, which required apps to be MSIX packaged to be in store. NT Authority\Interactive aka GUI means you are logged in either locally or through RDP. it's MSIX packages requirements which require Users Interactive/GUI/RDP login into windows, otherwise those apps refuse to run at all, that's the reason MSIX packaged apps can't be run as admin in local logins too because MSIX doesn't also support all users install.

Nothing to do with store or Winget or AppInstaller. MSIX packaging requirement is the culprit. MSIX is this much crap, only supports per user install , no ssh, no winRM , no all users install/uninstall, no running under system account , no drivers supports etcs and so on.
The Only solution is Winget completely ditching MSIX and embracing MSI format until MSIX becomes less crap.

Note : This MSIX packaging crap derivates from APPX format which was the app packaging format of another disaster app model known as UWP apps. this crap format has been from there from 2018 yet None of Microsoft's own heavy duty apps use this MSIX crap, example- VS Code , Visual Studio , Microsoft Edge (chromium), Office, Teams ; all of them use MSI or traditional EXE format.

Ref :
Doesn't run under WinRM.
Can't run winget as a admin.
Add per-machine storage support to MSIX.
Machine Wide Provisioning (Install for All Users.)
Support Usage with System Account.

[Masamune3210]

Im not sure what you are trying to accomplish complaining about MSIX here....

[ghost]

Im not sure what you are trying to accomplish complaining about MSIX here....

point 0 : don't expect me to get into a sort of debate because I won't. but he defense needs to understand some logistics.
point 1 : "accomplishing" and "complaining" is a contradictory term. No one "accomplishes" ANYTHING in real life with "complaining."
point 2 : was a correction comment that's the reason for commenting in the first place+nothing there is my own subjective feelings rather IT IS FACTS with several references to look at.

[denelon]

I believe this issue is fully external, and there is a bug tracking this at PowerShell/Win32-OpenSSH#1632 be sure to add your 👍 to help raise priority.