0x80070005 : Access is denied

[KineticTheory]

Brief description of your issue

When I run any winget install command, the result is 0x80070005 : Access is denied.

• Possibly related to Install failed: An internal error occurred with error 0x800700B7 #1097 and 0x800700b7 : Cannot create a file when that file already exists. (Win 11) #1433. Unfortunately, these closed issues don't explain the actual problem or resolution. They only relate that the issue vanished after a series of updates.
• I have also reviewed https://github.com/microsoft/winget-cli/tree/master/doc/troubleshooting
• I have tried uninstalling winget, rebooting, and reinstalling. This did not help.

Steps to reproduce

1. Open powershell
2. Run a winget install command (any package, vim shown here)

$ winget install vim -s winget
Failed in attempting to update the source: winget
Found Vim [vim.vim] Version 9.0.1245
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
An unexpected error occurred while executing the command:
0x80070005 : Access is denied.

3. Notice the failure to update source for winget and the unexpected error.

Expected behavior

I expect that winget will be able to update its own sources and that it can install software.

Note: If I log in as Administrator, I don't see these errors. Everything works normally in an elevated account. This indicates that I might have a permissions issue, but I don't know how to triage further.

Actual behavior

Log file:

WinGet-2023-02-06-13-16-47.466.log

%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json does not exist.

Environment

$ winget info
Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2486
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.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

[Edit] More information as requested from questions below:

$ winget list winget
Failed in attempting to update the source: winget
Name                                    Id                                    Version
-----------------------------------------------------------------------------------------------
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2023.206.1928.961

[denelon]

Can you share the output from winget list winget?

I'm looking to see which version of the "winget" source you have installed.

It's the second entry from my system below:

winget list winget
Name                                     Id                                    Version           Source
--------------------------------------------------------------------------------------------------------
Windows Package Manager Manifest Creator Microsoft.WingetCreate                1.1.2.0           winget
Windows Package Manager Source (winget)  Microsoft.Winget.Source_8wekyb3d8bbwe 2023.206.2136.998

[litbeep]

I'd like to throw my hat into the ring here - I'm experiencing the same error, but only when attempting to uninstall a package. This behavior persists after doing several clean installs on my PC with the latest available Windows 11 Pro ISO straight from MS with all updates installed.

In the past I was able to "winget uninstall" pretty much any package on the system without an issue. Cortana for example. However, when I attempt to do so now, it results in the access denied error, and I have to run terminal as admin in order to process the command. I'm definitely using an Administrator account, and I've tested this in a few VMs without problems, but oddly the issue persists on bare metal.

Here are the results when I run the winget list winget command

Name                                    Id                                    Version
---------------------------------------------------------------------------------------------
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2023.208.834.41

Also, here's the output of running winget --info:

Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.1194
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.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

[denelon]

@litbeep I think you may have been hit by:

• Unable to uninstall a provisioned MSIX package non-elevated #2928

We've merged the fix, but it hasn't been released yet.

[microsoft-github-policy-service]

@KineticTheory this issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 7 days. It will be closed if no further activity occurs within 7 days of this comment.

[teknixstuff]

Still happening with latest winget, but only Microsoft store packages are affected

[zejjnt]

It isn't at all solved though.

[dxman]

I am experiencing the same behavior described in the original post, including the fact that winget is working correctly under my admin-privileged account. The undesired behavior only occurs under my non-admin account.

All winget commands result in the Failed in attempting to update the source: winget message. Commands such as winget list and winget update display the correct output in addition to the error. Commands such as winget install and winget uninstall fail with the 0x80070005 : Access is denied. message.

Worth noting that this was not always the case for me. The problem first arose for me a few months back, after I had already been using winget successfully for months.

Here's my winget list winget output:

winget list winget
Failed in attempting to update the source: winget
Name                                    Id                                    Version           Source
-------------------------------------------------------------------------------------------------------
App Installer                           Microsoft.AppInstaller                1.21.3482.0       winget
Microsoft.UI.Xaml.2.8                   Microsoft.UI.Xaml.2.8                 8.2310.30001.0    winget
Microsoft.UI.Xaml.2.7                   Microsoft.UI.Xaml.2.7                 7.2208.15002.0    winget
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2024.215.2314.757

