actions/cache "tar: ... Cannot open: No such file or directory" on restore in CI

actions/cache extracts its archive with tar. When the restore target path is missing, the archive was created on a different OS, or the wrong tar (BSD vs GNU) is on PATH, extraction fails with "tar: ... Cannot open: No such file or directory" and the restore aborts.

What this error means

The Restore step prints a tar error such as "tar: <path>: Cannot open: No such file or directory" and "Warning: Failed to restore: ... exit code 2", leaving the cache unrestored.

/usr/bin/tar: ../../home/runner/.cache/pip: Cannot open: No such file or directory
/usr/bin/tar: Error is not recoverable: exiting now
Warning: Failed to restore: "/usr/bin/tar" failed with error: tar exited with code 2

Common causes

The archive was saved on a different OS or path layout

A cache created on one runner OS can hold absolute paths that do not exist when restored on another, so tar cannot create or open them.

A non-GNU tar is first on PATH (often on Windows/macOS)

If a BSD tar or a self-installed tar shadows GNU tar, the flags actions/cache uses behave differently and extraction breaks.

How to fix it

Scope the cache key per OS so archives match the runner

1. Include runner.os in the key so a Linux cache never restores onto Windows.
2. Re-run so each OS restores only its own archive.
3. Confirm the tar error is gone after the OS-scoped key takes effect.

key: cache-${{ runner.os }}-${{ hashFiles('**/lockfile') }}

Ensure GNU tar is used on the runner

On Windows, GitHub-hosted runners provide GNU tar; if you installed another tar, remove it from PATH so actions/cache uses the expected one. On macOS, install GNU tar (gtar) if a custom path is needed and let the action find the system tar.

How to prevent it

• Always scope cache keys by runner.os.
• Do not shadow the runner GNU tar with a third-party tar.
• Keep cached paths relative to the runner home where possible.

Related guides