Paperless Bugfix Office-Dokumente importieren

Hier ist der Paperless Bugfix Office-Dokumente importieren. Das war viel Aufwand, um den Fehler zu finden, hier die Lösung 👍

Es ist eigentlich ein wahnwitziger Fehler 😂 – einer von der Sorte, bei dem man sich nach einer Weile schon die Axt neben den Computer legt und immer wieder einen Blick darauf wirft: „Soll ich… oder soll ich nicht?“

📒 Weitere Artikel dieser Beitragsserie:

Rechts oben, unter „Newsletter abonnieren“, findest du das Suchfeld!
Gib „Paperless“ ein und drücke die [ENTER/EINGABE]-Taste, um alle Paperless-Artikel anzuzeigen.

Aber gut, zurück zum Thema.

Dieser Beitrag bezieht sich auf Docker Desktop für Windows unter WSL, kann aber von der Lösung her auch auf andere Systeme übertragen werden.

Beim Import von Office-Dokumenten bricht der Vorgang ab. Eine mögliche Fehlermeldung sieht zum Beispiel so aus:

PL - File - Thai - mythische Herrscher aus dem All WORD ohne Bild.docx: Error occurred while consuming document PL - File - Thai - mythische Herrscher aus dem All WORD ohne Bild.docx: Could not parse /tmp/paperless/paperless-ngx83t8lopn/PL - File - Thai - mythische Herrscher aus dem All WORD ohne Bild.docx with tika server at http://localhost:9998: [Errno 111] Connection refused

Die Lösungsvorschläge aus KI und Internet ähneln sich alle und beschränken sich darauf, die externen Anwendungen Tika und Gutenberg richtig anzupassen bzw. zu konfigurieren.

Da gibt es Versionen, die nur mit der Version von Paperless x.x.x laufen, und welche, die gar nicht funktionieren. Die gar nicht funktionieren, ja ist OK, lassen wir so stehen.

api-timeout einstellen
PAPERLESS_GOTENBERG_URL: http://gotenberg:3000
PAPERLESS_USE_GOTENBERG: "true"
PAPERLESS_TIKA_URL: "http://tika:9998"

und so weiter, hilft aber alles nichts.

Nun, wie gesagt: Entweder du hast ein System, das funktioniert – oder eins, das nicht funktioniert. Also wo liegt der Unterschied?

Die Parameter in der docker-compose haben darauf keinen Einfluss. Das kann ich schon einmal klarstellen: Die muss man nicht ändern.

Beim Vergleich der docker-compose.yml vom Produktivsystem (funktioniert) und der docker-compose.yml für Entwicklung und Schulung (funktioniert nicht) war das Problem schnell gefunden:

• Das Produktivsystem läuft mit Containern von docker.io.
• Das zweite System nutzt Container-Images von Alpine 😳

Lösung 1: Tausche die Container-Images wie folgt aus:

# Das "redis Image 
redis:
  image: redis:6-alpine

# gegen
redis
  image: docker.io/library/redis:7

# Das Gutenberg Image
gotenberg:
  image: gotenberg/gotenberg:latest

# gegen 
gotenberg:
  image: docker.io/gotenberg/gotenberg:8.6.0

Und das war es:

docker-compose down
docker-compose up -d

und der Laden sollte laufen.

Die Datenbank:

dbpg:
  image: postgres:15-alpine

auf keinen Fall ändern, auch wenn es ein Alpine Image ist. Das ganze hier ist kein Datenbankproblem! Wenn du aber gerade am einrichten bist verwende das Image von docker.io

image: docker.io/library/postgres:16

Wenn du das Datenbank Image austauscht, und sich Daten in der Datenbank befinden, ist die Datenbank nicht mehr lauffähig. Um die Datenbank Umzustellen must du sie umziehen:

Sichern
Löschen
Neue Datenbank installieren
Sicherung wider einspielen

das lass sein, die Datenbank läuft zuverlässig, du hast keinen Handlungsbedarf.

Lösung 2: Firewall

In einer Diskussion auf GitHub, bei der ich nicht sicher sagen kann, ob die Images – wie oben beschrieben – getauscht wurden oder nicht, gehe ich davon aus, dass die Images nicht gewechselt, sondern weiterhin auf Alpine-Basis betrieben wurden.

Jedenfalls konnte festgestellt werden, dass die Ports:

Gotenberg: 3000
Tika: 9998

von der Firewall blockiert wurden. Das könnte den Unterschied in der Funktionalität der verschiedenen Docker-Images erklären.

Gib die genannten Ports in der Firewall frei und starte Paperless anschließend neu.

---

---

#Paperless #PaperlessImport #OfficeImport #DMS #DigitalesBuero #DokumentenVerwaltung #Fehlerbehebung #Bugfix