Keycloak 17 on container fails to extract theme from jar

Hi,

I’m using Keycloak 17 in a podman rootless container where I add my jar file with our theme. Sometimes it works, but after a while it starts failing with the error:

2022-03-18 18:59:37,260 WARN [org.keycloak.services] (executor-thread-1) KC-SERVICES0075: Failed to get theme request: java.lang.RuntimeException: Temporary directory /opt/keycloak/bin/…/data/tmp does not exist and it was not possible to create it.
at org.keycloak.quarkus.runtime.integration.QuarkusPlatform.getTmpDirectory(QuarkusPlatform.java:153)
at org.keycloak.encoding.GzipResourceEncodingProviderFactory.initCacheDir(GzipResourceEncodingProviderFactory.java:55)
at org.keycloak.encoding.GzipResourceEncodingProviderFactory.create(GzipResourceEncodingProviderFactory.java:26)
at org.keycloak.encoding.GzipResourceEncodingProviderFactory.create(GzipResourceEncodingProviderFactory.java:15)
at org.keycloak.services.DefaultKeycloakSession.getProvider(DefaultKeycloakSession.java:333)
at jdk.internal.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)

Seems like it can’t unzip the theme from the jar file to serve the resources (CSS files and such).
As anyone else experienced this behavior or is it only me / my container environment?
Any idea on how to fix it?

Thanks for any help!

Regards
João

most probably my bad…
was setting the container user to Keycloak which is then not able to write on the /opt/keycloak since its owned by root.
now running the container with root user inside the container it already works fine apparently

(doesn’t quiet explains why sometimes it actually worked)

After some further investigation from the base keycloak 17 container I believe we might have a problem here…
all the /opt/keycloak folder it owned by root, and the default user is keycloak.
Therefor it is not possible to create the data folder which is expected for the theme

I presume the temp directory at /opt/keycloak/data/tmp should be possible to write by the default user.

going a bit further…
Keycloak belongs to the root group and therefor it can write inside most of /opt/keycloak.
What it can’t do is create folders under /opt/keycloak (to create the data directory) since the group root doesn’t have write permissions on the /opt/keycloak itself:

image

Typically, you should build a custom container with the theme instead of relying on the container doing the initial build on the fly. Then you won’t have a problem as the build is done as root.

Like:

FROM keycloak:17
WORKDIR /opt/keycloak
COPY *.jar providers/
ENV <set envs for kec build here>

RUN /opt/keycloak/bin/kc.sh build 

Hi,

Our Dockerfile does what you suggest, and what I believe is suggested from documentation.

FROM Quay as builder

COPY ourTheme.jar /opt/keycloak/providers/ourTheme.jar
COPY ourPlugin*.jar /opt/keycloak/providers/ourPlugins.jar

ENV KC_DB=postgres
ENV …
RUN /opt/keycloak/bin/kc.sh build

FROM Quay

ENV …

COPY --from=builder /opt/keycloak/lib/quarkus/ /opt/keycloak/lib/quarkus/
COPY --from=builder /opt/keycloak/providers/ /opt/keycloak/providers/
WORKDIR /opt/keycloak

ENTRYPOINT ["/opt/keycloak/bin/kc.sh", “start”]

now the problem is that base image has /opt/keycloak not writable by keycloak user, and once the theme tries to unzip some resources to the temporary folder the user can’t create the folder.
Therefor we need to provide some additional permissions to the user on the folder itself.

Also find weird since original Dockerfile seems to create the folder with the right group permissions if I understand it correctly (keycloak/Dockerfile at main · keycloak/keycloak · GitHub)

Yes, so you have to switch to user 0 in your build image and swizch back (maybe even update the permission again)

An alternative is to just use the upstream docker file and adopt it to your needs (so copying the jar files and run build in the builder image.)

with release 17.0.1 this is now solved as /opt/keycloak is owned by keycloak user not root.