- This topic has 16 Antworten, 3 Stimmen, and was last updated vor 3 days, 10 hours by
.
-
Beiträge
-
Ich hänge mich hier einmal dran (obwohl ich eine andere Fehlermeldung habe).
Bei mir funktioniert die beA-Anbindung seit dem letzten update auf Serverversion 3.5.0.17 bzw. die Vorgängerversion nicht mehr.
Sie hat zunächst funktioniert; dann habe ich die e-mail-Anbindung neu konfiguriert. Jetzt funktioniert die beA-Anbindung nicht mehr.Das Fenster für das beA-Postfach geht nicht auf. Wenn ich auf „aktualisieren“ klicke kommt „unauthorized“.
Ich habe versucht, in der Benutzerverwaltung das Zertifikt zu speichern. Wenn ich versuche, es zu speichern, „verschwindet“ es ohne Fehlermeldung. Danach kommt „Zertifikatsinformationen können nicht ermittelt werden: beA login failed: <html><head><title>Error</title></head><body>Unauthorized</body></html>“.
Ich habe gemini nach einer Lösung gefragt und über zwei Stunden alles mögliche versucht (u.a. mehrere Änderungen am API-Endpunkt), aber ich komme nicht weiter. Hat noch jemand das Problem?
Wurde die zusätzliche Software installiert?
Wurde in den Einstellungen im Client dieser Schritt ausgeführt?
Bei http://localhost:7080 ? Nein (habe gerade nochmal bei Docker.desktop nachgesehen)
Gibt es hierfür schon eine Lösung? Ich habe das gleiche Problem. Software ist auf dem Server, auf dem auch der j-lawyer-server läuft (Ubuntu). installiert und Container läuft. Anbindung ohne SSL. Fehler ist:
Zertifikatsinformationen können nicht ermittelt werden: beA login failed: {"timestamp":"2026-05-11T11:57:46.994853594Z","status":500,"error":"Internal Server Error","message":"Keystore initialization failed: /opt/beastie/data/beastie-keystore.jks.tmp","path":"/api/v1/auth/login"}Neben der Installation des Docker-Containers ist noch eine Einstellung im Client zu setzen – ist weiter oben bereits verlinkt.
Hatte ich so gemacht (http://localhost:7080, also ohne SSL). Werden die Logs noch benötigt?
Sieht nach einem Berechtigungsproblem aus:
2026-05-11 18:51:45 ERROR c.j.b.api.controller.AuthController - Keystore initialization failed: /opt/beastie/data/beastie-keystore.jks.tmp java.nio.file.AccessDeniedException: /opt/beastie/data/beastie-keystore.jks.tmpDann wären die Schreibrecht auf dem Datenverzeichnis von beAstie anzupassen, damit der Container dort schreiben kann. Evtl. wurde er mal als root gestartet und dann als normaler User.
Ich habe versucht:
docker stop beastie,docker rm beastie,chmod -R 777 /opt. Ich kann dort Verzeichnisse und Dateien anlegen. Es gab KEIN Verzeichnis /opt/beastie. Alle Verzeichnisse angelegt, inklusive /opt/beastie/data/Cache/messages und /opt/beastie/data/KommandosNeuinstallation nach Neustart:
2026-05-13 08:54:41 INFO o.s.v.b.OptionalValidatorFactoryBean - Failed to set up a Bean Validation provider: jakarta.validation.NoProviderFoundException: Unable to create a Configuration, because no Jakarta Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath.(das dürfte unproblematisch sein)2026-05-13 08:54:51 WARN c.j.beastie.service.CommandService - Directory does not exist or is not accessible: /opt/beastie/data/Kommandos(Verzeichnis existiert)2026-05-13 08:56:16 ERROR c.j.b.a.s.MessageFileCacheService - Failed to create message cache directory: /opt/beastie/data/Cache/messages java.nio.file.AccessDeniedException: /opt/beastie/data/CacheAnsonsten beschwert er sich über fehlendes Zertifikat, das sich aber halt nicht installieren lässt (oder soll ich das händisch kopieren?)
Neuinstallation nach Löschen des Verzeichnisses messages unter /opt/beastie/data/Cache/ gibt keine Änderung.
Start des Containers mit root oder sudo würde ich ausschließen. Außer mir ist niemand an dem Rechner.
Ich bin, für den Moment, ratlos.
- Du musst angemeldet sein, um zu diesem Thema eine Antwort verfassen zu können.