[gitarian]

I am experiencing the very same issue as @dxman in a non-elevated shell.

The components list (note the diffference in the minor patch numbering of WPMS/winget):

Name                                    ID                                    Version         Quelle
-----------------------------------------------------------------------------------------------------
App-Installer                           Microsoft.AppInstaller                1.21.3482.0     winget
Microsoft.UI.Xaml.2.8                   Microsoft.UI.Xaml.2.8                 8.2310.30001.0  winget
Microsoft.UI.Xaml.2.7                   Microsoft.UI.Xaml.2.7                 7.2208.15002.0  winget
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2024.215.1838.1

[gitarian]

My problem is gone, I could fix it by myself.

Cause: the WinGet folder in the windows temp folder of my non-privileged user had - for whatever reason - admin access rights only.

Fix: deleted this WinGet folder, ran winget source update from an non-elevated shell again. Et voilà, a new WinGet folder with proper permissions has been created and everything is fine again. :-)

[dxman]

Verified that @gitarian 's solution worked for me.

In my case, the offending temp/WinGet folder was the one under my %LOCALAPPDATA% directory, rather than anything under Windows. Somewhat odd that there was a directory owned by Admin under my non-admin user directory.

[pedrohgmacedo]

It isn't at all solved though.

It's not solved. I'm having this problem. On my old computer this worked. @denelon

From git bash:

pedro@nostromo:~$ winget install vim.vim
Found Vim [vim.vim] Version 9.1.0211
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
An unexpected error occurred while executing the command:
0x80070005 : Access is denied.
pedro@nostromo:~$

[zejjnt]

It isn't at all solved though.

It's not solved. I'm having this problem. On my old computer this worked. @denelon

From git bash:

pedro@nostromo:~$ winget install vim.vim
Found Vim [vim.vim] Version 9.1.0211
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
An unexpected error occurred while executing the command:
0x80070005 : Access is denied.
pedro@nostromo:~$

Still the same for me too

[dxman]

Verified that @gitarian 's solution worked for me.

In my case, the offending temp/WinGet folder was the one under my %LOCALAPPDATA% directory, rather than anything under Windows. Somewhat odd that there was a directory owned by Admin under my non-admin user directory.

Just a bit of additional info I've since discovered, to help any future users reading this: I believe my issue was caused by trying to use gsudo to install packages as admin while logged in as my non-admin user. It led to Admin taking ownership of some of the files in my non-root user's AppData. So yeah... don't do that XD

[soerenkoehler]

Verified that @gitarian 's solution worked for me.

In my case, the offending temp/WinGet folder was the one under my %LOCALAPPDATA% directory, rather than anything under Windows. Somewhat odd that there was a directory owned by Admin under my non-admin user directory.

Thanks you both. The exact problem drove me crazy for weeks and I already suspected IT Central to have "tightened the thumb screws" 🙈 As in your case: gsudo may have been the culprit.

[mathias-koch-mesalvo]

Verified that @gitarian 's solution worked for me.

In my case, the offending temp/WinGet folder was the one under my %LOCALAPPDATA% directory, rather than anything under Windows. Somewhat odd that there was a directory owned by Admin under my non-admin user directory.

Incase it might help others: I had the same problem on my machine. It occurred after I uninstalled a package. During the uninstall process I was asked to enter admin password. I did, and I guess then the access rights of %localappdata%\Temp\WinGet were changed.
I doubleclicked the WinGet folder with my unprivileged user, was asked for the admin password for granting access. After that, everything worked again as expected.

[ROBYER1]

My problem is gone, I could fix it by myself.

Cause: the WinGet folder in the windows temp folder of my non-privileged user had - for whatever reason - admin access rights only.

Fix: deleted this WinGet folder, ran winget source update from an non-elevated shell again. Et voilà, a new WinGet folder with proper permissions has been created and everything is fine again. :-)

This fixed the same issue for me today with UnigetUI which wouldn't install via windows store with the same error code 0x80070005. Surprised this hasn't been fixed?