cache: Tracking: Permission Errors when restoring and creating cache

lrwxrwxrwx 1 runner docker 22 Mar 13 15:33 /home/runner/.cargo -> /usr/share/rust/.cargo

~/.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.

So what’s the “correct” solution to this? I see all these commits saying that they’re removing workarounds, but we’re still experiencing this exact problem after our action moves some temp files (created as -rw------- by default) into our cache folder. Are we supposed to make our action run as another user (and if so, which and how?)? Is there extra config needed to make this action run as root? Should we give up and micro-manage permissions in the cache (that seems like the very workaround that those projects removed)?

Might as well paste in all the links in case someome reads this...

• Failed run of actions/cache: https://github.com/KSP-CKAN/NetKAN/runs/1758832548
• Workflow: https://github.com/KSP-CKAN/NetKAN/blob/master/.github/workflows/inflate.yml
• Our action: https://github.com/KSP-CKAN/xKAN-meta_testing/blob/master/action.yml
• Our container: https://github.com/KSP-CKAN/CKAN/blob/master/Dockerfile.metadata

I’m hitting this as well while trying to cache buildkit state exported from the /var/lib/docker dir of a buildx builder. Many files and directories are only readable by root, was a solution for people facing this problem in a context other than cargo actually found before this was closed?

For Rust projects the permissions issue was fixed (see https://github.com/actions/virtual-environments/issues/572#issuecomment-626624527) for Ubuntu. There still a problem with tar on Windows

On Windows, the issue is different and i don’t think that it is image issue. actions/cache uses tar to pack and unpack files and tar doesn’t work properly with symlinks on Windows.

Works for me on Linux. The Windows run has worked too, restoring from an ante-fix cache.

A cache where root is still owner got used. I think tar sets the owner before trying to set time and permissions, so those fail. If you invalidate the cache, for example by changing the cache key, it should work.

Any updates on this? I also run into errors on cargo registry related cache (on rust)

We’re having the following problems in https://github.com/OpenEthereum/open-ethereum/pull/11528 this is a rust project and caching artifacts works properly only on macOS, on linux we get https://github.com/OpenEthereum/open-ethereum/runs/474579803#step:5:7

/bin/tar: ./src/github.com-1ecc6299db9ec823/rand_chacha-0.2.1/src: Cannot utime: Operation not permitted

and on windows https://github.com/OpenEthereum/open-ethereum/pull/11528/checks?check_run_id=474579823#step:5:7

./index/github.com-1ecc6299db9ec823/.git/objects/pack/pack-a1b8e2d02676504008fea86ca360367fcee5bd43.idx: Can’t unlink already-existing object

Files created by container actions, however, will likely be created by the root user.

I was running into this, where caching had been working fine on the main Linux host, but simply moving the workflow into a container caused the cache saving step to fail with the following:

Post actions/cache@v1 ##[error]The template is not valid. Access to the path ‘[some unrelated path]’ is denied.,Permission denied

The path reported was consistent, but had nothing to do with the cache path. (It may have corresponded to the first entry of ls -R from the repository root, but I’m not exactly sure.)

---

I was able to work around it by running chmod -R a+rwx . as the very last thing happening in the container. That grants (absolutely all) privileges back to the host’s user, so that the cache action can access whatever it needs.

Note that simply enabling permissions for the path to be cached was not sufficient. I tired of experimenting before I could figure out exactly which permissions were and weren’t needed. I leave that exercise to someone else if their use case necessitates tighter security.

Is it possible that the Ubuntu instances provided by GitHub Actions are running on Docker?

No, they’re individual Ubuntu VMs, see Docs: Cloud hosts for GitHub-hosted runners.

Files created by container actions, however, will likely be created by the root user.

@joshmgross we’re seeing the issue at tauri-apps/tauri as well (also cargo-related): https://github.com/tauri-apps/tauri/pull/237/checks?check_run_id=364927646#step:7:9

@joshmgross I’m facing the same with gradle on all of Android projects (configured to run on Linux) Gradle wrapper doesn’t restore itself from cache. I’ll be able to add sample Inn a couple of hours.

I don’t think this is an accurate description of the issue.

Great point, I missed that difference. I’ve updated the issue title and description to cover both restore and creation.

This is why I’m surprised it’s not an issue on Windows.

It’s likely that the user account provisioned for hosted Windows runners has the necessary admin privileges, whereas Linux/macOS require sudo

Files not created by the local user may fail when restored from the cache as tar preserves file permissions.

I don’t think this is an accurate description of the issue. If you look at my issue, it has this snippet:

/bin/tar: ./overlay2: Cannot open: Permission denied
/bin/tar: ./builder: Cannot open: Permission denied
...
/bin/tar: Exiting with failure status due to previous errors

This is when the tar file is being created, not when it is being unpacked; the problem comes because the current user does not have permissions to read files owned by root, separate from anything tar does. This is why I’m surprised it’s not an issue on Windows.