Paperless-ngx Paperless-ngx – DMS via Docker auf dem NAS

[renfiela]

Der Container Manager wird aber durch den Systembenutzer ausgeführt. Das kannst du auch gut daran erkennen, dass du mit deinem Adminbenutzer Docker Container nicht starten und stoppen kannst, sondern nur als Superuser wie der root.
Probier mal als Benutzer docker stop <containername> wird eher nicht gelingen.
Das funktioniert nur als Mitglied der Superuser, also mit sudo docker stop <containername>

docker stop Paperless
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/containers/Paperless/stop": dial unix /var/run/docker.sock: connect: permission denied

$ id
uid=1029(systemrene) gid=100(users) groups=100(users),101(administrators),1023(http)
systemrene@nas:~$ sudo -i
Password:
root@nas:~# id
uid=0(root) gid=0(root) groups=0(root),2(daemon),19(log)root@nas:~#

 

[plang.pl]

Dazu fällt mir das hier ein: https://davejansen.com/manage-docker-without-needing-sudo-on-your-synology-nas/
Ob das funktioniert, keine Ahnung. Nie getestet. Vielleicht hat ja jemand Bock.

 

[Tuxnet]

Ich habe mal die confdatei von @renfiela getestet,
Beitrag im Thema 'Paperless-ngx – DMS via Docker auf dem NAS'
https://www.synology-forum.de/threads/paperless-ngx-dms-via-docker-auf-dem-nas.124614/post-1136619
da ist alles bei mir grün, mit meiner oder @Pixelschubser ist der paperless container auch orang.

@renfiela kannst du mal bitte deine docker-compose.env posten

 

[renfiela]

Anbei die docker-compose.env dort siehst du auch, dass Paperless mit der id des root ausgeführt wird.

USERMAP_UID=0
USERMAP_GID=0

PAPERLESS_URL=https://deineURL #oder auskommentieren
PAPERLESS_SECRET_KEY=geheimerKey
PAPERLESS_TIME_ZONE=Europe/Berlin
PAPERLESS_OCR_LANGUAGE=deu+eng
PAPERLESS_OCR_IMAGE_DPI=300
PAPERLESS_TASK_WORKERS=2
PAPERLESS_THREADS_PER_WORKER=2
PAPERLESS_CONSUMER_ENABLE_BARCODES: true
PAPERLESS_CONSUMER_ENABLE_ASN_BARCODE: true
PAPERLESS_CONSUMER_BARCODE_SCANNER: ZXING
PAPERLESS_PRE_CONSUME_SCRIPT: /scripts/pre-consume.sh
PAPERLESS_ENABLE_UPDATE_CHECK=true
PAPERLESS_FILENAME_FORMAT={created_year}/{correspondent}/{title}

 

[alexhell]

Der User den du bei paperless angibst muss die Rechte für den Ordner haben. Gibst du da einen User mit?

Der Container Manager wird aber durch den Systembenutzer ausgeführt. Das kannst du auch gut daran erkennen, dass du mit deinem Adminbenutzer Docker Container nicht starten und stoppen kannst, sondern nur als Superuser wie der root.

Ja, Docker wird mit root Rechren ausgeführt, aber deshalb müssen doch nicht die Container im selben Kontext laufen. Bei mir läuft das auch ohne Probleme mit

USERMAP_UID: 1026
USERMAP_GID: 100

Es gibt auch sehr viele Container die erst gar nicht mit root laufen. Und zwar aus Sicherheitsgründen.

Dazu fällt mir das hier ein: https://davejansen.com/manage-docker-without-needing-sudo-on-your-synology-nas/

Das würde ich auf gar keinen Fall konfigurieren. Wer Zugriff auf den Docker Daemon hat, hat quasi Root Rechte. Er könnte sich dann einen Container erstellen und / mounten und alles machen was er will.

 

[renfiela]

Man sollte es aber auch einmal von der Seite aus betrachten, dass wir hier im privaten und nicht im Unternehmenskontext handeln. Zudem wird keiner so verrückt sein, sämtliche Dienste der Synology durch Portfreigaben an seinem öffentlichen Internetanschluss preiszugeben.

Wenn ein Ordner beim Binding in der docker-compose.yml zuvor im Dateisystem nicht bestand, dann wird er zwangsläufig durch den Systembenutzer angelegt. Wenn du anschließend versuchst, diesen Ordner als normaler Systembenutzer zu bearbeiten, wird es dir nicht gelingen, da dir die Rechte fehlen.

Ich schlage mal vor, um zu einer Lösung zu kommen, dass einmal die ID gepostet wird und von allen relevanten Ordnern die Rechte angeschaut werden. Anschließend kann man immer noch entscheiden, ob man die Rechte geradebiegt oder den Container in einem anderen Kontext ausführt.

 

[plang.pl]

Zudem wird keiner so verrückt sein, sämtliche Dienste der Synology durch Portfreigaben an seinem öffentlichen Internetanschluss preiszugeben.

Oh doch! Das gab es schon und wird es auch immer wieder geben, so lange Synology solche Dinge wie automatische Portfreigaben ins DSM schraubt und dass ohne eine ausreichende Warnung geblockt ist.

 

[renfiela]

Es gibt auch sehr viele Container die erst gar nicht mit root laufen. Und zwar aus Sicherheitsgründen.

Dabei handelt es sich aber auch nicht um meine Aussagen, sondern sind der entsprechenden Dokumentation von Paperless zu entnehmen. Mir ist dabei schon bewusst, dass es durchaus Container gibt, denen man keine ID übergeben muss und diese anschließend super laufen. Bei Paperless gibt es jedoch diesen Umstand und deshalb ist es auch wichtig zu wissen, welcher Benutzer hat die Rechte an den Ordnern und wer führt den Container aus:

