Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No permission to access /usr/bin/tar on subsequent deploys #64

Open
Honeybunch opened this issue Jul 28, 2023 · 0 comments
Open

No permission to access /usr/bin/tar on subsequent deploys #64

Honeybunch opened this issue Jul 28, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@Honeybunch
Copy link

Honeybunch commented Jul 28, 2023

Bug description
When deploying to steam from linux the action fails unless run from a fresh environment

How to reproduce

  • Install self-hosted runner in a WSL2 ubuntu environment with action version 1.3.0
  • Deploy a linux build to steam see my deploy action here
  • Trigger another build

Instead I get this log:

Downloading ...
Extracting ...
/usr/bin/tar xz --warning=no-unknown-keyword --overwrite -C steamcmd -f /home/runner/runner0/_work/_temp/steamcmd_linux.tar.gz
/usr/bin/tar: linux32/steamerrorreporter: Cannot open: Permission denied
/usr/bin/tar: linux32/libstdc++.so.6: Cannot open: Permission denied
/usr/bin/tar: linux32/crashhandler.so: Cannot open: Permission denied
/usr/bin/tar: Exiting with failure status due to previous errors
Error: Error: The process '/usr/bin/tar' failed with exit code 2

Expected behavior

The subsequent build succeeds

Additional details

The only workaround for this I have found is to destroy the entire _work directory for the runner and trigger the build & deploy again. Again, any deploy made after a successful deploy will fail due to a permission error with tar; I imagine it's a file locking problem.

I thought this may have been caused by me not having my runners running under a user named "runner" but I have since corrected that since it seems one of the scripts in this action expects that and I'm still running into this problem. Could WSL2 be causing a problem here?

I have another set of runners on the same machine running under windows and they have no problems. I also have an m1 mac mini running a couple self hosted runners and they also have no issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant