Standard user cannot use globally installed zipped portable package installed by another user

[Fei1Yang]

Brief description of your issue

When a zipped portable package is installed with --scope machine, only the user installed that package is granted access to the extracted folder. however unlike the parent, it does not have the "Users" group granted.

This resulting standard users cannot use these packages:

PS C:\> & "C:\Program Files\WinGet\Links\rclone.exe"
ResourceUnavailable: Program 'rclone.exe' failed to run: An error occurred trying to start process 'C:\Program Files\WinGet\Links\rclone.exe' with working directory 'C:\'. No application is associated with the specified file for this operation.At line:1 char:1
+ & "C:\Program Files\WinGet\Links\rclone.exe"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~.
PS C:\> Get-ChildItem -Path "C:\Program Files\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.61.1-windows-amd64\"
Get-ChildItem: Access to the path 'C:\Program Files\WinGet\Packages\Rclone.Rclone_Microsoft.Winget.Source_8wekyb3d8bbwe\rclone-v1.61.1-windows-amd64' is denied.

Steps to reproduce

1. Create an administrator account.
2. Login to that account, open the terminal with "Terminal (Admin)" option in Start button context menu.
3. Install a zipped portable package (e.g. winget install --scope machine Rclone.Rclone) in that terminal.
4. Login back to the original account, open another terminal with "Terminal" option in Start button context menu.
5. Run the installed package (e.g. & "C:\Program Files\WinGet\Links\rclone.exe").

Expected behavior

The installed package should run in step 5.

Actual behavior

Got the ResourceUnavailable error instead.

Environment

PS C:\> winget --info
Windows Package Manager (Preview) v1.5.441-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.1265
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.20.441.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled

[yilmazdurmaz]

this workflow distributes any change on user&system variables and anything installed on the PATH will be accessible after that (a system restart also fixes, but not practical).

• Open control panel (or Win+S) then "Edit the system environment variables"
• Click on "Environment Variables" button
• No need to change anything, just click "Ok"
• then click "Ok" again

The reason I gave these steps is for both manually fixing the issue for the moment, and to give an idea what should be done to fix the issue for real.

• These steps will immediately fix the PATH along with other system environment variables changes that are not yet reflected to the user.
• Whatever is triggered in the system by these steps can be traced (I hope) and used to fix this winget-cli issue.

[Fei1Yang]

this workflow distributes any change on user&system variables and anything installed on the PATH will be accessible after that (a system restart also fixes, but not practical).

• Open control panel (or Win+S) then "Edit the system environment variables"
• Click on "Environment Variables" button
• No need to change anything, just click "Ok"
• then click "Ok" again

The reason I gave these steps is for both manually fixing the issue for the moment, and to give an idea what should be done to fix the issue for real.

• These steps will immediately fix the PATH along with other system environment variables changes that are not yet reflected to the user.
• Whatever is triggered in the system by these steps can be traced (I hope) and used to fix this winget-cli issue.

This issue is not about updating environment variables, it's about updating filesystem permissions. I think your problem should be tracked in your original issue.

[yilmazdurmaz]

@Fei1Yang thanks for clarifying info. can you please also update the first post to have a "longer" error message so others will not fall into the same mistake.