Update in Proxmox LXC - ppl 2.18.4 (Debian 12) auf ppl 2.19 (Debian 13)

paperless-ngx
1

Hallo zusammen,

ich hab unter Proxmox in einem Debian 12 LXC die Paperless-Version 2.18.4 erfolgreich laufen.
Wurde anfangs über die Proxmox Helper-Scripts installiert.

Jetzt wäre zwar Paperless in Version 2.19 verfügbar, aber mit weitreichenden Änderungen am System selber.

Das interne LXC Update bricht mit Fehlermeldung ab:

:check_mark: Checking for update: paperless
:check_mark: Stopped all Paperless-ngx Services
⠸ Backing up datacp: cannot access ‚/opt/paperless/media/#recycle‘: Permission denied
⠦ Backing up data
[ERROR] in line 40: exit code 0: while executing command cp -r /opt/paperless/media /opt/paperless/backup/

root@paperless-ngx:~#

Das Verzeichnis /opt/paperless/media liegt nicht innerhalb des LXC-Containers, sondern ist ein Mountpoint, der auf der Synology liegt.
Ist eine separate Partition, die nur für Paperless da ist, mit separatem User.
Nur dieser hat auch Schreibrechte.
Alle anderen User haben nur Leserechte, um das ppl-Archiv konsistent zu halten.

Ich hab auch probiert, über die sources.list auf Debian 13 Trixie ein Dist-Update zu machen.
Das Update lief durch und ich komm auch auf die Paperless-GUI.
Während des Updates wurde auch ein Update von Postgresql 15 auf 17 gemacht.

Jetzt hab ich ein lauffähiges Debian 13.1 mit Postgresql 17.6.
Allerdings ist die ppl-Version immer noch 2.18.4.

Diesen Stand hab ich auch erstmal mit einem Proxmox-Backup eingefroren.

Wenn ich jetzt “update” starte (das Update-Script von der Helper-Scripts-Seite) lande ich wieder bei einem gebrochenen System (Web-GUI ist nicht mehr erreichbar), auch wieder mit o.g. Fehlermeldung.

Weiß jemand von euch, wie man den LXC-Container sauber hochzieht?
Eigentlich möglichst so, dass das Update-Helper-Script auch wieder läuft :wink:

Danke und viele Grüße,
Martin

PS: was ich noch nicht probiert habe, ist, das Helper-Script im verbose-Mode zu starten, um evtl. mehr Rückfragen zu erhalten. Das schaffe ich aber heute nicht mehr.

2

das Problem sind ja wahrscheinlich nicht irgendwelche Veränderungen in Paperless von 2.18 auf 2.19, die das jetzt verursachen. Da sind die Unterschiede nicht groß genug. Klingt eher, als wäre die Kombi aus diesem nicht-lokalen (auf den Container bezogen) Pfad und dem Helperscript. Das ja hier auf digitalisierung-mit-kopf eh etwas “daneben” ist. Hier wird ja eigentlich eine eigene Installation mit selbsterstellter docker config usw. propagiert und supported.

Wenn Du also ein Setup über das Helperscript erzeugt hast, ist das ja ganz anders aufgesetzt als die Installationen von “hier”.

Hat denn bisher das mit dem “update” per Helperscript funktioniert, um z.b. bis zu Paperless 2.18.4 zu kommen? Mich wundert, warum da jetzt beim Wechsel auf 2.19 was schief laufen soll, da das eigentlich ein ganz simpler Vorgang (bezogen auf Paperless selbst!) ist. Bei mir hat ein normales manuelles Ziehen der neuen Container ausgereicht. Also:

docker compose down
docker compose pull
docker compose up -d

und schon war Paperless wieder online mit der neuesten Version.

Ich vermute mal eher, daß das “update” übers Helperscript noch mehr im Hintergrund verändert hat oder will, was gar nix mit dem Update von Paperless selbst zu tun hat.

Wenn jetzt alles andere soweit läuft mit dem Container mit Trixie und Paperless 2.18, dann bringt Dich ein manuelles Update über obige Befehle auf jeden Fall auf die neueste Version. Aber “update” per Helperscript klappt dann natürlich dauerhaft erstmal nicht mehr, bis Du rausgefunden hast, was zwischen Helperscript-Voraussetzung und Deinem Spezialsetup mit dem Synology-Mountpoint verkehrt ist. Vermutlich darf das Helperscript halt einfach mit seinen Root-Rechten nicht auf den Pfad aufm Synology zugreifen, weil dafür ja wie Du sagst ein extra User angelegt ist.

Zusammengefasst: Paperless 2.19 erzwingt keinen massiven Systemwechsel! Wo 2.18 lief, sollte auch 2.19 laufen. Alles was an anderen Änderungen kommt, liegt am Helperscript und nicht an Paperless.

3

Ihr rede hier alle aneinander vorbei. Entweder aus Unwissenheit oder wegen nicht ganz gelesenen Thread.

