ecoDMS 24.01/2 - Archivierung in INBOX nicht mehr möglich

ecoDMS Themen-Foren ecoDMS
1

Hi zusammen,

im Forum (bzw. allgemein im Internet) bin ich leider nicht fündig geworden (oder habe an den falschen Stellen gesucht), daher erstelle ich hierfür mal einen eigenen Thread.

Ich kann nicht mehr zu 100% sagen, seit wann das u.g. Problem auftritt, aber ich bin mir sehr sicher, dass vor dem letzten ecodmsserver-Update auf 24.01/2 noch alles funktioniert hat.

Seit einiger Zeit kann ich Dokumente aus der INBOX nicht mehr per Klick auf „Archivieren“ ins Archiv verschieben. Es passiert einfach… nichts. Der Client tut so, als würde er verschiedene Dinge tun, anschließend wird auch nicht das vorher geöffnete Dokument, sondern ein anderes aus der INBOX aufgerufen, aber die Zahl der Dokumente in der INBOX bleibt gleich und das zu archivierende Dokument ist per Wechsel auf die richtige Dokumenten-Nummer wieder sichtbar, also weiterhin in der INBOX. Es erscheint auch nicht im Archiv. Die Eingabefelder Bemerkung, Status, Ordner und Dokumentenart sind nun grün hinterlegt und die Revision ist „-1“.

In den Logs konnte ich folgende Meldungen sehen:

2024-09-30 20:43:26,915 ERROR |ENGINE-16004 Exception while closing command context: couldn't execute activity <serviceTask id="servicetask2" ...>: org.mapdb.DBException$VolumeIOError 
org.camunda.bpm.engine.impl.pvm.PvmException: couldn't execute activity <serviceTask id="servicetask2" ...>: org.mapdb.DBException$VolumeIOError
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute$2.callback(PvmAtomicOperationActivityExecute.java:65)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute$2.callback(PvmAtomicOperationActivityExecute.java:50)
[...]
Caused by: java.lang.Exception: org.mapdb.DBException$VolumeIOError
        at de.ecodms.workflow.MoveToArchive.execute(MoveToArchive.java:103)
        at org.camunda.bpm.engine.impl.bpmn.delegate.JavaDelegateInvocation.invoke(JavaDelegateInvocation.java:40)
[...]
2024-09-30 20:43:26,922 ERROR |ID:ecodms.lan.DOMAIN.de-46489-1727459196749-4:20:1:1 Exception while processing message: ID:MB2.lan.DOMAIN.de-53439-1727721103197-0:11:1:281:1 
org.camunda.bpm.engine.impl.pvm.PvmException: couldn't execute activity <serviceTask id="servicetask2" ...>: org.mapdb.DBException$VolumeIOError
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute$2.callback(PvmAtomicOperationActivityExecute.java:65)
        at org.camunda.bpm.engine.impl.pvm.runtime.operation.PvmAtomicOperationActivityExecute$2.callback(PvmAtomicOperationActivityExecute.java:50)
[...]
Caused by: java.lang.Exception: org.mapdb.DBException$VolumeIOError
        at de.ecodms.workflow.MoveToArchive.execute(MoveToArchive.java:103)
        at org.camunda.bpm.engine.impl.bpmn.delegate.JavaDelegateInvocation.invoke(JavaDelegateInvocation.java:40)
[...]
2024-09-30 20:43:35,135 ERROR |org.mapdb.DBException$VolumeIOError 
2024-09-30 20:43:35,136 ERROR |org.mapdb.DBException$VolumeIOError 
2024-09-30 20:43:35,136 ERROR |org.mapdb.DBException$VolumeIOError 
2024-09-30 20:43:35,148 ERROR |ENGINE-16006 BPMN Stack Trace:
        servicetask2 (activity-execute, ProcessInstance[1667913])
        servicetask2, name=MoveToArchive
          ^
          |
        ecoICE, name=Inbox

Ein paar Hintergrundinfos zu meiner Umgebung:

  • ecoDMS-Server: Debian 11, 2 vCPU, 10 GB RAM; Version 24.01/2
    • Pakete werden über http://www.ecodms.de/ecodms_240164/bullseye bezogen
    • postgreSQL wurde m.W. automatisch gemeinsam mit ecodmsserver installiert; Datenverzeichnis ist lokal
    • die Ordner /opt/ecodms/{backup,data} sind als CIFS-Share (QNAP-NAS „direkt nebenan“) eingebunden; ob hierfür Shares offiziell unterstützt sind, konnte ich den System Requirements nicht entnehmen. Da es die letzten Jahre aber problemlos funktioniert hat, würde ich die Shares als Ursache zunächst erstmal ausschließen bzw. nach hinten schieben, hier gab es in den letzten Wochen keine Änderungen an den beiden Shares
  • ecoDMS-Client: macOS Sonoma; Version 24.01/2

