Paperless-ngx Paperless: Kann nach Backup kein Dokumente sehen

user32343

Benutzer
Mitglied seit
06. Jan 2024
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

ich hatte seit langem paperless ngx auf meiner DS220+ laufen, musste dieses jedoch neu aufsetzen.
Nachdem automatische Updates mit Watchtower nicht richtig funktionierten, habe ich alles neu aufgesetzt.

- Gesamtes paperlessngx Verzeichnis gesichert (leider nur eine Kopie, nicht per document_exporter Befehl)
- Verzeichnis gelöscht
- Alles gem. Anleitung von Marius neu aufgesetzt und den Stack erzeugt. https://mariushosting.com/how-to-install-paperless-ngx-on-your-synology-nas/ (s. Skript unten)
- Stack gestoppt, Backup in das Verzeichnis kopiert und Stack wieder gestartet


Problem:
Ich kann mich zwar einloggen und paperless-ngx inkl. Updates funktioniert, leider sehe ich kein einziges Dokument oder die bereits angelegten Tags/Korrespondenten etc.
Ich tippe auf ein Berechtigungsproblem, bekomme es jedoch nicht gelöst.

Im Log des paperless-ngx Containers (s.u.) erscheint "Did not create superuser, a user paperless already exists".

Verständnisfrage:
Muss das im Docker compose file angegebene Login ( hier PAPERLESS_ADMIN_USER: paperless, PAPERLESS_ADMIN_PASSWORD: paperless)
exakt dem alten superuser des Backups entsprechen oder sind dies nur Initial-Werte und es reicht wenn irgendein superuser angelegt ist.
Wie verhält es sich mit superusern die nachträglich in der paperless Oberfläche angelegt wurden?
D.h. muss ich nachträglich in der paperless Oberfläche einen superuser mit exakt der gleichen USER/PW Kombi anlegen, damit ich alle alten Daten sehe?

..schonmal danke für eure Hilfe!

Paperless-ngx docker container starting...
Creating directory /tmp/paperless
Adjusting permissions of paperless files. This may take a while.
Waiting for PostgreSQL to start...
Waiting for Redis...
Connected to Redis broker.
Apply database migrations...
Operations to perform:
Apply all migrations: admin, auth, authtoken, contenttypes, django_celery_results, documents, guardian, paperless_mail, sessions
Running migrations:
No migrations to apply.
Running Django checks
System check identified no issues (0 silenced).
Did not create superuser, a user paperless already exists
Executing /usr/local/bin/paperless_cmd.sh
2024-01-06 07:03:38,463 INFO Set uid to user 0 succeeded
2024-01-06 07:03:38,494 INFO supervisord started with pid 1
2024-01-06 07:03:39,520 INFO spawned: 'gunicorn' with pid 84
2024-01-06 07:03:39,522 INFO spawned: 'celery' with pid 85
2024-01-06 07:03:39,524 INFO spawned: 'celery-beat' with pid 86
2024-01-06 07:03:39,526 INFO spawned: 'consumer' with pid 87
2024-01-06 07:03:39,528 INFO spawned: 'celery-flower' with pid 88
Checking if we should start flower...
2024-01-06 07:03:39,564 INFO success: celery-flower entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
Not starting flower
2024-01-06 07:03:40,567 INFO success: gunicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-01-06 07:03:40,568 INFO success: celery entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-01-06 07:03:40,568 INFO success: celery-beat entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-01-06 07:03:40,568 INFO success: consumer entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2024-01-06 07:03:40,569 INFO exited: celery-flower (exit status 0; expected)
[2024-01-06 08:03:41,575] [INFO] [paperless.management.consumer] Using inotify to watch directory for changes: /usr/src/paperless/consume
[2024-01-06 08:03:45 +0100] [84] [INFO] Starting gunicorn 21.2.0
[2024-01-06 08:03:45 +0100] [84] [INFO] Listening at: http://[::]:8000 (84)
[2024-01-06 08:03:45 +0100] [84] [INFO] Using worker: paperless.workers.ConfigurableWorker
[2024-01-06 08:03:45 +0100] [84] [INFO] Server is ready. Spawning workers
[2024-01-06 08:03:47,952] [INFO] [celery.beat] beat: Starting...
[2024-01-06 08:03:48,557] [INFO] [celery.beat] Scheduler: Sending due task Check all e-mail accounts (paperless_mail.tasks.process_mail_accounts)