Docker ist was ganz anderes wie LXC. Ja beides sind Container und zählen somit zur Technologie Containerisierung aber das war es dann auch schon.

  • LXC: Tool zur Nutzung von Kernel-Features zur
    Prozessvirtualisierung (Container)
  • Docker bietet ein Framework zur einfacheren Verwaltung
    von Containern (ursprünglich auf LXC-Basis)
  • Docker enthält Tools zum Bauen und Verwalten von Images
  • Docker ist spezifisch darauf ausgerichtet, Applikationen zur
    Verfügung zu stellen:
    1 Applikation = 1 Container
  • Docker nutzt eine Layertechnik mit
    Copy-on-Write-Verfahren für die unterschiedlichen
    Containerzustände

Beim LXC baust Du einmal aus einem Template den Container auf und kannst ihn dann wie ein normales OS + Application pflegen. Der Container beinhaltet auch oft die Nutzdaten. Man kann aber auch mittels bind mount die Nutzdaten auf den Host mappen und kann dann immer einen neuen Container aus einem aktuellen Template bauen.

Diese komischen Helper Scripts gehen da noch etwas weiter, das ist wie ein System aufbauen zum Beispiel mit terraform und die Anwendung nachziehen, installieren und konfigurieren mittels Ansible. Die Helper Scripts machen das alles in Bash mit Proxmox API Aufrufe.

4

Ah, danke Dir. Bin irgendwie davon ausgegangen, dass das Helperscript einen Basis-Debian-LXC nimmt, darauf dann Docker installiert und da dann per Docker Compose Paperless installiert. Aber klar, grad mal nachgeschaut, das Helperscript installiert das ja “nativ” im Container, nicht nochmal in Docker verpasst. Das war mein Denkfehler. Die Grundunterscheidung von LXC und Docker ist mir sehr wohl bewusst und bekannt, hab nur aufgrund meiner eigenen Installation diese Kombi angenommen, blöd. Danke für die Korrektur.

Im Fazit hat dann aber natürlich die Helperscript-Variante noch viel weniger mit der hier propagierten Installationsart zu tun und die Ausgangsfrage wäre vermutlich im Github-Forum der Helperscripte besser aufgehoben als hier.

1 „Gefällt mir“
5

Frage mich gerade ernsthaft was an meinem Beitrag so schlimm war das er geblockt wurde. Kann mir ein Admin bitte kurz erklären was ich falsch gemacht haben soll. Danke.

@Stefan

6

Erschließt sich mir auch nicht. Das war ja ein wichtiger Hinweis, daß meine erste Antwort von nem ganz anderen Setup ausgegangen ist und dadurch in Teilen falsche Hinweise gab. Klang durch die Erläuterung natürlich etwas “lehrerhaft”, aber besser so und richtig erklärt, daß da aneinander vorbeigeredet wurde, als es unkommentiert zu lassen oder so.

1 „Gefällt mir“
7

@CoolTux Der Beitrag wurde gemeldet, ich habe ihn soeben aber wieder freigegeben. Ich kann kein Problem mit dem Beitrag erkennen. War möglicherweise ein Versehen.

8

Lieben Dank @Stefan

Einen schönen Abend gewünscht

9

Sehr gerne, das wünsche ich dir / euch ebenso!

10

Danke für eure rege Beteiligung.

Ich hatte bei dem Update-Prozess zwei Fehler gemacht.
a) ich hab lediglich “update” eingegeben, um das Update zu starten. Hab jetzt den kompletten “bash… curl…”-Aufruf ausgeführt und damit evtl. das Update-Skript neu gezogen/aktualisiert.

b) hab vorher den Synology-Mountpoint auf das media-Verzeichnis ausgehängt.
Somit kam keine “Permission denied” Fehlermeldung.

Ich hab jetzt ppl 2.19.1 auf Debian 13 mit Postgresql 17.6.
Das einzige ist, dass mir LXC immernoch Debian 12 auf der Start-Konsole anzeigt. Ist aber nur kosmetischer Natur - wenn ich die Versionen überprüfe, wird mir 13/17.6 angezeigt.

11

Ich habe mit/seit dem Update auf jede der neuen V2.19.x Versionen auch Probleme. Paperless an sich funktioniert, aber document_sanity_checker und document_exporter haben mit z.B. folgender Fehlermeldung ihren Dienst eingestellt:

image
image2292×1426 324 KB

Gehe ich wieder zurück auf V2.18.4 funktioniert beides tadellos. Ich habe ebenfalls einen LXC Container unter Proxmox via Helper Scripts installiert und bisher ohne Probleme betrieben.

Sollte das bei jemanden unter ähnlicher Konfiguration mit der 2.19er Version noch funktionieren, wäre eine Rückmeldung schön. Dann weiß ich das es irgendwie an mir liegt. :wink: Danke.

12

Ich selbst nutze die LXC-Scripte nicht, aber nur um zu verstehen: Rein aus Unabhängigkeits-Sicht wäre es, wenn man LXC nutzen möchte, doch fast einfacher, einfach Docker im LXC zu installieren, ab da funktioniert jede Anleitung für paperless-ngx. So macht man sich davon abhängig, dass der Ersteller des Scriptes immer ein Update-Script pflegt.

Nachteil wäre: Es muss ein priviligiertes LXC sein und Nesting aktiviert haben. Ist das der Grund?

Edit: Mit Podman würde es auch unpriviligiert gehen.