EcoDMS unter Docker / Portainer

Martin1968

New member
Hallo zusammen,

ich verzweifle aktuell an Docker, konkret der Installation von ecodms unter Docker bzw. Portainer.

Gibt es evtl. hier jemandem, der EcoDMS unter Docker installiert hat? Auf einer Synology habe ich das hinbekommen, als Container, unter dem "richtigen" Docker funktioniert es einfach nicht.

Gruß

Martin
 
Hallo und willkommen im Forum @Martin1968

Ich hab da so gar keine Ahnung.
Ich glaube es wäre aber hilfreich zu schreiben was nicht geht. Mehr Informationen. Dann fällt es (hoffentlich) auch leichter zu
helfen.
 
Mein Fehler, sorry, inzwischen läuft der Container, funktioniert aber noch nicht richtig. Ich werde erst mal weiter recherchieren und Euch erst wieder behelligen, wenn ich weiss was los ist ...
 
Da quäle ich mich gerade durch ... es sind wahrscheinlich mehrere Probleme, die zusammenkommen. Aktuell habe ich erkannt, dass es einen Unterschied macht, ob man im Freigabepfad ein Zeichen groß oder klein schreibt ... jetzt bin ich mit dem Mount auf dem richtigen Server .. keine Ahnung wo die Daten zuletzt gelandet sind ...

Ansonsten lese ich mich gerade ein und hoffe, dass ich es irgendwann durchdringe ..

Werde berichten, wie das ausgeht ... ob ich aus dem Fenster springe, oder der Rechner fliegt ;-)
 
Aktuell habe ich erkannt, dass es einen Unterschied macht, ob man im Freigabepfad ein Zeichen groß oder klein schreibt
Zwischen Groß- und Kleinschreibung wird durchaus unterschieden.

So wie es aussieht, ist das Docker-Image von EcoDMS anscheinend auch schwer auf Synology/QNAP getrimmt. Hatte es vorhin selbst mal kurz angeworfen, da gab es schon Geraffel mit den Pfaden, aber das lies sich relativ leicht beheben, nur das Webinterface lief nicht, von daher konnte ich auch nix dazu sagen, ob es nun richtig lief, oder nicht. Die Client-Software wollte ich mir für diesen kurzen Test jetzt auch nicht extra installieren (über welche man wohl das Webinterface aktivieren könnte?). Im Log war dann noch eine Warnung bzgl. irgendwas mit Java zu sehen, aber es war auch nur eine Warnung und kein Fehler, von daher bin ich einfach mal davon ausgegangen, dass das schon passen wird 😅

ob ich aus dem Fenster springe, oder der Rechner fliegt
Du hast Plan C vergessen... Es könnte vielleicht auch einfach funktionieren 😄
 
Oh, danke für die Mühe ... bis zum Client war ich schon, Webinterface ist nur Plan B ... und der Link ist auch nur über den Client auslesbar...Ich starte grad einen neuen Versucht ... Kommt vieles zusammen. Ein Docker in einer VM, das auf eine Freigabe zugreift, die ein OMV-Freigabeordner mappt ... irgendwann kriege ich das hin...
 
Auf einer Synology habe ich das hinbekommen, als Container, unter dem "richtigen" Docker funktioniert es einfach nicht.
Die Syno verwendet auch ein richtiges Docker, nur ist es dezent verbogen und ist 3 Major Versionen im Rückstand :)

Eine Compose Datei, die auf der Syno läuft, sollte mit kleineren Anpassungen auch auf einem anderen Host laufen. Wenn Du keine Compose Datei hast, dann kannst Du dir auf der Syno von Deinem existierenden EcoDMS Container mit autocompose eine erzeugen lassen, siehe https://forum.heimnetz.de/threads/docker-netzwerke-wiederverwenden.4197/post-44103.
 
Vielen Dank für den Hinweis auf die Möglichkeit, die Compose-DAtei zu identifizieren, schaue ich mir gleich an.

