@dasniko IIRC, you should be able to query the user if you search by keyword. Not sure if the example allows you to query/merge users from your custom provider.

I'm able to (re) authenticate the user. Perhaps I'm missing some step?

@pedroigor I don't know what's going on in my environment(s)... perhaps I should step out of this feature. 🤷‍♂️

Just wanted to give it another try, but to compile the jpa-user-storage-jpaexample, I need valid 18-SNAPSHOT libs, so I have to compile Keycloak itself first. This again fails - don't know why - with the keycloak-themes module. This happened already in the past, then, after a few days I could compile again, now it's not working again. This is really annoying.
The recently compiled version of the user storage example, is still not working with the latest Keycloak-Nightly Docker image, with the same error/stacktrace mentioned above. This seems really to be problem, like there is some similar Quarkus issue (link is also mentioned above).

As others already have given their positive feedback, I'll trust them and hopefully it'll work with the next release.
Perhaps I will give it another try next week, perhaps I'm just giving up. I really would love to give some better feedback....

I used the quick start as a guide for a provider. Registering the provider works, but when Keycloak attempts use the provider while logging in, that same com.arjuna.ats.arjuna.exceptions.ObjectStoreException: ARJUNA012225: FileSystemStore::setupStore - cannot access root of object store: ObjectStore/ShadowNoFileLockStore/defaultStore/ exception is thrown.

I'm running this on docker image based on quay.io/keycloak/keycloak. Tried versions 17.0.1 and nightly.

If I add USER 0 to my Dockerfile, this exception is not thrown anymore and the provider works as expected. Looks like the USER 1000 does not have access to everything that is needed.

I found a way around the problem. Not sure what is the correct way to actually fix this, but I'll leave that to people who know better.

When using USER 0, it will create the object store to /ObjectStore/ShadowNoFileLockStore/defaultStore. When using USER 1000, it will also attempt to create the object store to that location. Keycloak user cannot write to that location, so I guess this causes the exception.

This can be worked around by adding following lines to Dockerfile:

USER 0
RUN mkdir -p /ObjectStore/ShadowNoFileLockStore/defaultStore && chmod -R g+w /ObjectStore && chown -R keycloak /ObjectStore
USER 1000

Hope this helps to find the solution.

Not sure if we can change our image to use the root user.

While investigating the issue I found this quarkusio/quarkus#2702.

I'm wondering if we should document the issue and the solution in our container guide? Wdyt @andreaTP ?