paperless ngx unter docker auf Synology - Erste Erfahrungen

[the other]

Moinsen,
ich habe mich ja lange um docker / Container Manager / portainer und co auf dem NAS gedrückt, nicht weil ich das Modell doof finde oder ablehnen würde...mir fehlten bisher einfach ein paar Anwendungsszenarien, die auch im Alltag Nutzen bringen.

Habe aber vor ein paar Tagen mal zum Spass damit angefangen. Zuerst mit Heimdall, was auf Anhieb gut funktionierte und jetzt als Startbildschirm beim Öffnen der Browser agiert...nice.
Am Wochenende kam dann eine neue Idee: paperless ngx, um zukünftig etwas Ordnung in den Brief- / Rechnungs- / Papier-Zustand zu bringen.

Also schematisch wie folgt vorgegangen:
1. Portainer eingerichtet, weil es damit IMHO doch etwas schöner von der Hand geht als mit dem Synology eigenen Container Manager....läuft.
2. Mich in paperless ngx eingelesen, die diversen Seiten im Netz zu "Synology und paperless" überflogen, die diversen Konfigurations-YAMLs angeschaut...
3. Die Konfiguration angepasst an meine Bedürfnisse (Ordner Mapping, Speicherort, UID und GID usw)...ok.
4. Samstag dann diese eingerichtet unter Portainer > Stacks...läuft.
5. Erste Schritte mit paperless ngx gemacht, getestet, ausprobiert, rumgespielt...bin immer noch dabei, viele Möglichkeiten.
6. Erste Schritte versucht, um einen workflow zu gestalten, der für meine Bedürfnisse funktioniert...done.
7. Dann die ca. 400 pdfs, die hier bereits auf der Festplatte in Ordnern ruhen, mit paperless behandelt...fertig.
8. Eben noch den Netzwerkscanner mit paperless bekannt gemacht, so dass Scan-über-FTP jetzt auf Knopfdruck direkt zu paperless liefert, was dann die Dokumente weiterverarbeitet und ablegt.
9. Die paperless Ordner ins backup Programm überführt, damit die Arbeit auch abgesichert wird.

Bis hier geht auch alles. Bei einigen Schritten war etwas Tee, Zigarette, Süßkram nötig, weil es nicht direkt wollte (zB die Einrichtung Scanner als FTP Scanner war zäh, jetzt geht aber auch das).
Ich bin mal gespannt, wie es dann in den nächsten Wochen so weitergeht. Vermutlich werde ich paperless noch einige Zeit an meinen Workflow anpassen, hier und da mal nachjustieren (gerade bei der Automatisierung) und beobachten, ob das Ergebnis meinen Vorstellungen entspricht. Der erste Eindruck nach dieser kurzen Zeit ist aber durchweg positiv, endlich Ordnung im Papierlager. Das Wiederfinden, Organisieren, Katalogisieren ist aber deutlich angenehmer als vorher.

Nun bin ich ja nicht der Erste, der damit arbeitet (bzw. erste Krabbelschritte macht). Wie ist eure Erfahrung?
- nutzt ihr paperless ngx?
- Probleme? Positives?

 

[blurrrr]

- nutzt ihr paperless ngx?

Nein.

- Probleme? Positives?

Kann ich nix zu sagen, s.o.

Somit hat Dir zumindestens schon jemand geantwortet...

Aber mal ernsthaft: Ich hatte es mir vor Jahren mal angeschaut (k.A. ob es da schon "ngx" hiess), war aber irgendwie nicht so meins, deswegen ist es direkt wieder weggeschmissen worden. Aktuell organisiere ich halt alles vernünftig und mit einem DMS ist die Gefahr recht groß - so gut kenne ich mich dann doch - dass einfach alles völlig unsortiert reingeworfen wird, das DMS wird es schon richten und darauf hab ich eigentlich auch keine Lust... Falls dann mal was sein sollte, oder man will vllt gar kein DMS mehr nutzen (oder wie auch immer) steht man mitunter vor gravierenden Problemen

 

