beA-Container in Docker läuft nicht

Vielen Dank für die schnelle Rückmeldung. Ich bin nun mit dem gesamten System (JL Server und beA Container) auf das Mac Studio umgezogen, beides läuft im Docker-Desktop. Der Mac Studio läuft 24/7. Das beA-Problem habe ich nicht beheben können. Allerdings kommt nun eine andere Fehlermeldung:

Zertifikatsinformationen können nicht ermittelt werden: beA login failed: {„timestamp“:“2026-05-02T09:49:28.116084263Z“,“status“:401,“error“:“Unauthorized“,“message“:“Authentication failed: Cannot invoke \“de.brak.bea.application.dto.soap.types.BeAServicePortType.getConfiguration(de.brak.bea.application.dto.soap.types.GetConfigurationRequest)\“ because \“this.beAPortType\“ is null“,“path“:“/api/v1/auth/login“}

Wie kann ich den Log übersenden? Für das Fenster hier ist er offensichtlich zu lang.

Okay, dann weiß ich Bescheid. Ergänzend noch die Zusammenfassung der von mir mit diesem Thema beschäftigten KI für meine Probleme auf dem NAS und auf dem Mac Studio. Ich wünsche einen schönen Restsonntag.

Fehlerbericht: beA-Anbindung (beAstie) in Docker-Umgebungen (macOS & Ugreen NAS)
Kontext: Migration eines j-lawyer 3.5.x-Systems vom NAS auf Mac Studio (Apple Silicon) und zurück auf ein Ugreen NAS (Intel). Der j-lawyer-Server (Wildfly/MariaDB) läuft stabil, die beA-Anbindung (beastie:latest) scheitert in beiden Umgebungen.

1. Mac Studio (Apple Silicon / arm64)
Problem: Architektur-Inkompatibilität der Krypto-Bibliotheken.

Fehlerbild: Trotz platform: linux/amd64 in der docker-compose.yml schlägt die Initialisierung des SSL-Kontexts fehl.

Ursache: Die eingebundenen Governikus-/BOS-Bremen-Bibliotheken scheinen in der Java-Laufzeitumgebung unter Rosetta 2-Emulation nicht in der Lage zu sein, den PKCS12-KeyStore-Provider korrekt anzusprechen.

Log-Auszug: java.lang.ExceptionInInitializerError gefolgt von failed to create sslContext.

2. Ugreen NAS (Intel x86_64 / UGOS)
Problem: Berechtigungs-Konflikt beim Erstellen der technischen Keystore-Datei.

Fehlerbild: Der Container startet, findet aber die intern benötigte Datei data/beastie-keystore.jks nicht.

Analyse:

Das beAstie-Image versucht beim Initialstart, die beastie-keystore.jks im Datenverzeichnis zu generieren.

Sowohl bei Bind Mounts (direkter Pfad auf das NAS-Dateisystem) als auch bei Named Volumes blockiert das zugrunde liegende Host-OS (UGOS/Linux) den Schreibzugriff für den Container-Nutzer (selbst unter user: root).

Dadurch wird die Datei niemals angelegt, was zu einer permanenten FileNotFoundException führt.

Ein manuelles „Hineinkopieren“ via docker cp wird mit lchown: operation not permitted quittiert.

Downstream-Fehler: In der Folge bleibt this.beAPortType null, was bei jedem Zugriffsversuch des j-lawyer-Servers zu einer NullPointerException führt.

3. Allgemeine Beobachtung (Usability)
Passwort-Mapping: Es gab Unklarheiten bezüglich des Namensschemas der Passwortdatei. Während die Dokumentation oft von .pwd spricht, forderte das Log explizit das doppelte Suffix .p12.pwd an, um das Zertifikat überhaupt zu assoziieren.