Falls jemand Langeweile hat, könnte er sich an einen Abgleich mit meinem Log machen ;-)

Code:
2024-05-03T11:49:55.562233442Z Sprache: de_DE.UTF-8
2024-05-03T11:49:55.564361657Z bind9: unrecognized service
2024-05-03T11:49:55.568360039Z ###INFO### Image wurde erzeugt: 2023-11-30-12:36:58 ###INFO###
2024-05-03T11:49:55.572280064Z user ecodms exists
2024-05-03T11:49:55.574994196Z setfacl: /srv/data: Operation not supported
2024-05-03T11:49:55.580720797Z mkdir: cannot create directory ‘/var/run/postgresql’: File exists
2024-05-03T11:49:55.602714889Z The files belonging to this database system will be owned by user "ecodms".
2024-05-03T11:49:55.602733078Z This user must also own the server process.
2024-05-03T11:49:55.602736602Z
2024-05-03T11:49:55.602780836Z The database cluster will be initialized with locale "de_DE.UTF-8".
2024-05-03T11:49:55.602790846Z The default text search configuration will be set to "german".
2024-05-03T11:49:55.602794082Z
2024-05-03T11:49:55.602796723Z Data page checksums are disabled.
2024-05-03T11:49:55.602799606Z
2024-05-03T11:49:55.604150710Z initdb: error: could not change permissions of directory "/srv/data/psql12": Operation not permitted
2024-05-03T11:49:55.610845090Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T11:49:55.649531707Z psql: error: could not connect to server: Connection refused
2024-05-03T11:49:55.649551433Z     Is the server running on host "127.0.0.1" and accepting
2024-05-03T11:49:55.649555446Z     TCP/IP connections on port 17002?
2024-05-03T11:49:55.655581570Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T11:49:55.665657747Z setfacl: /srv/data: Operation not supported
2024-05-03T11:49:55.667400520Z fixing permissions on existing directory /srv/data/psql12 ... OLD Database doesnt't exists no migration
2024-05-03T11:49:55.705819173Z ln: failed to create symbolic link '/opt/ecodms/workdir/workdir': Input/output error
2024-05-03T11:49:55.707632313Z ln: failed to create symbolic link '/opt/ecodms/log/log': Input/output error
2024-05-03T11:49:55.709121463Z ln: failed to create symbolic link '/opt/ecodms/contentstore/contentstore': Input/output error
2024-05-03T11:49:55.710834035Z ln: failed to create symbolic link '/opt/ecodms/data/data': Input/output error
2024-05-03T11:49:55.712564401Z ln: failed to create symbolic link '/opt/ecodms/ocr/ocr': Input/output error
2024-05-03T11:49:55.714285052Z ln: failed to create symbolic link '/opt/ecodms/backup/backup': Input/output error
2024-05-03T11:49:55.715981036Z ln: failed to create symbolic link '/opt/ecodms/restore/restore': Input/output error
2024-05-03T11:49:55.747048550Z Linking Scaninput to /srv/scaninput
2024-05-03T11:49:55.749592145Z mv: cannot stat '/srv/data/workdir/scaninput/*': No such file or directory
2024-05-03T11:49:55.754300649Z ln: failed to create symbolic link '/srv/data/workdir/scaninput': Input/output error
2024-05-03T11:49:55.756922182Z Linking external Backupdir to /srv/backup
2024-05-03T11:49:55.835382630Z ln: failed to create symbolic link '/srv/data/backup': Input/output error
2024-05-03T11:49:55.838263551Z Linking external Restore-Dir to /srv/restore
2024-05-03T11:49:55.902701395Z ln: failed to create symbolic link '/srv/data/restore': Input/output error
2024-05-03T11:49:55.935590624Z 2024-05-03 11:49:55.935 GMT [128] LOG:  skipping missing configuration file "/srv/data/psql12/postgresql.auto.conf"
2024-05-03T11:49:55.936410002Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T11:49:55.952774406Z Unable to connect to postgres: "could not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (::1) and accepting\n\tTCP/IP connections on port 17002?\ncould not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (127.0.0.1) and accepting\n\tTCP/IP connections on port 17002?\nQPSQL: Unable to connect"
2024-05-03T11:49:55.953053120Z Check Started...
2024-05-03T11:49:55.956504431Z ecoDMS Server startet as service
2024-05-03T11:49:55.967068730Z INFO: Using ecoDMS java:  "/opt/ecodms/ecodmsserver/Java/bin/java"
2024-05-03T11:49:57.217790179Z | 0=d 1=e 2=. 3=e 4=c 5=o 6=d 7=m 8=s 9=. 10=p 11=l 12=u 13=g 14=i 15=n 16=. 17=D 18=b 19=. 20=P 21=o 22=o 23=l 24=e 25=d 26=S 27=t 28=o 29=r 30=a 31=g 32=e 33=E 34=n 35=d 36=p 37=o 38=i 39=n 40=t 41=  42=| 43=  44=r 45=o 46=l 47=l 48=b 49=a 50=c 51=k 52=T 53=r 54=a 55=n 56=s 57=a 58=c 59=t 60=i 61=o 62=n 63=  64=| 65=  66=2 67=0 68=2 69=4 70=- 71=0 72=5 73=- 74=0 75=3 76=  77=1 78=3 79=: 80=4 81=9 82=: 83=5 84=7 85=, 86=2 87=1 88=2 89=  90=| 91=  92=W 93=A 94=R 95=N 96=| 97=  98=W 99=A 100=R 101=N 102=I 103=N 104=G 105=: 106=  107=N 108=o 109=  110=t 111=r 112=a 113=n 114=s 115=a 116=c 117=t 118=i 119=o 120=n 121=  122=s 123=t 124=a 125=r 126=t 127=e 128=d 129=!
2024-05-03T11:49:57.243452444Z | 0=U 1=n 2=a 3=b 4=l 5=e 6=  7=t 8=o 9=  10=s 11=t 12=a 13=r 14=t 15=  16=u 17=p
 
Was hast Du getan? 😅 Ich habe bei mir nur die Ordnerangaben aus dem Einzeler (https://hub.docker.com/r/ecodms/ecodms) umgeschrieben, die Ordner angelegt und danach den Container mit dem entsprechenden Image startet. Das einzige was zu bemängeln war, war eine "Warnung" (kein Fehler), dass irgendwas bald obsolet ist (glaub es war irgendwas bzgl. Java, aber nix genaues weiss ich nicht mehr).

Das Grundsystem ist bei mir auch nur ein einfaches Debian + Docker CE + Portainer, also keine Sonderlocken. Da hat es nach nach der Pfadgeschicht direkt funktioniert :unsure:
 
Ich vermute, es hängt an den Pfaden für die Dateien..

Habe eine Freigabe eingerichtet und unter /mnt/ecodms eingebunden. Zugriff von der Konsole aus klappt.

Dann hab ich dort Unterordner für
- Backup
- Restore
- Data
- Scaninput

Angelegt und in Portainer als Bind eingebunden… etwa so:

/srv/backup -> /mnt/ecodms/backup
..

Ich dachte das wäre korrekt…

Netzwerk wäre evtl. Noch ein Thema, ist aktuell als Bridge eingerichtet… hast du das anders gemacht?

Martin

P.s. heute Abend Probier ich das mal auf der console..
 
Grad getestet. Sah gut aus, bis ich gemerkt habe, dass ich das Verzeichnis für /srv/data nicht angepasst hatte. Container gelöscht, mit korrigierten Pfaden neu gestartet und nix geht mehr…

Der erste Versuch sah super aus, was wohl offenbar mit dem /srv/data-Verzeichnis zusammenhing. Die Angabe aus der Docker-Hub-Beschreibung sah folgende Zuordnung vor:

-v /volume1/ecodmsData:/srv/data

Er hat offenbarem Start des fehlerhaft konfigurierten Docker-Images den Ordner "ecodmsData" angelegt:

Code:
martin@vdocker:/volume1$ ls -all
total 12
drwxr-xr-x   3 root root 4096 Mai  3 13:43 .
drwxr-xr-x  24 root root 4096 Mai  3 13:43 ..
drwxrwxr--+  8 root root 4096 Mai  3 13:43 ecodmsData

So hat es geklappt und der Client konnte sich mit dem Server verbinden...


Meine "kaputtkorrigierte" Konfiguration sieht folgende Zuordnung vor:

-v /mnt/ecodms/data:/srv/data

wobei /mnt/ecodms eine Freigabe ist, in der sich ein Ordner "data" befindet, siehe:

Code:
martin@vdocker:/volume1$ ls -all /mnt/ecodms/
total 4
drwxr-xr-x 2 root root    0 Mai  3 13:43 .
drwxr-xr-x 4 root root 4096 Mai  2 17:31 ..
drwxr-xr-x 2 root root    0 Apr 21 17:25 _backup
drwxr-xr-x 2 root root    0 Mai  3 13:36 backup
drwxr-xr-x 2 root root    0 Mai  3 16:04 data
drwxr-xr-x 2 root root    0 Mai  3 13:43 ecodmsfileimport
drwxr-xr-x 2 root root    0 Mai  3 13:39 fileimport
drwxr-xr-x 2 root root    0 Mai  3 13:39 fileimport_move
drwxr-xr-x 2 root root    0 Mai  2 16:20 _restore
drwxr-xr-x 2 root root    0 Mai  3 13:36 restore
drwxr-xr-x 2 root root    0 Mai  3 13:46 scaninput

Wenn ich die beiden Verzeichnisse vergleiche, ergibt sich folgendes Bild:

Code:
drwxrwxr--+  8 root root 4096 Mai  3 13:43 ecodmsData
drwxr-xr-x   2 root root    0 Mai  3 16:04 data

Der Name dürfte keine Rolle spielen, da das im Container ja über /srv/data angesprochen wird ... für die restlichen Angaben fehlt mir ehrlich gesagt der Background :-(

Kann mir jemand von Euch erklären, wie sich die Verzeichnisse hinsichtlich der Rechte unterscheiden ?

Martin





Code:
2024-05-03T16:04:31.198228775Z
2024-05-03T16:04:31.198230964Z The database cluster will be initialized with locale "de_DE.UTF-8".
2024-05-03T16:04:31.198233725Z The default text search configuration will be set to "german".
2024-05-03T16:04:31.198236600Z
2024-05-03T16:04:31.198238772Z Data page checksums are disabled.
2024-05-03T16:04:31.198240927Z
2024-05-03T16:04:31.199706889Z fixing permissions on existing directory /srv/data/psql12 ... initdb: error: could not change permissions of directory "/srv/data/psql12": Operation not permitted
2024-05-03T16:04:31.206807301Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T16:04:31.246357678Z psql: error: could not connect to server: Connection refused
2024-05-03T16:04:31.246377898Z     Is the server running on host "127.0.0.1" and accepting
2024-05-03T16:04:31.246381523Z     TCP/IP connections on port 17002?
2024-05-03T16:04:31.252417837Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T16:04:31.259473648Z setfacl: /srv/data: Operation not supported
2024-05-03T16:04:31.261355372Z OLD Database doesnt't exists no migration
2024-05-03T16:04:31.334132334Z Linking Scaninput to /srv/scaninput
2024-05-03T16:04:31.336702914Z mv: cannot stat '/srv/data/workdir/scaninput/*': No such file or directory
2024-05-03T16:04:31.340815159Z ln: failed to create symbolic link '/srv/data/workdir/scaninput': Input/output error
2024-05-03T16:04:31.343333090Z Linking external Backupdir to /srv/backup
2024-05-03T16:04:31.345870058Z mv: cannot stat '/srv/data/backup/*': No such file or directory
2024-05-03T16:04:31.349755424Z ln: failed to create symbolic link '/srv/data/backup': Input/output error
2024-05-03T16:04:31.352321068Z Linking external Restore-Dir to /srv/restore
2024-05-03T16:04:31.354787052Z mv: cannot stat '/srv/data/restore/*': No such file or directory
2024-05-03T16:04:31.358909845Z ln: failed to create symbolic link '/srv/data/restore': Input/output error
2024-05-03T16:04:31.361250045Z Linking external fileimport-Dir to /srv/fileimport
2024-05-03T16:04:31.363739252Z mv: cannot stat '/srv/data/fileimport/*': No such file or directory
2024-05-03T16:04:31.367879169Z ln: failed to create symbolic link '/srv/data/fileimport': Input/output error
2024-05-03T16:04:31.370245247Z Linking external fileimport_mov-Dir to /srv/fileimport_move
2024-05-03T16:04:31.373119428Z mv: cannot stat '/srv/data/fileimport_move/*': No such file or directory
2024-05-03T16:04:31.377133798Z ln: failed to create symbolic link '/srv/data/fileimport_move': Input/output error
2024-05-03T16:04:31.406175299Z 2024-05-03 16:04:31.405 GMT [145] LOG:  skipping missing configuration file "/srv/data/psql12/postgresql.auto.conf"
2024-05-03T16:04:31.407066236Z pg_ctl: directory "/srv/data/psql12" is not a database cluster directory
2024-05-03T16:04:31.411599107Z Check Started...
2024-05-03T16:04:31.417597361Z Unable to connect to postgres: "could not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (::1) and accepting\n\tTCP/IP connections on port 17002?\ncould not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (127.0.0.1) and accepting\n\tTCP/IP connections on port 17002?\nQPSQL: Unable to connect"
2024-05-03T16:04:31.419790679Z ecoDMS Server startet as service
2024-05-03T16:04:31.426295634Z INFO: Using ecoDMS java:  "/opt/ecodms/ecodmsserver/Java/bin/java"
 
Es tut mir leid, ich gehe Euch wahrscheinlich tierisch auf die Nerven, aber ich komme nicht wirklich weiter...

Habe nun ein Docker-Volume angelegt, das per CIFS-Treiber auf den gemounteten Pfad zugreift. Den Docker-Internen Mountpunkt habe ich gefunden, als root auf der Docker-Maschine gefunden und geprüft, ob er im selben Verzeichnis ist, wie ich angenommen habe, das hat geklappt.

Habe dann das /srv/data auf das Volume umgebogen und anschließend den Container neu erzeugt, nachdem ich die alten Dateien in dem Verzeichnis / Volume gelöscht habe ... das hat aber nichts gebracht, es kommt immer noch die Fehlermeldung, das Postgre-SQL nicht funktioniert.

Code:
2024-05-03T16:04:31.417597361Z Unable to connect to postgres: "could not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (::1) and accepting\n\tTCP/IP connections on port 17002?\ncould not connect to server: Connection refused\n\tIs the server running on host \"localhost\" (127.0.0.1) and accepting\n\tTCP/IP connections on port 17002?\nQPSQL: Unable to connect"

Versuche jetzt nochmal den Netzwerk als host, und dann reicht es mir für heute .. Bis die Tage ..

Martin
 
Kleiner Tipp: der Unterschied zwischen dem Syno-Setup und dem "echten" Docker-Host ist, dass die Daten auf der Syno lokal gespeichert wurden. Wenn die Daten lokal auf dem Docker-Host liegen würde, dann würde es da genauso funktionieren.

Die Postgres wird mit CIFS Shares nicht gehen. Mit nfsv4 dagegen läuft es stabil (auch wenn Remote Shares von Postgres explizit nicht empfohlen werden). Kann aber auch gut sein, dass irgendeine Komponente in dem Container eine Dateisystem-Funktion benötigt, die bei Remote-Shares gar nicht existiert, sodass die Gesamtlösung über Remote Share dann nicht benutzbar wäre.
 
Und ich dachte, Docker wäre eine Lösung um die Installation von Programmen in ihrer Komplexität zu reduzieren ;-) Ich will eigentlich die persistenten Daten aus der Docker-VM raushalten, deswegen der "Umweg" über eine Freigabe ... aber NFS ist ja ein Test, Postgre (Mein Mac macht da immer Poster draus ;-)) kennt ich leider garnicht, schon überhaupt nicht auf Protokollebene...