[the other]

Moinsen,
ach, ich schaue einfach mal...sind meine ersten Gehversuche mit DMS und auch mit Docker allgemein
Was ich bisher sagen kann:
die Daten werden in gemappten Ordnern in einer eigenen Freigabe abgelegt (sowohl die eigentlichen Dokumente als auch alles für paperless). Die sind (gestern mal versucht) auch weiter vorhanden, selbst wenn der Stack entfernt wird. Das ist also schon mal sicher gestellt . Den Stack dann wieder eingespielt, lief sofort. Mal etwas an der .yaml verändert (andere Variablen zugefügt, damit der Scanner bzw paperless mit barcode Trennseiten umgehen lernt > hat auch geklappt)...bisher hat es das alles ausgehalten...

Die gescannten und durch paperless verwalteten Dokumente werden im Original und in bearbeiteter Version aufgehoben, ähnlich wie bei den besseren Fotobearbeitungsprogrammen (lightroom, darktable), so dass die eigentliche vom Scanner erzeugte .pdf unverändert im eigenen Ordner liegt. Die .pdf, die mit den Tags und anderen Datenbankeinträgen versehen wurde liegt an anderer Stelle. Beide Ordnerstrukturen sind gleich, ändere ich also in paperless etwas am Speicherort, passt sich die Struktur der Ordner für die Originale mit an.
Damit sind auf jeden Fall schon mal (auch per einfachem Backup) die Struktur und die Inhalte (.pdfs) safe (hoffe ich ).

Damit das dann aber auch im Falle des Falles wieder mit den Datenbankinhalten passt, mache ich regelmäßig dann einen kompletten Export per document_exporter. Das sichert dann wirklich auch die Datenbankeinträge plus Original plus "verwaltete" und mit OCR versehene Version. Und der wird dann auch in die Backup Orgie mit aufgenommen...

Ich hoffe, dass ich damit einigermaßen über die Runden komme. So sollte die Ordnerstruktur und Benennung mir auch dann noch ermöglichen alles wiederzufinden, wenn sich vielleicht paperless erledigt hat. Und in der Zwischenzeit genieße ich (für mich als Privatperson mal wieder etwas großkotzig ), dass der Scanner auf Wunsch alles direkt mit paperless vereinbart, ich meine sonstigen eigenen Unterlagen als pdf exportiere und dann mit paperless sortieren lasse und bisher vor allem die Stichwortsuche. Da wird das Rauskramen für die nächste Steuererklärung endlich mal etwas abgekürzt.
Und nein, ganz automatisieren werde ich den Eingang sicherlich nicht...da hab ich gerne selber ein Auge drauf...aber das "Nacharbeiten" dauert bisher nicht länger als das Abheften oder bisherige Speichern. Wenn erstmal genug Tags und Speicherpfadvorgaben da sind, ist das schnell von der Hand. Und die Vorschläge von Paperless werden mit der Zeit auch präziser.

Aber was laber ich, gerade mal seit Samstag damit am Machen...

 

[Frank73]

Wir nutzen aktuell ecoDMS, haben aber auch die ersten Gehversuche mit paperles-ngx unternommen, da ecoDMS meiner Meinung nach etwas überfrachtet und langsam wirkt.

Zu Testzwecken habe ich das 3er-Konglomerat (redis, postgres und paperless) auf dem VMM (DSM) installiert.

Auch wir nutzen Portainer (mehr Möglichkeiten und wesentlich Userfreundlicher als der Container-Manager).
Habe mich über das Wochenende hauptsächlich damit beschäftigt, auf welchem Datenbanksystem ich das Dokumentenmanagement aufsetzen will. In Frage kamen MariaDB und PostgreSQL. Letztendlich fiel nach mehreren Installationen und div. Tests die Entscheidung auf PostgreSQL, obwohl das Handling bzgl. Upgrades auf neue Major-Releases bei MariaDB einfacher sein soll.
Auch das Mapping der jeweiligen Volumes funktioniert einwandfrei. Testläufe mit dumps für PostgrSQL wurden auch erfolgreich durchgeführt.

