unlinkat /workspace/.git: permission denied #92
Comments
|
Please attach a link to a gist of a full log run for this error. Thanks. |
https://gist.github.com/cmoulliard/61f8145698b73339fe7dfddc82456874 |
|
Tried to reproduce on both podman (linux) and docker (linux). Both cases ran, but failed with roughly this error.. Which is odd, because that implied the maven build was successful, but did not produce a quarkus app in the expected packaging format (fast jar). I tried just building locally, and confirmed this, and then realized your sample project pom.xml is incorrect, as it uses maven's compiler plugin, not quarkus's. So the example project isn't a real quarkus project, it merely has some quarkus code in it, and the pom.xml is hand crafted and incomplete. At the very least you need to remove And replace it with And both docker and podman (on linux) create a working image. I cannot recreate the error related to being unable to remove .git, If this still occurs it may be a podman behavior unique to macos |
Be sure that your quarkus java project includes Remark: My project is up to date: https://github.com/redhat-buildpacks/java-buildpack-example/blob/main/pom.xml#L86-L101 |
|
Something odd with github today? I git cloned that project at 09:12 today, and again at 09:44 on a different host .. both resulted in a local directory with a head at commit 5d413ad. Github history says you made commit 338f510 '6 hours ago', which would be like 4 o'clock in the morning.. so I should have ended up with the version above.. |
|
|
|
I suspect https://www.githubstatus.com/incidents/b85tj3x6n4vz may have delayed your commits from being visible when I did the git clone... Regardless... this is feeling like a podman permissions issue on macos. Debugging it may be challenging, as the app volume is always deleted after each build.. to find out why it can't delete it, we need to see the permissions on the workspace dir, and the dirs underneath it that are created in that volume during the build... getting that info is tough, the sanest way to do it is to add in a custom buildpack that dumps the filesystem permissions, and insert it into the order before the maven build.. doing that means building a custom builder etc, which isn't trivial. Could you attempt to build the project using the same builder image, and the pack cli ? if the same error occurs, that would strongly suggest it to be a podman issue. Also, if the error does re-occur with pack cli, we can use it to inject a buildpack to dump the /workspace permissions/ownership. Failing all that, we can customise the library code to dump the app volume ownership/permissions before each phase is executed, but that's also fairly messy. Worth noting that the app dir isn't just mounted into the container, it's copied into a volume, and the volume is used for the build (otherwise the delete source step would erase your local source code). During that copy step, the ownership should be updated from your local user id, to the build uid/gid required by the image. So when looking at ownership & permissions during debugging you should expect to see it under that ownership, not yours. |
|
We can kill the process and access during a few moments the terminal of the container created using the following setup The kaniko except for |
Podman - macosWe got the same error Docker - macosThat works on macos as files under 
|
No.. the owner of /workspace, is root/root (look at ownership for Curiously, the build still worked, because target was created, unless that already existed locally.. which I guess it would because you are driving the buildpack step after the regular build.. try just driving Lets confirm the ephemeral builder image created has correct ownership for /workspace, (there's no reason it shouldn't because the other dirs DO and they are created the same way).. Run a podman build, kill the process before it tidies up and deletes the images/volumes, and launch a container based on the ephemeral builder image.. you will see that created in the log messages coming from the library (at the mo, you don't have any of those, because you don't have an slf4j log impl on your path, add Verify the ownership for /workspace in the ephemeral build container.. if this is cnb/cnb as expected, then we have a podman bug (but we kinda knew that) .. and podman is not respecting the ownership of the mountpoint when mounting the app volume (odd, since kaniko's ownership IS being respected as cnb/cnb) |
|
I added the missing |
I pushed (using podman) on the start button of the ephemeral container created for cnb lifecycle extender and got the same cnb/cnb uid/gid 
If we launch a container using the pakero ubi-builder image, we observe |
|
The paketo ubi-builder image is irrelevant, we don't use that one to create the phase containers, we use the ephemeral builder image, the id of which is logged before each phase execution. We need to see the permissions from a fresh container created from that image. The screenshot is relaunching one of the phase containers, and (I'm guessing) is also remounting the volumes, because /workspace has content under it, which is only ever present in the app volume. Can you try to launch a container based on the ephemeral builder image id and verify the perms of the dirs in root with |
No as the link to the ephemeral image don't exist anymore and/or I got such an error |
|
You'll need to kill off the build once analyze phase is complete, by that point the ephemeral image is created, and you'll skip the tidy up part that deletes it normally |
|
I was able to launch a container with the ephemeral image |
|
FYI. Here is the output of the commands executed using the ephemeral builder image with root or ui/gid = 1500/1500 top of podman |
Issue
Lifecycle can build a java quarkus project but fail due to permission issues
How to reproduce
@BarDweller
The text was updated successfully, but these errors were encountered: