Tracking: Permission Errors when restoring and creating cache
See original GitHub issueIssue
Files not created by the local user may fail when restored from the cache as tar preserves file permissions. Permission errors can also occur when the current user does not have permissions to read files when creating the cache. This is likely just a Linux and/or macOS issue (all the reports are Linux)
Reports
- https://github.com/actions/cache/issues/11
- https://github.com/actions/cache/issues/117
- https://github.com/actions/cache/issues/130
- https://github.com/actions/cache/issues/131
Possible solutions
- Run
tar
withsudo
- What are the downsides of this approach?
Issue Analytics
- State:
- Created 4 years ago
- Reactions:17
- Comments:42 (8 by maintainers)
Top Results From Across the Web
"Permission denied" while recovering cached files · Issue #9630
We have jobs failing in Alpakka project quite often because of the "Permission denied" error when recovering cached files.
Read more >Pro Tools Error - Permission Denied (13) While Creating... We ...
The problem is that there are permission issues with the folder being used to create the cache and cloud project information, which means...
Read more >Permission problems on cached files (#1782) - gitlab-runner
I've checked the status of the file after the initial build & they are all set to gitlab-runner so something that the cache...
Read more >Tracking file permissions in Git. Error running git-cache-meta ...
Try this: function get_metadata { git ls-files | xargs stat -c $'%a\t%U\t%G\t%x\t%n' | while IFS=$'\t' read -r perm user grp date name; ...
Read more >Refresh data caches on clients - Azure DevOps - Microsoft Learn
In either case, you must refresh the cache for tracking work items, and users must refresh the version control cache on client computers....
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
~/.cargo
is a symlink for/usr/share/rust/.cargo
, so the chown only changed the owner of the symlink. Appending a/
to the path (sudo chown -R $(whoami):$(id -ng) ~/.cargo/
) does fix it without requiring a cache invalidation.I worked around this using
sudo chown -R $(whoami):$(id -ng) ~/.cargo
to make~/.cargo
owned by the current user.