Ich habe für jeden Container einen separaten Stack erstellt. Das hat für mich den Vorteil, dass ich jeden Container individuell bearbeiten kann, ohne immer den kompletten Stack stoppen zu müssen (vor allem noch in der Testphase). Zusätzlich habe ich im Stack des PostgreSQL noch pgadmin4 mit aufgenommen, sodass ich mir über einen GUI die Datenbank für paperless bequemer ansehen kann.

In Paperless haben wir vorab mal die ersten Speicherpfade, Aufgaben, Tags ... erstellt, da wir aus ecoDMS ca. 3.000 Dokumente migrieren wollen.
Bei den Speicherpfaden haben wir darauf geachtet, dass die Ordnertiefe nicht so tief ist und das "Zusammenbauen" der Dateinamen nicht zu so langen Dateinamen führt. Das war mir als "Backup" wichtig für den Fall, dass es paperless irgenwann mal nicht mehr gibt (was ich nicht hoffe!).
Zusätzlich haben wir noch den Mailabruf eingerichtet, über den wir von einem bestimmten Empfänger die *.pdf-Dateien automatisiert aus dem Maileingang nach paperless abholen. Da wir alle noch papierhaften Eingänge im Geschäft über einen ordentlichen Scanner jagen, verschicken wir diese einfach an die hinterlegte Mailadresse und abends können wir dann die Zuordnungen vornehmen.

Für die "Pflege" des Dokumentenmanagementsystems ist dann meine Frau zuständig (ich stelle nur die Technik zur Verfügung ), da sie ein besseres Verständnis für die Datenablage hat.
Im Vergleich zu ecoDMS ist der OCR-Scan in paperless zuverlässiger und auch deutlich schneller. Auch die Oberfläche ist in paperless viel ansprechender und schneller als in ecoDMS.

Mein nächster Schritt wird es sein, die Container auch auf dem "Haupt"-NAS einzurichten und mit der Migration zu beginnen.

Fazit:
Wir sind von paperless-ngx total begeistert!!

 

[the other]

Moinsen @Frank73,
ich stolpere gerade noch über den pg_dump...

Wie hast du paperless laufen? Via portainer? Container Manager?
Ich bekomme gerade den bekannten Fehler:

pg_dump: error: connection to server on socket "/var/run/postgresql/.s.PGSQL.5432" failed: No such file or directory
    Is the server running locally and accepting connections on that socket?

Wie genau hast du den dump denn erstellt? Danke für ein paar Tipps dazu...

 

[Frank73]

Hallo @the other ,

paperless läuft bei mir im Portainer.

PostgreSQL deploye ich mit folgendem Stack:

version: "3.4"
networks:
   br_paperless:
      external: true
      
services:

  db:
    container_name: ppl_pg_16
    image: library/postgres:16
    networks:
      - br_paperless   
    volumes:
      - /volume1/docker/paperless/pg_16:/var/lib/postgresql/data
      - /volume1/docker/paperless/pg_backup:/backup
    restart: unless-stopped
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password

Ich binde das Verzeichnis "backup" auf den Host und führe dann folgenden Befehl über das Container-Terminal aus:

pg_dumpall -U paperless > /backup/jjjj_mm_dd.sql

Diesen Befehl möchte ich allerdings über eine Aufgabe automatisiert täglich laufen lassen, sodass ich kein tgl. manuelles ToDo bzgl. Datensicherung der Datenbank durchführen muss (werde ich versuchen umzusetzen sobald paperless nicht nur auf dem VMM läuft).

 

[the other]

