Wenn die default "bridge" von Docker die Range 172.17.0.0/16 verwendet, dann kann es keine Kollision mit der Host-Range von 172.16.0.0/24 geben.
Sicher das die Firewall Kommunikation von und nach 172.17.0.0/16 erlaubt?
Ansonsten wäre es mal sinnvoll die Logs in einem gute verdaubaren Format zu liefern. Wenn man sich per ssh mit dem Terminal verbindet, kann man die logs mit
sudo docker logs openproject > /volume1/docker/openproject.log
erzeugen lassen, sie aus dem docker-Share rauskopieren und die dann hier im Forum anhängen.
An der Berechtigung der Verzeichnisse
/volume1/docker/openproject/pgdata
und
/volume1/docker/openproject/assets
kann es nicht liegen, da der Container beim Start die Berechtigungen selbst glatt zieht.
Wenn die DS einen Kernel 3.10.x Kernel hat, dann wird es daran liegen, dass der Kernel die benötigt Variante /dev/urandom Device nicht unterstützt. Dann sehen die Fehlermeldungen in den Logs so aus, wie in
diesem GitHub-Issue.
Auch das kann man über das Terminal herausfinden:
uname -r
. Wenn noch nicht das aktuellste DSM-Update eingespielt ist, könnte es helfen. Wenn die DS bereits einen Kernel > 4.x hat,
Code:
-e OPENPROJECT_HOST__NAME=localhost:32796
Kann nicht korrekt sein. Hier sollte der Hostname oder die IP stehen, die beim Aufruf in der URL im Browser eingetragen wird. Das wird eher
ds-ip:32796
,
ds-hostname:32796
sein. Localhost wäre hier nur korrekt, wenn der Browser auf demselben Gerät ausgeführt wird, auf dem Docker läuft... Sprich: wenn man Docker Desktop verwendet oder Docker-CE auf einem Linux System mit Desktop - überall anders ergibt localhost keinen Sinn.