Ich bin etwas ratlos. Die Fehlermeldungen geben zwar einen Hinweis, aber damit kann ich nicht viel anfangen.

Haben andere dieses Problem auch? Bin ich der einzige? Kann jemand mit den Fehlermeldungen was anfangen bzw. kann einen Tipp für das weitere Troubleshooting geben?

Viele Grüße
Ben

2

Hi,

das ist mir besonders aufgefallen. Das deutet ggf. auf ein Problem oder einen Fehler der Festplatte hin.

3

Ich habe dasselbe Problem. Nur meine Fehlermeldung ist etwas anders. Statt dem

org.mapdb.DBException$VolumeIOError

kommt bei mir nur

null

Das beschriebene Verhalten ist aber exakt gleich.
Hast du bereits eine Lösung gefunden?

4

Hi ihr beiden,

entschuldigt die späte Rückmeldung. Angesichts der Probleme, die ich (lt. Rezensionen bin ich damit beim besten Willen nicht allein) mit ecoDMS immer wieder habe (so auch dieses hier), werde ich wohl nach einer Alternative schauen müssen. Im Moment habe ich v.a. Paperless-ngx im Auge, hier suche ich noch nach einem Migrationspfad.
Wie ich die Tage gelesen habe, verwendet ecoDMS ein proprietäres Format zur Speicherung der PDFs, ergo kann man sich die PDFs wahrscheinlich nicht einfach direkt von der Platte wegkopieren. Aber… das ist ein anderes Thema.

Ich habe tatsächlich bis heute keine Lösung für o.g. Problem gefunden und kann auch weiterhin nichts archivieren. Leider ist in der normalen Privatanwender-Lizenz ja nicht mal Mailsupport im einfachen Rahmen enthalten und eine Knowledge-Base mit allen Problemen der Vergangenheit und deren jeweilige Lösungen (öffentliche GitHub-Issues, Jira-Tickets, o.ä.) gibt es auch nicht - bzw. nur beim Hersteller, der dieses Wissen aber offensichtlich nicht teilen will, sondern lieber unter Verschluss hält.
Ich bin mir fast sicher, dass das Problem nur eine Kleinigkeit ist, die man durch Aktion X oder Befehl Y beheben könnte. Aber so „gut“, wie die ecoDMS-CLI-Tools allgemein dokumentiert sind, mach ich mir da keine Hoffnung, hierzu etwas zu finden.

Zum Thema VolumeIOError und der Vermutung, es könnte ein Problem/ein Fehler mit der Festplatte sein: in CheckMK habe ich ad hoc keinen Anhaltspunkt hierfür finden können. Diese Meldung ist mir damals auch direkt ins Auge gesprungen, jedoch findet Google (bei einer exakten Suche in Anführungszeichen) nicht mal 2 Seiten voll Websites zu dieser Fehlermeldung. Die, die ich dazu angeschaut habe, waren nicht wirklich hilfreich.
Ich muss dazu sagen, dass der data- und backup-Ordner bei mir beide auf einem gemounteten NAS-Share liegen. In den ecoDMS-Specs steht nur, dass das DB-Verzeichnis auf keinen Fall auf einem Share liegen darf, sonst nichts. Die Shares waren bisher aber allgemein kein Problem, daher würde es mich wundern, wenn dem nun plötzlich so wäre.

@ploetman Hast du für dein ähnliches Problem in der Zwischenzeit eine Lösung gefunden?

5

Für eine GoBD-konforme Archivierungslösung wäre das auch ziemlich ungünstig, wenn das gehen würde.

Ich verstehe Deine Sichtweise. In Anbetracht des Lizenzpreises kann ich jedoch auch verstehe, dass man seitens ecoDMS hier keinen kostenfreien Support anbietet.

Nun ja, also hier Fehlerbehebungsartikel - Wissensdatenbank gibt es schon dokumentierte Lösungen und Hinweise. Aber ja, von soetwas kann es nicht genug geben. U.a. deswegen habe ich ja auch ecoDMS als Forenbereich mit aufgenommen, dass wir hier Wissen und Lösungen sammeln können. :slight_smile: