Paperless-ngx in Docker

igomyway · September 28, 2025 at 6:02 PM

Ich greife das Thema erneut, oder wieder, auf. Die 2800er hatte ich erfolgreich geflasht und daher alles auf null. Meine aktuelle Lage beschreibe ich folgend (würde mich schon freuen über eine „rege“ Teilnahme ). Fragt aber antworten kann schon mal dauern (Dienstag 2te OP angesagt. Der „Durchblick“ ist dann eingeschränkt im warsten Sinne).

Zum Thema: Paperless-ngx installiert (Portainer/Docker), Anleitung von „der-hier-nicht-verlinkt-werden-darf“ genommen. Dortige Ordnerstruktur auf dem NAS angelegt, die YAML angepasst, Stack erstellt, Container laufen. Login in die GUI funktioniert, alles zuverlässig.

Auf der GUI zum Testen angelegt:

Korrespondent: Amazon (Regex-Muster für verschiedene Schreibweisen)
Tags: Amazon, Bestellbestätigung, Gutschrift, Rechnung
Speicherpfad: Amazon Archiv → /volume2/archiv/Amazon
Arbeitsablauf: aktiv, Auslöser: Dokument aktualisiert (Korrespondent Amazon), Aktion: Titelzuweisung nach Schema {{ created_year }}.{{ created_month }}.{{ created_day }}_Amazon_Rechnung, Speicherpfad: Amazon Archiv.

Testdokumente (PDFs) sowohl manuell als auch per Scanner in den consume-Ordner gelegt → Paperless holt ab, verarbeitet, zeigt sie in der GUI korrekt mit Korrespondent/Tags.

Problem: Die Dokumente landen weiterhin im Standard-Media-Ordner auf Volume1 (NVMe) unter /volume1/docker/paperlessngx/media/documents. Der angegebene Speicherpfad /volume2/archiv/Amazon wird nicht genutzt.

Zusatzinfos:

Aktuell nutze ich keine Jinja-Erweiterung. Falls das zwingend notwendig wäre, müsste ich das nachziehen.
Ich benötige keine Unterordner (z. B. Jahreszahlen). Eine einfache Ablage im Archivordner reicht mir, Volltextsuche genügt. Das betrifft momentan Amazon – bei anderen Korrespondenten könnte es wieder anders aussehen.
Falls relevant: Ich kann gerne meine verwendete YAML posten (wichtige Stellen natürlich geschwärzt).

Tommes · September 28, 2025 at 6:15 PM

Quote from wegomyway

Aktuell nutze ich keine Jinja-Erweiterung.

~~Nichts für ungut, aber allein aus diesem Grund würde ich an deiner Stelle besser einen eigenen Thread aufmachen, weil es hier ja primär um Jinja Filter geht.~~

EDIT sagt: Das Thema wurde zwischenzeitlich in einen eigenen Thread verschoben

Quote from wegomyway

Problem: Die Dokumente landen weiterhin im Standard-Media-Ordner auf Volume1 (NVMe) unter /volume1/docker/paperlessngx/media/documents. Der angegebene Speicherpfad /volume2/archiv/Amazon wird nicht genutzt.

Vermutlich musst du dich entscheiden, ob du entweder den kompletten Ordner ../media nach /volume2 verschieben möchtest, oder ob nur z.B. nur ../media/documents/originals oder ../media/documents/archive verschieben möchtest. Ich habe es bei mir z.B. so angegeben…

Code

- /volume2/Dokumente/Aktenarchiv:/usr/src/paperless/media/documents/originals:rw

… wobei mir die Originalen PDF-Dateien wichtiger sind als sie archivierten bzw. OCR‘ten

Quote from wegomyway

Speicherpfad: Amazon Archiv → /volume2/archiv/Amazon

Der Speicherpfad innerhalb einer Regel ist immer relativ nicht absolut. Richtig wäre also /Amazon und nicht /volume2/archiv/Amazon

Quote from wegomyway

Arbeitsablauf: aktiv, Auslöser: Dokument aktualisiert (Korrespondent Amazon), Aktion: Titelzuweisung nach Schema {{ created_year }}.{{ created_month }}.{{ created_day }}_Amazon_Rechnung, Speicherpfad: Amazon Archiv.