Die Synode-Installation ist aber imho keine Installation auf dem lokalen Host, sondern auf einer Freigabe auf dem selben Gerät, oder irre ich da ?

Morgen noch ein Versuch, dann überlege ich zum Paperless-NGX zu wechseln, auch wenn das bedeutet tausende PDFs manuell neu abzulegen ...

Gute Nacht und vielen Dank für Eure Mühen und Eure Unterstützung!

Martin
 
Eine NFS-Freigabe.. da muss man doch die IP des zugreifenden Clients quasi "erlauben" - ist das die des Docker hosts oder kommuniziert er über die IP die der Docker-Container im Portainer anzeigt?
 
Und ich dachte, Docker wäre eine Lösung um die Installation von Programmen in ihrer Komplexität zu reduzieren ;-) Ich will eigentlich die persistenten Daten aus der Docker-VM raushalten, deswegen der "Umweg" über eine Freigabe
Wenn Anwendungen persistente Daten auf Remote Shares unterstützen, dann werden sie es in einem Container auch noch können... Und wenn sie damit nicht umgehen können, dann wird sich das im Container auch nicht ändern.

Das EcoDSM Image ist auch nicht wirklich nach Docker Best-Practice aufgebaut: dadurch laufen mehrere Anwendungen, die eigentlich als separate Container laufen müssten, in einem Container.

Die Synode-Installation ist aber imho keine Installation auf dem lokalen Host, sondern auf einer Freigabe auf dem selben Gerät, oder irre ich da ?
"Installation auf dem lokalen" Host ergibt im Kontext von Docker keinen Sinn. Da wird nichts installiert, außer die Docker Engine selber, bzw. auf der Syno der Container Manager der die Docker Engine mitinstalliert. Einen Container erzeugt man auf Basis eines Images - es nur ist eine wegwerf Laufzeit-Instanz des Images.

Bzgl. Freigabe: Du irrst Dich. Der Container Manager zeigt zwar nur Dateifreigaben an, aber wenn man sich mit sudo docker inspect <container name oder id> die Konfiguration ansieht, dann steht da der absolute Pfad im Dateisystem drin. Die UI erlaubt auch nur Binds, sprich: mappen von Host Verzeichnissen in Container Verzeichnisse. Wenn es wirklich mit Freigaben arbeiten würde, dann wären entsprechende Named Volumes in Docker registriert die auf einen NFS/CIFS Remote Share zugreifen müssten. Die würden dann mit sudo docker volume ls gelistet werden...

Eine NFS-Freigabe.. da muss man doch die IP des zugreifenden Clients quasi "erlauben" - ist das die des Docker hosts oder kommuniziert er über die IP die der Docker-Container im Portainer anzeigt?
Es muss die IP vom Docker Host freigegeben werden, da die Docker Engine die Dateifreigabe auf dem Host als Volume mountet, und dann erst in den Container bindet. Alternativ kann man auch das ganze LAN-Segment freigeben.

Es gibt halt Anwendung/Services die spezielle Dateisystem Features benötigen, die mit Dateifreigaben nicht verfügbar sind. Das sollte aber in der jeweiligen Doku der Anwendung bzw. der entsprechenden Teilkomponente (=bspw. postgres) zu finden sein.
 

Zurzeit aktive Besucher

Letzte Anleitungen

Statistik des Forums

Themen
4.657
Beiträge
47.602
Mitglieder
4.302
Neuestes Mitglied
Cheffe
Zurück
Oben