Moinsen,
Vielen Dank für deine Antwort.
Ich werde es die Tage mal versuchen.
Portainer nutze ich auch, bin da aber bisher absolut neu, unbedarft und ahnungslos...gefährliche Mischung also.
Kopierst du den Befehl dann unter Portainer direkt in das zum paperless DB gehörende consolenfeld? Und ausführen als angelegtem Postgres User oder root...? Du siehst schon an der Frage: null Erfahrung (aber willens).

 

[Frank73]

Hallo,

also ich bin auf diesem Gebiet auch noch Neuling und lese mich gerade so nach und nach ein
Ja, ich kopiere diesen Befehl direkt in die Console des PostgreSQL-Containers. Habe es gerade nochmals getestet und der Dump wird sowohl mit dem User "root" als auch mit dem User "postgres" in das Backup-Verzeichnis erstellt.

 

[the other]

Moinsen,
Na, dann werde ich es die Tage mal, darüber versuchen.
Erneut, herzlichen Dank für den Tip.
Soweit ich bisher gelesen habe, gehen die Meinungen ja auch etwas auseinander bzgl dump nötig vs nicht nötig.
Ein Export mit document_exporter soll reichen, sagen die einen, dump muss sein die anderen...oder einfach die gemachten Ordner komplett...
Naja...geht ja am Ende vor allem darum, dass bei einem Update der DB die Daten nicht unbrauchbar werden, soll bei postgres ja durchaus vorkommen...

Davon ab bin ich auch weiterhin von paperless begeistert.

 

[blurrrr]

Ja, ich kopiere diesen Befehl direkt in die Console des PostgreSQL-Containers

Wäre das nicht praktischer via docker exec -it my_container sh -c "<Befehl>" (ggf. auch direkt als Cronjob)?

 

[the other]

Moinsen,
bin offensichtlich zu doof ...
Bei mir wird da keine wirkliche dump.sql erstellt bzw diese ist leer.
Ich habe den stack wie hier angelegt:

version: "3.6"

networks:
    internal:
        external: false

services:
    broker:
        container_name: paperless-redis
        image: redis:6.2
        volumes:
            # Hier den richtigen Pfad zum gemappten Ordner (vor dem ":") eintragen
            - /volume1/paperless/redis:/redis
        restart: unless-stopped

    db:
        container_name: paperless-db
        image: postgres:14
        # oder die gewünschte Version zB
        # image: postgres:13
        # Nicht einfach up- oder downgraden, die Datenbank wird dann nicht mehr laden > dafür einen dump.sql anlegen
        restart: unless-stopped
        volumes:
            # Hier ebenfalls den richtigen Pfad zum gemappten Ordner eintragen (der Ordner muss zuvor manuell angelegt werden am Ort                   # der Wahl)
            - /volume1/paperless/db:/var/lib/postgresql/data
          # oder alternativ zB:
        #  - /volume2/paperless/db:/var/lib/postgresql/data
        environment:
            POSTGRES_DB: paperless
            POSTGRES_USER: paperless
            # Hier ein anderes Passwort verwenden statt GEHEIMNIS
            POSTGRES_PASSWORD: GEHEIMNIS

    webserver:
        container_name: paperless
        image: ghcr.io/paperless-ngx/paperless-ngx:latest
        restart: unless-stopped
        depends_on:
            - db
            - broker
        ports:
            # Diesen Teil löschen, wenn der Proxy Manager auf der Synology ist.
            # Ansonsten hier einen Port auswählen, der frei ist. Ich habe den Port laufen plus reverse proxy, kann also via domainname oder               # IP plus Portangabe gehen
            - 8010:8000
        # alternativ nach Wunsch und freien Ports
        # - 8011:8000
        # - 8012:8000
        healthcheck:
            test: ["CMD", "curl", "-f", "http://localhost:8000"]
            interval: 30s
            timeout: 10s
            retries: 5
        volumes:
            # Hier die passenden Pfade zum gemappten Ordner eintragen
            - /volume1/paperless/data:/usr/src/paperless/data
            - /volume1/paperless/media:/usr/src/paperless/media
            - /volume1/paperless/export:/usr/src/paperless/export
            - /volume1/paperless/paperless_inbox:/usr/src/paperless/consume
        environment:
            PAPERLESS_REDIS: redis://broker:6379
            PAPERLESS_DBHOST: db
            PAPERLESS_DBPASS: GEHEIMNIS # Das ist das Passwort von oben
            USERMAP_UID: 1045 # UserID für den docker Benutzer
            USERMAP_GID: 65541 # GruppenID für den docker Benutzer (kann auch (bei mehreren Gruppen IDs) ausgewählt werden > hier               # ist es die paperless Gruppe
            PAPERLESS_ADMIN_USER: USERNAME
            PAPERLESS_ADMIN_PASSWORD: PASSWORT
            PAPERLESS_OCR_LANGUAGES: eng deu       
            PAPERLESS_TIME_ZONE: Europe/Berlin
            PAPERLESS_OCR_LANGUAGE: deu
            PAPERLESS_CONSUMER_ENABLE_BARCODES: true
            PAPERLESS_URL: https://anonymisiert!!

