Skip to content

Spring Boot with native image container image build fails #45233

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

Open
dmikusa opened this issue Apr 18, 2025 · 1 comment
Open

Spring Boot with native image container image build fails #45233

dmikusa opened this issue Apr 18, 2025 · 1 comment
Labels
for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged

Comments

@dmikusa
Copy link

dmikusa commented Apr 18, 2025

Steps to Repro

  1. https://start.spring.io, Spring Boot 3.4.4, Java 21, Gradle. Add deps for native image + spring web. Download. Extract.
  2. Run ./gradlew bootBuildImage.

It will fail with the following error:

    [creator]     Finished generating 'com.example.demo.DemoApplication' in 1m 3s.
    [creator]       Removing bytecode
    [creator]     unable to invoke layer creator
    [creator]     unable to remove /workspace/BOOT-INF
    [creator]     unlinkat /workspace/BOOT-INF: permission denied
    [creator]     ERROR: failed to build: exit status 1

Normally, this is the point where the buildpack would clear out the Java class files and things you no longer need given this is a native image. It should be able to write to /workspace, but obviously cannot given this error.

Usually file permissions are inherited from the contents that are pushed into the build container, which I believe are the Boot JAR contents. I don't know the exact mechanics of how the Boot build tools plugin does this though.

Full build log -> build-log-gradle.txt

This was run on Mac OS Sequoia 15.4, Podman Desktop 1.17.2 (running Podman 5.4.1).

If I run the same build with the latest pack cli on the same system using the same JAR file, it does not have this issue. See build log from pack -> pack-log.txt

Paketo had a similar report where the user had this problem in conjunction with the <applicationDirectory>/myapp</applicationDirectory> option (--workspace with pack cli). I'm able to reproduce that as well, but that does not work with pack cli either. I'm mentioning this in case it does have the same underlying cause.

Thanks

@philwebb
Copy link
Member

I'm unable to replicate the problem locally but I have Docker Desktop. Flagging to see if anyone else on the team has Podman.

@philwebb philwebb added the for: team-attention An issue we'd like other members of the team to review label Apr 18, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
for: team-attention An issue we'd like other members of the team to review status: waiting-for-triage An issue we've not yet triaged
Projects
None yet
Development

No branches or pull requests

3 participants