Mal davon abgesehen, das ich eigentlich keine Arbeitsabläufe konfiguriert habe, würde ich dir empfehlen, den Punkt in der Datumsangabe durch einen Bindestrich zu ersetzten, da nach dem Punkt im Dateinamen i.d.R. die Dateierweiterung folgt.

igomyway · September 30, 2025 at 10:29 AM

Tommes, hab mir das mal alles durchgelesen. Noch nicht alles umgesetzt (siehe Degradierung NVMe und das Theater der WD HDDs). Am Rande erwähnt, ich denke echt darüber nach paperless mal auf die 224+ zu installieren (trotz synOCR). Reine Neugier um zu sehen was ist dort anders (ja klar nur das Volume1 mit den WD HDDs als RAID1 und als 8 TB). Trotzdem und gerade deshalb, weil man schon Zeit investiert hat in die 2800er soll und wird paperless auf der DXP raufkommen.

Tommes · September 30, 2025 at 4:51 PM

Ganz wie du magst. Nur macht es in meinen Augen keinen Unterschied, ob du Paperless-ngx auf einer DS oder auf einer DXP einrichtest. Das Ergebnis wird das Gleiche sein, zumal es hier ja erstmal nur um die Definition der Speicherpfade...

Code

     volumes:
      - /volume1/docker/paperless-ngx/data:/usr/src/paperless/data:rw
      - /volume1/docker/paperless-ngx/media:/usr/src/paperless/media:rw
      - /volume1/docker/paperless-ngx/export:/usr/src/paperless/export:rw
      - /volume1/docker/paperless-ngx/consume:/usr/src/paperless/consume:rw

... geht und ob du einige davon umbiegen möchtest oder nicht. Alles andere läuft dann ja eh über die WebUI von Paperless-ngx. Aber gut... ich will dir da nicht reinreden. In meinen Augen machst du dir das Leben nur unnötig schwer.

Ich habe bei mir z.B. den Ordner /usr/src/paperless/consume sowie den Ordner /usr/src/paperless/media/documents/originals umgebogen, was am Ende bei mir so aussieht...

Code

    volumes:
      - /volume1/docker/paperless-ngx/data:/usr/src/paperless/data:rw
      - /volume1/docker/paperless-ngx/media:/usr/src/paperless/media:rw
      - /volume1/docker/paperless-ngx/export:/usr/src/paperless/export:rw
      # - /volume1/docker/paperless-ngx/consume:/usr/src/paperless/consume:rw
      - /volume2/Dokumente/Aktenarchiv/Posteingang:/usr/src/paperless/consume:rw
      - /volume2/Dokumente/Aktenarchiv:/usr/src/paperless/media/documents/originals:rw

Mein Dokumentenscanner legt eingescannte Dokumente zunächst unter /volume2/Dokumente/Scaneingang/Brother_ADS1800W ab. Wenn ich mit dem Ergebnis des Scans zufrieden bin, verschiebe ich diese in den Ordner /volume2/Dokumente/Aktenarchiv/Posteingang wo sie dann durch Paperless-ngx konsumiert werden. Abgelegt werden die originalen PDF-Dokumente dann unter /volume2/Dokumente/Aktenarchiv, ergänzt durch den definierten Speicherort, der sich aus Speicherpfad, Korrespondent und Dokumenttyp zusammensetzt. Wie in einem anderen Thread bereits als Beispiel gezeigt:

/volume2/Dokumente/Aktenarchiv [ volumes: (definierter "originals" Pfad im YAML- bzw. Docker-Compose-File ]
- Versicherungen [ Speicherpfad: Versicherungen/ ]
  - Allianz_Berufsunfaehigkeitsversicherung {{ correspondent }}
    - 2025-07-23_Allianz_BU_12345678_Beitragsrechnung.pdf {{ created_year }}-{{ created_month }}-{{ created_day }}_{{ document_type }}_{{ title }}

Aber wie gesagt... tu was du für richtig hälst. Falls du Fragen hast, dann frag, ansonsten wünsche ich dir viel Erfolg bei deinem Vorhaben. Wann auch immer und auf welchem System auch immer.

Tommes

blackh0le · October 2, 2025 at 9:30 PM

Ich werfe hier mal eine neue Frage zum Thema rein

Nachdem ich das Scannen zu SMB nun endlich zum laufen gebraucht habe, macht sich nun ein Problem beim Paperless Docker breit.

Zur Grundlage habe ich hauptsächlich die Anleitung / Datei von Willi paperless.yaml (Variante ohne MacVlan) verwendet. In der offiziellen paperless yaml wurde die tage die DB zu Postgres 18 geändert. Scheinbar beißt sich da nun etwas mit neuen Pfaden oder so.

Im Log der DB steht nur noch mkdir: cannot create directory ‘/var/lib/postgresql’: Permission denied

Dachte nur, wenn es schon in der offiziellen Doku geändert wurde, dann muss man später nicht die DB upgraden und so… Das ist alles noch recht neu für mich

blackh0le · October 3, 2025 at 11:42 AM

Quote from blackh0le

Ich werfe hier mal eine neue Frage zum Thema rein
Nachdem ich das Scannen zu SMB nun endlich zum laufen gebraucht habe, macht sich nun ein Problem beim Paperless Docker breit.
Zur Grundlage habe ich hauptsächlich die Anleitung / Datei von Willi paperless.yaml (Variante ohne MacVlan) verwendet. In der offiziellen paperless yaml wurde die tage die DB zu Postgres 18 geändert. Scheinbar beißt sich da nun etwas mit neuen Pfaden oder so.
...

Nach mehreren Tests, würde ich das Problem auf Rechte bezüglich Docker zugriff auf die Freigegeben Ordner verorten. Beim Stack erstellt über Portainer läuft alles. Die neue Struktur "/18/docker/" wird unter "db" angelegt. Startet man den Stack dann neu, kann Postgres plötzlich nichts mehr machen in "db" und in den Logs steht das oben aufgeführte.

Werde das ganz mit Postgres 17 erst mal betreiben, da ich gesehen habe das die Version 18 sehr sehr frisch aus dem letzen Monat erst ist. Es wird später bestimmt Wege zum Upgrade geben.

Sparkling-Art-1626 · October 3, 2025 at 11:48 AM

Da zwei Fragen/Anmerkungen zu:

1. Hast du schon Daten in der DB? PostgreSQL kannst du nicht einfach durch eine neue Versionsangabe im Stack updaten.

2. PostgreSQL 18 hat Änderungen an Pfaden und Env Variablen. Du kannst da also nicht einfach die 17 durch 18 austauschen. Die Änderungen kannst du auf der offiziellen Seite nachlesen. Da steht was du anpassen musst.

blackh0le · October 3, 2025 at 12:43 PM

Zu 1. Es war alles clean. Ich hatte zuvor eine Testversion aufgesetzt um den Scanner ausgiebig zu testen. Danach alle Stacks, Container, Images und Verzeichnisse gelöscht. Wobei die Testversion auch einen anderen Namen generell genutzt hatte.

Zu 2. Ja ich habe gesehen das :/var/lib/postgresql/data zu :/var/lib/postgresql geändert werden sollte, da die Struktur nun zu ORDNER/18/docker/geändert wurde. Lässt man das /data/ gibt es auch einen hilfreichen Eintrag im Log mit dem Hinweis.

deltapapa · October 11, 2025 at 7:56 AM

Quote from Tommes
Ganz wie du magst. Nur macht es in meinen Augen keinen Unterschied, ob du Paperless-ngx auf einer DS oder auf einer DXP einrichtest. Das Ergebnis wird das Gleiche sein, zumal es hier ja erstmal nur um die Definition der Speicherpfade...
Code
     volumes:
      - /volume1/docker/paperless-ngx/data:/usr/src/paperless/data:rw
      - /volume1/docker/paperless-ngx/media:/usr/src/paperless/media:rw
      - /volume1/docker/paperless-ngx/export:/usr/src/paperless/export:rw
      - /volume1/docker/paperless-ngx/consume:/usr/src/paperless/consume:rw
... geht und ob du einige davon umbiegen möchtest oder nicht. Alles andere läuft dann ja eh über die WebUI von Paperless-ngx. Aber gut... ich will dir da nicht reinreden. In meinen Augen machst du dir das Leben nur unnötig schwer.
Ich habe bei mir z.B. den Ordner /usr/src/paperless/consume sowie den Ordner /usr/src/paperless/media/documents/originals umgebogen, was am Ende bei mir so aussieht...
Code
    volumes:
      - /volume1/docker/paperless-ngx/data:/usr/src/paperless/data:rw
      - /volume1/docker/paperless-ngx/media:/usr/src/paperless/media:rw
      - /volume1/docker/paperless-ngx/export:/usr/src/paperless/export:rw
      # - /volume1/docker/paperless-ngx/consume:/usr/src/paperless/consume:rw
      - /volume2/Dokumente/Aktenarchiv/Posteingang:/usr/src/paperless/consume:rw
      - /volume2/Dokumente/Aktenarchiv:/usr/src/paperless/media/documents/originals:rw
Mein Dokumentenscanner legt eingescannte Dokumente zunächst unter /volume2/Dokumente/Scaneingang/Brother_ADS1800W ab. Wenn ich mit dem Ergebnis des Scans zufrieden bin, verschiebe ich diese in den Ordner /volume2/Dokumente/Aktenarchiv/Posteingang wo sie dann durch Paperless-ngx konsumiert werden. Abgelegt werden die originalen PDF-Dokumente dann unter /volume2/Dokumente/Aktenarchiv, ergänzt durch den definierten Speicherort, der sich aus Speicherpfad, Korrespondent und Dokumenttyp zusammensetzt. Wie in einem anderen Thread bereits als Beispiel gezeigt:
/volume2/Dokumente/Aktenarchiv [ volumes: (definierter "originals" Pfad im YAML- bzw. Docker-Compose-File ]
Versicherungen [ Speicherpfad: Versicherungen/ ]
Allianz_Berufsunfaehigkeitsversicherung {{ correspondent }}
2025-07-23_Allianz_BU_12345678_Beitragsrechnung.pdf {{ created_year }}-{{ created_month }}-{{ created_day }}_{{ document_type }}_{{ title }}
Aber wie gesagt... tu was du für richtig hälst. Falls du Fragen hast, dann frag, ansonsten wünsche ich dir viel Erfolg bei deinem Vorhaben. Wann auch immer und auf welchem System auch immer.
Tommes
Display More

Moin Tommes,

darf ich einmal deinen ganzen Stack sehen? Dann kann ich das etwas leichter nachvollziehen. Oder hast du einen Stack aus der Filebase von hier genommen.

Ich habe zur Zeit paperless auf der 918 mit MariaDB am laufen, da spart man sich das ganze PostgreSQL Update gefrickel. Jedoch habe ich da mit dem Aufgabenplaner meine Scan's in den consume Ordner geschoben. Da (schmerzlicherweise) Ugreen keinen Aufgabenplaner hat, muss ich das ja nun irgendwie anders machen. Daher gefällt mir deine Lösung sehr

Tommes · October 11, 2025 at 8:43 AM

Moin!

Ich habe den Stack auf meinem GitHub Auftritt hinterlegt. Hier der Link *klick* Da ich selbst damals ein paar Probleme mit dem Healthcheck von Paperless-ngx hatte, habe ich diesen an entsprechender Stelle ( - webserver: ) zunächst entfernt. Gegebenenfalls kannst du dir den Healthcheck selbst wieder einbauen.

Die Einsortierung der PDF-Dokumente ins Dateisystem habe ich u.a. mit sogenannten Jinja-Filtern umgesetzt. Ich habe diesbezüglich einen Thread dazu aufgemacht *klick*

Was den Aufgabenplaner angeht. Wenn du nicht möchtest, das deine Scans direkt in den Consume Ordner landen, sondern nur indirekt, ginge das theoretisch auch ohne den Aufgabenplaner. Dazu müsstest du dich aber auf die Konsole der DXP aufschalten und könntest dir ein Paket mit dem Namen inotify-tools installieren. Nach entsprechender Einrichtung (siehe Link) würde Inotify einen bestimmten Ordner auf Veränderungen hin überwachen. Verbunden mit einem entsprechenden BASH Script könntest du anschließend die eingelaufenen Daten automatisch von A nach B schieben.

Oder du erstellst dir einen cronjob, der ein entsprechendes BASH Skript startet um Dateien zeitgeseuert von A nach B zu verschieben. Dies geht bisher aber leider ebenfalls nur über die Konsole.

Nur so als Idee.

Tommes

deltapapa · October 11, 2025 at 8:49 AM

Vielen herzlich Dank erst einmal. Ich werde mir das alles mal in Ruhe anschauen, aber die Idee, die Stacks in GitHub zu packen finde ich Weltklasse, das werde ich auch so machen.

Hast du dafür Portainer genutzt? Würde mir den Container ja gerne sparen, weil ich nur Paperless, Adguard und vielleicht noch Immich drauf machen werden. Aber wiederrum bei der Hardware tut Portainer nicht weh, und die Stacks laufen überall.

Tommes · October 11, 2025 at 8:59 AM

Ich hatte ganz zu Beginn mit der Docker App von UGOS Pro sehr gute Erfahrungen gemacht, habe zwischenzeitlich dann aber trotzdem kurz mit Portainer gearbeitet, bin dann aber wieder zur Docker App zurückgekehrt. UGREEN hat die Docker App wirklich toll umgesetzt und es wäre eine Schande, dies ungenutzt zu lassen, zumal meine Ansprüche an Docker eher gering sind.

Die Stacks laufen meiner Meinung nach auch ohne Portainer überall. Mag sein, das es Portainer ein paar Besonderheiten oder Vorzüge bereitstellt, aber ein Stack bleibt ein Stack.

deltapapa · October 11, 2025 at 9:03 AM

Okay, dann versuche ich es doch ersteinmal ohne Portainer. Noch eine kurze Frage: In deinem Stack ist alles auf Volumen 1 gemappt, in dem Thread hier aber schiebst du die Originale und den Consume aber auf Volumen 2, oder? Zur Datensicherheit oder aus Platzgründen auf der M.2?

Tommes · October 11, 2025 at 9:04 AM

Quote from deltapapa

Ich habe zur Zeit paperless auf der 918 mit MariaDB am laufen…

das hatte ich auch mal und im Synology Forum auch beschrieben *klick* Mittlerweile ist mir der Aufwand dafür zu groß geworden und nutze die Standardkonfiguration mit PostgreSQL

Docker läuft bei mir auf Volume1 (NVME) und meine persönlichen Daten liegen auf Volume2 (SSD) jeweils im RAID1 Verbund. Daher die Unterschiedlichen Volumes.

Der Stack dient ja nur der allgemeinen Übersicht. Individualisieren muss ihn jeder Selbst. Benutzernamen und Passwörter sind in dem Stack ja auch allgemein gehalten

deltapapa · October 11, 2025 at 10:10 AM

Quote from Tommes

das hatte ich auch mal und im Synology Forum auch beschrieben *klick* Mittlerweile ist mir der Aufwand dafür zu groß geworden und nutze die Standardkonfiguration mit PostgreSQL

Syno - Forum hatte ich das schon mal gesehen und jetzt erst den Bezug zu dir hier hersgestellt.

Aber was meinst du mit Aufwand: Einmal eingerichtet und läuft, bei PostgreSQL hast du ja immer die Update Problematik beim Major Update. Ich hatte gelesen das der Sprung von 17 auf 18 auch wieder Anpassung erfordert.

Tommes · October 11, 2025 at 4:57 PM

Der administrative Aufwand ist natürlich immer relativ und liegt immer im Auge des Betrachters. Unter Verwendung der PostgreSQL Datenbank brauch ich zunächst nur die persistenten Daten regelmäßig wegsichern, die ich im Bedarfsfall einfach zurückspielen kann. Unter Verwendung einer eigenständigen MariaDB Datenbank muss ich immer schauen, das der Datenbank-Dump mehr oder weniger zeitgleich mit den persistenten Daten weggesichert wird, um eine homogene Rücksicherung zu ermöglichen.

Ja klar… alles kein Hexenwerk und für mich auch ohne weiteres umsetz- und administrierbar, aber ich auch faul und mag es daher einfach. Keep it simple!

Es kann aber durchaus sein, dass ich meine Aussage morgen bereits über den Haufen werfe, denn nichts ändert sich bei mir schneller als die Lage. Von daher…

Tommes · October 12, 2025 at 5:56 PM

Mein lieber Scholli!

Heute überkam es mich, die mit Paperless-ngx verbundene PostgreSQL-Datenbank von Version 17 auf Version 18 zu aktualisieren.

Ein sporadischer Blick in das Paperless-ngx Projektprotokoll der Docker-App verriet mir jedoch, dass ich noch ein anderes Problem habe, und zwar folgendes:

Code

WARNING:  database "template1" has a collation version mismatch
DETAIL:  The database was created using collation version 2.36, but the operating system provides version 2.41.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE template1 REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

Glücklicherweise konnte ich das Problem mithilfe dieses Forumsbeitrags lösen.

Nachdem das erledigt war, fiel mir im Paperless-ngx Projektprotokoll der Docker-App eine weitere Fehlermeldung auf, die ebenfalls PostgreSQL betraf, nämlich diese hier:

Code

FATAL: role "root" does not exist

Hier lag vermutlich ein Healthcheck-Fehler im Docker-Compose-File vor, den ich ebenfalls relativ einfach beheben konnte.

Nach einem Neustart von Paperless-ngx taten keine Fehlermeldungen mehr auf. Also dann – PostgreSQL-Update durchführen. Gesagt, getan. Dazu habe ich folgende Schritte durchgeführt:

Ein Dump der PostgreSQL 17 Datenbank erstellt
Paperless-ngx Container inkl. Redis und PostgreSQL 17 beendet.
Eine Kopie bzw. Sicherung meiner persistenten Daten von /volume1/docker/paperless-ngx angelegt.
Das Paperless-ngx Docker-Compose-File auf die neuen Begebenheiten zur Implementierung von PostgreSQL 18 eingetragen.
Paperless-ngx Container gestartet.

Das Ergebnis war eine taufrische Paperless-ngx-Installation ohne Einträge. Na toll! Also habe ich den Dump der PostgreSQL-17-Datenbank zurückgespielt. Ohne Erfolg. Also wieder alles auf Anfang. Immerhin hatte ich zu Beginn ein Backup meiner persistenten Daten erstellt. Nach dem zurückspielen und Starten von Paperless-ngx lief wieder alles – halt nur mit PostgreSQL 17 und nicht 18.

Also nochmal von vorn. Ich habe das alles noch zwei- oder dreimal durchgespielt, aber irgendwie wollte es nicht klappen. Fragt mich nicht, warum. Nachdem ich einmal laut „Scheiße” gebrüllt hatte, um es ein letztes Mal zu versuchen, klappte es auf einmal, warum auch immer. Vielleicht lag's am Fluchen? Ich weiß es nicht.

Jedenfalls läuft jetzt wieder alles. Das ganze hat mich aber wieder gute 2 Stunden Arbeit gekostet. Hölle. Hölle. Hölle.

Fazit: Legt blos ein Backup eurer persitenten Daten an, bevor ihr irgendwas an Paperless-ngx ändert. Mir hat das echt den Hintern gerettet, sonst wären über 2000 PDF-Dokumente für die Katz gewesen.

Ich geh’ jetzt schaukeln, das beruhig mich immer.

Tommes

Marlachisch · October 12, 2025 at 6:18 PM

Quote from Tommes

Ich geh’ jetzt schaukeln, das beruhig mich immer.

Hab zwar weniger als die Hälfte verstanden, aber bei sowas hilft mir eher ein kühles Blondes

Tommes · October 12, 2025 at 7:09 PM

Ich neige da eher zu einem guten Glas Whisky oder Rum. Gerne auch während ich schaukel

BTW: Man muss auch nicht immer alles (gleich) verstehen. Der ein oder andere wird aber vielleicht auf ähnliche Probleme treffen und da können solche Informationen durchaus hilfreich sein. Auch teile ich mich gerne mit und hier passten meine Ausdünstungen am besten rein, wie ich finde.

Back to Topic. Ich werde die Tage wohl noch mein Docker-Compose-File auf GitHub entsprechend anpassen. Zuvor wollte ich aber noch ein paar abschließende Tests durchführen.

deltapapa · October 12, 2025 at 7:13 PM

Moin Tommes,

vielleicht denke ich da zu einfach, aber ich habe den Wechsel der Datenbanken und der verschiedenen Updates mit PostgreSQL immer via Export und Import Funktion in PaperlessNGX direkt gemacht. Dem Importer ist die Infrastruktur egal, das hat bis jetzt noch immer geklappt. Daher vermisse ich auch den task scheduler so schmerzlich, weil ich damit jeden Tag einen Export mache, und mir diesen 2x wegsichere.

Habe aber auch nur knapp 1000 Dokumente, aber denke mal die Menge macht keinen Unterschied...

Participate now!