Das ganze unter /volume1/paperless/... gemappt (wie zu sehen). Hmm...tja. Ich mach mir jetzt auch keinen Stress (aber es wurmt mich doch etwas).
Ideen von den Portainer /docker auf Synology Profis hier?

 

[blurrrr]

Also ich bin ja für die Syno-Aufgabenplanung / Cronjob... Wenn es mit dem o.g. Befehl funktioniert, sollte ja sowas wie...
docker exec -it paperless-db sh -c "pg_dumpall -U paperless > /backup/jjjj_mm_dd.sql"
... theoretisch funktionieren. Dazu braucht der DB-Container aber natürlich auch noch ein entsprechendes Volume (<Syno-Backup-Pfad>:/backup). Vielleicht erstmal über die Syno-Shell testen und danach in die Aufgabenplanung werfen

 

[the other]

Moinsen,
so, basta, Schnauze voll und so...
Ich habe jetzt den Stack mal etwas verändert und dieses ergänzt (nicht auf meinem Mist gewachsen, nur gefunden):

 db-backup:
        container_name: paperless-db-backup
        # Das Image (postgres Version) an das obere anpassen
        image: postgres:14
        volumes:
            # Hier den richtigen Pfad für die gemappten Ordner eintragen
            - /volume1/paperless/backup:/dump
            - /etc/localtime:/etc/localtime:ro
        environment:
            PGHOST: db
            PGDATABASE: paperless
            PGUSER: paperless
            PGPASSWORD: GEHEIMNIS # Das ist das Passwort von oben aus der Stack config zur Datenbank
            BACKUP_NUM_KEEP: 10 #individuell anpassbar
            BACKUP_FREQUENCY: 7d # Alle 7 Tage, kann man anpassen nach eigenem Bedarf
        entrypoint: |
            bash -c 'bash -s <<EOF
            trap "break;exit" SIGHUP SIGINT SIGTERM
            sleep 2m
            while /bin/true; do
              pg_dump -Fc > /dump/dump_\`date +%d-%m-%Y"_"%H_%M_%S\`.psql
              (ls -t /dump/dump*.psql|head -n $$BACKUP_NUM_KEEP;ls /dump/dump*.psql)|sort|uniq -u|xargs rm -- {}
              sleep $$BACKUP_FREQUENCY
            done
            EOF'
        networks:
            - internal

Damit bekomme ich im angelegten Ordner /volume1/paperless/backup auch eine dump.sql Datei erstellt, die auch etwas enthält. Es funktioniert also und das sogar automatisiert...alle 7 Tage, dump Datei mit Datum und Uhrzeit versehen, 10 Versionen aufbewahren und ältere weg. So zumindest der Plan...ich sag dann nächste Woche mal Bescheid, ob es automatisiert funktioniert hat.
Ist allerdings (wie so vieles) nicht auf meinem Mist gewachsen, sondern ebenfalls aus dem www gezogen und angepasst.

 

[Frank73]

@the other:
So wie ich das aus deinem Stack sehe, hast du für paperless einen eigenen Share angelegt. Dazu hätte ich mal 2 Fragen:

1) Hast du bei der Erstellung des Shares den Parameter "Daten-Prüfsumme für erweiterte Datenintegrität aktivieren" aktivierst? Synology empfiehlt ja bei der Verwendung von Datenbanken auf diese Einstellung zu verzichten.

2) Hast du einen separaten User für paperless im DSM angelegt und diesem nur Zugriff auf den Share "paperless" eingeräumt? Ich bräcuhte noch eine kleine Entscheidungshilfe; schwanke hin und her zwischen separatem User anlegen und nicht.

@blurrrr:
Wenn mein paperless auf dem Produktiv-NAS möchte ich die tgl. Sicherung automatisiert laufen lassen, wobei mir die Möglichkeit von @the other auch gefällt, da man dann alles an einem Ort hat.

 

[blurrrr]

Najo, ist ja auch verständlich und wäre ja auch nett, wenn es so läuft, sicher bin ich mir da allerdings nicht, denn:

Setting entrypoint both overrides any default entrypoint set on the service'simage with the ENTRYPOINT Dockerfile instruction, and clears out any defaultcommand on the image - meaning that if there's a CMD instruction in theDockerfile, it is ignored.

(Quelle: https://docs.docker.com/compose/compose-file/compose-file-v3/#entrypoint)

So wie ich das verstehe (und ich hab nicht sonderlich viel Ahnung von Docker), könnte sich das ggf. auch schon direkt auf Images auswirken. Ist im Image etwas bzgl. entrypoint definiert, dürfte das mit dem Zusatz in der Compose-Datei überschrieben werden.

postgres:14

Schaut man dann mal ins offizielle Dockerfile des pgsql-Containers... https://github.com/docker-library/p...816928a50c483ecc370c00/16/bookworm/Dockerfile ... findet sich diesbezüglich auch ein entsprechender Eintrag in Zeile 193: ENTRYPOINT ["docker-entrypoint.sh"], welcher auf diese Datei verweist: https://github.com/docker-library/p...483ecc370c00/16/bookworm/docker-entrypoint.sh. Von daher bin ich mir nicht so sicher, ob der entrypoint-Weg in diesem Fall der richtige ist...

Schaut man sich allerdings mal die Beschreibung des postgres-Images etwas genauer an (https://hub.docker.com/_/postgres), findet sich auf der Seite weiter unten noch folgender Punkt: "Initialization scripts", wo es u.a. heisst:

If you would like to do additional initialization in an image derived from this one, add one or more *.sql, *.sql.gz, or *.sh scripts under /docker-entrypoint-initdb.d (creating the directory if necessary). After the entrypoint calls initdb to create the default postgres user and database, it will run any *.sql files, run any executable *.sh scripts, and source any non-executable *.sh scripts found in that directory to do further initialization before starting the service.

Das liest sich für mich jetzt erstmal so, als sollte man die Finger von allem anderen lassen und wenn man etwas ausführen möchte, sollte man es dort einfach entsprechend z.B. als sh-Script im Ordner "/docker-entrypoint-initdb.d/" hinterlegen. Allerdings ist es auch gut möglich, dass ich diesbezüglich auf der völlig falschen Spur bin...

 

[the other]

Moinsen @Frank73,
ja, ich habe die gemappten Ordner auf einen eigenen freigegebenen Ordner gelegt. Und ja, ich habe mich dabei an die Empfehlung gehalten und keine Daten-Prüfsumme aktiviert (und auch nix verschlüsselt).
Und ja, es gibt einen eigenen Nutzer ("paperless" sowie eine eigene Gruppe "paperlessgroup"). Nur diese dürfen auf den Freigegebenen Ordner zugreifen. Außerdem für den Scanner auch ein eigenes Konto, damit der auch die gescannten Dokumente in den inbox Ordner packen darf. Damit sind also nur die Geräte zugelassen, mit denen ich entweder scanne oder aber .pdfs in den Inbox Ordner lege.

Zum Backup: das postgres: 14 meint die Version...
Ich habe hier nur den reinen privaten Gebrauch vor (und bekomme auch nicht so viele Dinge für die In-box), daher reichen mir die wöchentlichen (wenn es denn dann klappt, berichte nächste Woche ) dumps der Datenbank sowie regelmäßige Exporte mit dem document_exporter (hierfür den Befehl im Aufgabenplaner hinterlegt mit Zeitplan 1 x wchtl.).
Dann Hyper Backup gesagt:
1. den gesamten Paperless share sichern (also alle enthaltenen gemappten Ordner)
2. den dump sowie die Exporte via document_exporter ebenfalls mit HB sichern.
Damit sollte ich dann also haben:
a) ein Backup der abgescannten Daten (als Original sowie als mit Tags versehene Dateien) und zugehörende Ordnerstruktur
b) den dump
c) alles, was der Exporter exportiert


Am Ende: es sind aktuell keine 200 Dokumente, entsprechend klein ist die Größe von dump und co...daher bin ich vermutlich auch nicht der typische Anwender, der ggf einige hundert oder tausend (achwassagich: MILLIONEN!!!) an Dateien hat.

 

[the other]

Moinsen,
achja, entry point...kurz mal eben nachgeschaut in portainer...der Stack besteht bei mir ja aktuell aus den folgenden containern (samt entry points):
- paperless > entry point:

/sbin/docker-entrypoint.sh

- paperless-redis >

    docker-entrypoint.sh

- paperless-db > ebenso
- paperless-db-backup > hier wird der gesamte Befehl als entry point angegeben. also

bash -c bash -s <<EOF trap "break;exit" SIGHUP SIGINT SIGTERM sleep 2m while /bin/true; do pg_dump -Fc > /dump/dump_\`date +%d-%m-%Y"_"%H_%M_%S\`.psql (ls -t /dump/dump*.psql|head -n $BACKUP_NUM_KEEP;ls /dump/dump*.psql)|sort|uniq -u|xargs rm -- {} sleep $BACKUP_FREQUENCY done EOF

Nun gebe ich offen zu: ich bin da viel zu unerfahren und erst absolut am Anfang mit dem Thema...bisher klappt alles (soweit ich das bisher beurteilen kann). Zum Thema habe ich mich zum Verständnisgewinn (ahem) hieran orientiert: https://kinsta.com/blog/dockerfile-entrypoint/
WENN (!) ich das also korrekt verstehe, dann sollte auch das so passen...aber wie gesagt: am Anfang, null Erfahrung, noch weniger knowhow dazu.

Manuell habe ich übrigens nur den entry point des backups gesetzt, die anderen waren automagisch in portainer am Start...

 

[blurrrr]

- paperless-db
- paperless-db-backup

Is jut, hab nix gesagt, wer lesen kann ist klar im Vorteil, dachte das wäre mit beim eigentlichen DB-Container

 

[Frank73]

Hallo @the other

Und ja, es gibt einen eigenen Nutzer ("paperless" sowie eine eigene Gruppe "paperlessgroup").

d. h. dieser User und diese Gruppe hat auch nur auf diesen Share Zugriff und auf den Rest nicht?

Ich habe mir auch mal deine verlinkte Seite bzgl. Entrypoint durchgelesen (sowohl auf Deutsch und auf Englisch). Da bin ich jetzt komplett raus. Wenn du erst am Anfang mit null Erfahrung stehst, wo stehe ich dann erst .

Ich denke das Wochenende ist mal wieder gesichert (will mal einen bekannten Roboter zitieren: "Input, input")

 

[the other]

Moinsen,
Paperless Konto, scanner Konto und paperless-Gruppe nur auf den share, ja.
In der Gruppe sind allerdings auch clients Mitglied, die durchaus auf andere shares zugreifen dürfen...