Modify docker-compose.env, following the comments in the file. The most important change is to set USERMAP_UID and USERMAP_GID to the uid and gid of your user on the host system. Use id -u and id -g to get these.

Letztlich möchte ich nur Hilfestellung leisten. Man sollte sich die genannten Punkte einmal anschauen und dann mit gesundem Menschenverstand darüber entscheiden.

 

[alexhell]

Mir ging es nur darum, dass du empfohlen hast es als root laufen zu lassen. Also User ID 0. Das sollte man halt vermeiden. Man kann genau deshalb doch den User angeben. Und ich stimme dir zu, dass man seine Ordner Struktur richtig durchgucken sollte, ob die Rechte passen. Aber es ist keine Lösung den Container als root laufen zu lassen.

Man sollte es aber auch einmal von der Seite aus betrachten, dass wir hier im privaten und nicht im Unternehmenskontext handeln.

Da unterscheide ich nicht mal. Was man sicher machen kann, das sollte man auch machen. Das gilt für Unternehmen und genaus so Privat.

 

[renfiela]

Das kann man durchaus kri

Da unterscheide ich nicht mal. Was man sicher machen kann, das sollte man auch machen. Das gilt für Unternehmen und genaus so Privat.

Das kann man durchaus kritisch betrachten, denn bei mir im Unternehmen werden auch sämtliche Verbindungen zwischen einem Host und einer Maria-DB mit TLS gesichert. Wenn du jedoch das im privaten Umfeld jemandem zumutest, wird er vielleicht auch daran schon verzweifeln.

Aber gut, der eine sieht es so und viele sehen es anders. Einer wird sagen postgreSQL ist gut, ich sage mariadb ist besser. Aber das führt zu keiner Lösung.

 

[Pixelschubser]

Nun gut, dein Hausmeister wird aber nicht den Docker-Container ausführen.
Eher wahrscheinlich wird es root sein und der hat eben andere uid und guid.

Prüf doch einmal, ob du mittels ssh als root (sudo -i) in den Ordner schreiben und dort auch wieder löschen kannst.

Ich hab das mal ausprobiert.

und auch in der Filestation sehe ich das

(hat etwas gedauert, war noch nie wie ssh in der Synology).

############################
Ich komme bei der Diskussion nicht so richtig mit, bin kein Profi.
Aber was mir auffällt, ihr redet von einer docker-compose.env, ich habe keine solche Datei angelegt? Im Beispiel von Marius komtm die auch nicht vor. Brauch ich die?

 

[alexhell]

Du hast die Environment, wenn ich es richtig gesehen habe, in deinem Stack mit drin. Dann brauchst du die nicht.
Kannst du das auch mit deinem Hausmeister User? Also ohne sudo -i vorher zu machen....

 

[Pixelschubser]

Ja, geht auch, habe auch als Hausmeister (Admin) dort Rechte.

 

[alexhell]

Hast du mal bei 0 nochmal angefangen? Also mal alle Ordner neu angelegt und dann neu deployed?
Sonst mal ins Terminal vom Container gehen und mit ls -la /usr/src/paperless/ gucken wem die Dateien/Ordner gehören und welche Rechte die haben. Irgendwas hakt bei dir mit den Berechtigungen.

 

[Dog6574]

Hallo.

Ich sichere die Daten von meinem NAS 1 x die Woche auf einem anderen NAS und zusätzlich macht meine SYNO ständig Snapshots.
Kann ich die Daten im von Paperless im Falle eines Datenverlustes wieder herstellen? Einen Dumo mache ich auch noch alle 24 Stunden.

Gruß,

 

[plang.pl]

Wenn du den Dump mitsicherst und alles einmal getestet hast, kein Problem

 

[Pixelschubser]

Hast du mal bei 0 nochmal angefangen? Also mal alle Ordner neu angelegt und dann neu deployed?
Sonst mal ins Terminal vom Container gehen und mit ls -la /usr/src/paperless/ gucken wem die Dateien/Ordner gehören und welche Rechte die haben. Irgendwas hakt bei dir mit den Berechtigungen.

Ich habe alles neu gemacht, neues Projekt, neuen freigegebenen Ordner.
Wenn ich es so mache geht es:

Hier der Beweis:


Wenn ich die Zeile ändere auf:

auch mit neuem freigegebenem Verzeichniss (auch vom Hausmeister/Admin) angelegt.

meckert der Paperless Container an das er ins Scanverzeichnis nicht schreiben darf.

 

[Pixelschubser]

HEUREKA

Eine kleine Änderung brachte gerade das gewünschte Ergebnis:

Bei allen Einträgen UID und GID auf 0 gesetzt und es klappt. Jetzt frisst er die Dokumente aus /volume1/ScansDSM/DSM automatisch.

Das deutet ja darauf hin das 1026 / 100 das Problem ist. Aber ich habe nochmal nachgesehen:

Kein Plan warum .

Ich habe mal gesucht, es gibt einige Beispiele die 0 / 0 verwenden, Marius nicht. Es reicht auch den Paperless Container selber auf 0 / 0 zu stellen, alle anderen haben ja kein Problem, die können auf 1026 / 100 bleiben (ausprobiert).

Wenn die 0 / 0 kein Problem ist, würde ich es einfach so lassen?

 

[Pixelschubser]

Dicken Dank an alle die mir hier geholfen haben. Ohne eure Hinweise hätte ich nei die richtige Spur eingeschlagen.

 

[alexhell]

Ich würde es nicht als root laufen lassen. Aber am Ende ist es deine Entscheidung. https://www.howtogeek.com/devops/why-processes-in-docker-containers-shouldnt-run-as-root/

Edit: was mich noch nerven würde. Probier mal eine Datei die du gescannt hast zu löschen. Nicht über paperless