version: "3.6"
services:
broker:
image: redis
container_name: Paperless-NGX-REDIS
restart: always
volumes:
- /volume1/docker/paperlessngx/redis:/data

db:
image: postgres
container_name: Paperless-NGX-DB
restart: always
volumes:
- /volume1/docker/paperlessngx/db:/var/lib/postgresql/data
environment:
POSTGRES_DB: paperless
POSTGRES_USER: paperless
POSTGRES_PASSWORD: paperless

webserver:
image: ghcr.io/paperless-ngx/paperless-ngx:latest
container_name: Paperless-NGX
restart: always
depends_on:
- db
- broker
ports:
- 8777:8000
volumes:
- /volume1/docker/paperlessngx/data:/usr/src/paperless/data
- /volume1/docker/paperlessngx/media:/usr/src/paperless/media
- /volume1/docker/paperlessngx/export:/usr/src/paperless/export
- /volume1/docker/paperlessngx/consume:/usr/src/paperless/consume
environment:
PAPERLESS_REDIS: redis://broker:6379
PAPERLESS_DBHOST: db
USERMAP_UID: 1026
USERMAP_GID: 100
PAPERLESS_TIME_ZONE: Europe/Berlin
PAPERLESS_ADMIN_USER: paperless
PAPERLESS_ADMIN_PASSWORD: paperless
PAPERLESS_OCR_LANGUAGE: deu+eng
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.351
Punkte für Reaktionen
4.999
Punkte
519
Willkommen hier im Forum!
Leider ist dein Thread anscheinend irgendwie "durchgerutscht". Ich hab ihn jedenfalls nicht wahrgenommen.
Du musst dich mit den Daten anmelden, die du im Compose angibst.
Das mit den Updates ist so ein Ding. Das liegt aber nicht an paperless, sondern am Backend (der Datenbank). Postgres kann nicht ohne Weiteres einen Versionssprung machen. Danach ist evtl. die Datenbank im Eimer. Da hilft dann nur ein SQL-Dump der Datenbank (den man in einem vernünftigen Backup-Konzept ohnehin am besten automatisiert erstellen lässt). Da du in deinem Compose keinen Tag für das postgres-Image angegeben hast, wird latest genommen und der watchtower zieht das gnadenlos hoch und schrottet damit die DB. Man kann eine feste Versionsnummer als Tag setzen, damit das nicht passiert.
Ich selbst benutze aber statt postgres die MariaDB als Backend. Die hat diese Probleme nicht. Das kann man auch noch umziehen, wenn man will: https://www.synology-forum.de/threads/paperless-ngx-migration-postgresql-zu-mariadb.123727/
 

user32343

Benutzer
Mitglied seit
06. Jan 2024
Beiträge
2
Punkte für Reaktionen
0
Punkte
1
Danke für die Antwort. Das mit dem Login aus dem Compose kann ich noch nicht ganz nachvollziehen.
Wenn ich ein komplett neues Stack aufsetze und alle Ordner unter paperlessngx leere, dann kann ich mich nicht mit dem in compose angegebene PW anmelden (username&pw nicht vorhanden) sondern stattdessen nur mit einem alten Login.

Wo werden bitte die Logins gespeichert? Was ist der Unterschied zwischen dem in compose angegebenen login und den usern die in der paperless Oberfläche angelegt werden?
 

plang.pl

Benutzer
Contributor
Sehr erfahren
Maintainer
Mitglied seit
28. Okt 2020
Beiträge
14.351
Punkte für Reaktionen
4.999
Punkte
519
Der Login in der Compose ist der Initial Login. Der kann in der Oberfläche geändert werden.
Es kann aber sein, dass du zum Reset auch das Image neu pullen musst.
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat 

 
 
  AdBlocker gefunden!

Du bist nicht hier, um Support für Adblocker zu erhalten. Dein Adblocker funktioniert bereits ;-)

Klar machen Adblocker einen guten Job, aber sie blockieren auch nützliche Funktionen.

Das Forum wird mit hohem technischen, zeitlichen und finanziellen Aufwand kostenfrei zur Verfügung gestellt. Wir zeigen keine offensive Werbung und bemühen uns um eine dezente Integration.

Bitte unterstütze dieses Forum, in dem du deinen Adblocker für diese Seite deaktivierst.

Du kannst uns auch über unseren Kaffeautomat einen Kaffe ausgeben oder ein PUR Abo abschließen und das Forum so werbefrei nutzen.

Vielen Dank für Deine Unterstützung!