Tobias Teichmann
Erstellte Forenantworten
-
Beiträge
-
Nochmals vielen Dank für die Hilfe. Ich habe es gerade glücklicherweise dank des obigen Tipps zu den Berechtigungen doch noch auf dem NAS zum Laufen gebracht. Das war der Türöffner bei mir:
sudo docker exec -u root beastie chown -R 999:999 /opt/beastie
sudo docker restart beastieJetzt bin ich echt glücklich 🙂
Vielen Dank für den Input und die Hilfe. Das hat bei mir leider ebenfalls nicht zum Erfolg geführt. Weder auf dem NAS (JL-Server und beAstie als Container in Docker) noch auf dem Mac Studio (JL-Server und beAstie als Container in Docker Desktop) habe ich beA mit diesem Tipp zum Laufen gebracht.
KI: „Nach umfangreichen Tests auf Intel-NAS (UGOS) und Mac Studio (M4) scheitert beAstie konsistent an der Initialisierung des Keystores (FileNotFound oder Tag number over 30), selbst wenn Volumes als Named Volumes angelegt, Zertifikate via legacy-Export umgewandelt und Berechtigungen auf ID 999 gesetzt wurden. Es scheint ein fundamentales Problem mit dem Dateizugriff auf die intern generierte .jks-Datei in nicht-nativen Linux-Umgebungen zu geben.“
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.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.
