Permission denied creating tar for Apt files

[dcecile]

Based on @joshmgross's latest comment in #133 (comment), here's my use case, same as @evandrocoan #133 (comment)...

caching Apt list and package files in Ubuntu

Example workflow

The Apt step here takes about 35 seconds without caching. I'm hoping the cache will improve that. I'm also not 100% sure about the paths because I haven't been able to test it yet.

      - name: Use Apt lists cache
        uses: actions/cache@v1
        with:
          path: /var/lib/apt/lists
          key: ${{ runner.os }}-apt-lists
      - name: Use Apt packages cache
        uses: actions/cache@v1
        with:
          path: /var/cache/apt
          key: ${{ runner.os }}-apt-packages
      - name: Install Apt dependencies
        run: |
          sudo apt-get update
          sudo apt-get install -y liblua5.1-dev luarocks

Error during post job

Post job cleanup.
/bin/tar -cz -f /home/runner/work/_temp/207e89c2-b0e5-4443-915a-2eafc37bc59b/cache.tgz -C /var/cache/apt .
/bin/tar: ./archives/partial: Cannot open: Permission denied
/bin/tar: ./archives/lock: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
[warning]Tar failed with error: The process '/bin/tar' failed with exit code 2

[smorimoto]

It has nothing to do with the problem itself, but you should think a little more about caching. Downloading and decompressing are also costly. Considering those, is 35 seconds really long? In my opinion, it's not.

[smorimoto]

And the current setup doesn't guarantee that the contents of /var/lib/apt/lists will not be changed.

[dcecile]

Hmm I suppose 35 seconds isn't that long, but I'm not sure what the total Apt time will be if we start installing more packages.

Semaphore (another CI/CD platform) recommends 10 minutes as the maximum time for continuous integration. Any longer, and developers start changing their behaviour to work around the build system.

So depending on what your current times are, I think that saving 30 seconds or 1 minute can help.

[smorimoto]

In my opinion, there is basically no need to run an update. It's probably faster if you don't do it. Also, the package manager is not a build system; it probably won't be slower than you think. (Unless you specify that explicitly.)

[OldhamMade]

I fixed a similar issue by setting the restore target's permissions with chmod -R a+rwx before the caching step. The restore seems to action correctly with this, but it for sure would be better not to have to do this.

This took a 16min build down to 1min, because a full compile step for a utility binary could be skipped; no need to install the language's runtime, clone the remote repo, then build and install the binary.

Saving time matters for GH Actions. Anything that can be done to reduce the time for them to complete, even if it's only a few seconds, can have a big impact.

[AJMansfield]

