mirror of
https://github.com/nektos/act.git
synced 2026-04-26 01:15:51 +03:00
[GH-ISSUE #2374] Permission denied error when downloading Java #1091
Labels
No labels
area/action
area/cli
area/docs
area/image
area/runner
area/workflow
backlog
confirmed/not-planned
kind/bug
kind/discussion
kind/external
kind/feature-request
kind/question
meta/duplicate
meta/invalid
meta/need-more-info
meta/resolved
meta/wontfix
meta/workaround
needs-work
pull-request
review/not-planned
size/M
size/XL
size/XXL
stale
stale-exempt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/act#1091
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @just-dev-creator on GitHub (Jun 21, 2024).
Original GitHub issue: https://github.com/nektos/act/issues/2374
Bug report info
Command used with act
Describe issue
When downloading java via the
setup-java@v4action, the step fails with a permission denied error. This is no problem when running the action on GH directly.Link to GitHub repository
https://github.com/just-dev-creator/etb-plugin/
Workflow content
Relevant log output
Additional information
No response
@tholu commented on GitHub (Jul 16, 2024):
Seeing the same problem with Java 17. @just-dev-creator Have you found a solution?
@just-dev-creator commented on GitHub (Jul 24, 2024):
Hi @tholu,
no, sadly not. In my case, I went ahead and debugged my GitHub actions in a seperate branch on GitHub (the way I did it before using act).
I'm sorry that I don't have better news for you at this point.
@NathanDWalsh commented on GitHub (Nov 7, 2024):
Hi, I had a similar issue with Python. Check the permissions on the /opt/hostedtoolcache/Java_Adopt_jdk/ directory (in my case, the /opt/hostedtoolcache/Python/ directory), for me, owner:group was root:root. The workaround I applied was to chown this folder to runner:runneradmin. This served as a workaround as this directory and it's permissions are retained between container instances (/opt/hostedtoolcache/ mounts to a directory in docker-desktop-data.)
@dougdonohoe commented on GitHub (May 7, 2025):
I ran into this issue too, trying to upgrade from Java 17 to Java 21. The issue is related to the use of the Docker volume named
act-toolcache, whichactused to store download tools. My cache had Java 11 and Java 17, and had been around for several months. You can inspect what is in it via:I resolved this issue by deleting the
act-toolcachevolume (to allow it to be recreated fresh using latest images):This will fail if any
actcontainers are hanging around, so you will need to delete those first.As to the root cause? My guess is something changed in one of the tool dependencies for downloading and having an old volume was confusing it.