I was able to at least successfully save a cache of the downloaded .deb packages with this step:

      - name: Cache APT packages
        uses: actions/cache@v2
        with:
          path: |
            /var/cache/apt/archives/**.deb
            !/var/cache/apt/archives/partial
            !/var/cache/apt/archives/lock
          key: ${{ runner.os }}-apt

However, when attempting to restore this cache, the attempt to extract these cached files still results in Cannot open: Permission denied errors for each file:

Received 0 of 85361645 (0.0%), 0.0 MBs/sec
Received 71303168 of 85361645 (83.5%), 34.0 MBs/sec
Received 85361645 of 85361645 (100.0%), 35.8 MBs/sec
Cache Size: ~81 MB (85361645 B)
/bin/tar --use-compress-program zstd -d -xf /home/runner/work/_temp/6cb673f4-802b-4627-a69c-fc30b46f495f/cache.tzst -P -C /home/runner/work/haxe/haxe
/bin/tar: ../../../../../var/cache/apt/archives/autopoint_0.19.8.1-6ubuntu0.3_all.deb: Cannot open: Permission denied
/bin/tar: ../../../../../var/cache/apt/archives/bubblewrap_0.2.1-1ubuntu0.1_amd64.deb: Cannot open: Permission denied
 ⋮
 ⋮ (50 more lines omitted)
 ⋮
/bin/tar: ../../../../../var/cache/apt/archives/x11proto-randr-dev_2018.4-4_all.deb: Cannot open: Permission denied
/bin/tar: ../../../../../var/cache/apt/archives/x11proto-xinerama-dev_2018.4-4_all.deb: Cannot open: Permission denied
/bin/tar: Exiting with failure status due to previous errors
Warning: Tar failed with error: The process '/bin/tar' failed with exit code 2

If we could just have an option for running the /bin/tar command as sudo, that would make this tool significantly easier to use for caching system packages (like those installed by apt).

[chris-martin]

I have a workflow that opens a Nix shell. It has a lot of small dependencies, and it takes about 4 minutes to download them from various Nix binary caches. Seems like it would be faster to restore from github's cache. Is there some reason the restore can't just run as root?

[michaeltryby]

Caching system dependencies installed using apt is a a no brainer when it comes to use cases. If you have to run sudo apt-get install ... stands to reason you need to run sudo tar ... to restore the cache.

This feature would be very useful to a lot of people! 👍

[shonfeder]

I have a workflow that opens a Nix shell. It has a lot of small dependencies, and it takes about 4 minutes to download them from various Nix binary caches. Seems like it would be faster to restore from github's cache. Is there some reason the restore can't just run as root?

Hitting the same problem with the nix store, I found this workaround, which has unblocked us for the moment: https://github.com/WP2Static/wp2static-integration-tests/blob/900fb6e0f8d2c2b8656dfa3d9ac475b66d119806/.github/workflows/test.yml#L40-L49

[github-actions]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[evandrocoan]

Caching system dependencies installed using apt is a a no brainer when it comes to use cases. If you have to run sudo apt-get install ... stands to reason you need to run sudo tar ... to restore the cache.

This feature would be very useful to a lot of people! 👍

[ssbarnea]

I wonder if anyone tried messing the file permissions on the host before caching occurs, so the current user can rewrite the system cache. It is bit of security nightmare but it might work and it would happen only on CI.

[Phantsure]

Caching system dependencies installed using apt is a a no brainer when it comes to use cases. If you have to run sudo apt-get install ... stands to reason you need to run sudo tar ... to restore the cache.

This feature would be very useful to a lot of people! 👍

I feel joshmgross's comment here does reason why we can't use sudo for tar

[Phantsure]

Because of permissions I feel this is not possible. Workaround can be to download binaries in a directory and cache that. While restoring install binaries from that directory. Or you can do what @ssbarnea suggested.

[KyleKing]

FWIW, I saw that this action seems to offer caching for apt installs: https://github.com/awalsh128/cache-apt-pkgs-action. I'm not affiliated and don't know how the action implements caching, but I think it might be of interest here

[l0b0]

FWIW, I saw that this action seems to offer caching for apt installs: https://github.com/awalsh128/cache-apt-pkgs-action.

A quick look at that seems to indicate that it tries to cache the package files after installation, which seems extremely risky. I'd like to simply cache the results of apt-get update (~12s on the ubuntu-22.04 runner) and the actual .deb files downloaded (~9 seconds for libgdal-dev and its dependencies), to speed that up a bit.

[github-actions]

This issue is stale because it has been open for 200 days with no activity. Leave a comment to avoid closing this issue in 5 days.

[evandrocoan]

/bin/tar: ./archives/partial: Cannot open: Permission denied

Everything runs inside a docker. Therefore, there is no reason not to permit it, so we can do what needs to be done.

[booleanbetrayal]

This is also affecting us. Also agree that some sort of sudo|runAsUser flag should be supported for this action.

[zackees]

Also getting hit by this. Don't know why this directly is being hit. It would be awesome to be able to pass args to tar or otherwise ignore files that can't be cached.

The default behavior should be to just skip the files or warn about them. Seems like an easy change.

[Forty-Bot]

With the separate save/restore actions, you can now do something like

- name: Calculate apt sources hash
  id: apt-list
  run: |
    echo -n hash= >> $GITHUB_OUTPUT
    tar -cf - --sort=name /var/lib/apt/lists | sha256sum | cut -f 1 -d ' ' >> $GITHUB_OUTPUT
- name: Restore apt archives
  uses: actions/cache/restore@v3
  with:
    path: apt-archives
    key: ${{ env.ImageOS }}-apt-${{ steps.apt-list.outputs.hash }}
    restore-keys: |
      ${{ env.ImageOS }}-apt-
- name: Install OS dependencies
  run: |
    mkdir -p apt-archives
    sudo cp -a apt-archives /var/cache/apt/archives
    sudo apt-get install -y my-package
    cp -a /var/cache/apt/archives/*.deb apt-archives
- name: Save apt archives
  uses: actions/cache/save@v3
  with:
    path: apt-archives
    key: ${{ env.ImageOS }}-apt-${{ steps.apt-cache.outputs.hash }}

[kenorb]

I've tried to cache /etc/ansible/facts.d folder, but got the permission denied instead:

/usr/bin/tar -xf /home/runner/work/_temp/5b361ac7-c53e-487a-a535-0b733a9facbb/cache.tzst -P -C /home/runner/work/EA31337-classes/EA31337-classes --use-compress-program unzstd
/usr/bin/tar: ../../../../../etc/ansible: Cannot mkdir: Permission denied
/usr/bin/tar: ../../../../../etc/ansible/facts.d: Cannot mkdir: No such file or directory
/usr/bin/tar: ../../../../../etc/ansible: Cannot mkdir: Permission denied

Workflow code:

actions/cache@v4
  with:
    path: /etc/ansible/facts.d

How to fix it?