After waiting awhile to make sure OH has a chance to come online. If the error persists, try stopping OH and clearing the cache (delete the contents of userdata/cache and userdata/tmp. Restart and tell us whether the problem persists.
I already did that. OH was running for like a whole night. Problem persists.
Is user ID 1000 in group 1000 & 100 or is that a typo?
When UID and GID are not set up correctly OpenHAB refuse to even start.
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ ls -nl
total 24
drwxr-sr-x+ 2 1000 100 4096 May 17 16:05 addons
drwxr-xr-x+ 13 1000 100 4096 Apr 19 15:08 conf
drwxr-xr-x+ 8 1000 100 4096 May 17 15:12 userdata
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ grep pi /etc/passwd
pi:x:1000:1000:,,,:/home/pi:/bin/bash
pi@nas:/srv/dev-disk-by-label-AData/OpenHAB/openhab $ grep users /etc/group
users:x:100:pi
Gentelmen, I appreciate the time you put in looking into those configs and your guesses and I experimented with various settings for like a week now. I think that what I need now is a solid debug path that would lead me to the root cause of the problem, not just experimenting further.
I don’t understand why I don’t see the full stack trace containing the root cause for failure. I think I need that to solve the issue. Do you know how to set up more verbose logging?
// EDIT:
Oh, I’ve looked into the code and this is very disappointing. The exception is swallowed and only the message is logged 
Why it’s done like that?
1 Like
In the Docker-compose confid you posted the OpenHAB container has the same uid as another but a different gid. That is why I asked if there was a typo in the config.
Are the owner, group, and permissions set correctly on the mounted volumes? (UID 1000 GID 100)
Maybe you need to update some OMV component that has a bug, see:
1 Like
Yeah, I also suspected permissions to be the problem but this is not the case which you can actually see from my cmdline output - 3rd column is the owner UID (1000) and 4th is the GID (100). I have also set this recursively to subfolders and files.
1 Like
Just because it is missing try adding OPENHAB_HTTPS_PORT: "8443" I doubt it will help but it is in all examples I see.
Also network_mode: host is not listed in their example docker-compose file. I know it works in my testing without it.
My OMV Extras is version 5.3.3 and they claim to have fixed it in 5.3.1. This also is not the problem I’m seeing. Docker starts ok and is pulling all the images. I’ve successfully started few other containers (all in this docker-compose file) and they are running as expected.
I’ll give this a try, but it would be surprising if this worked 
Keep in mind that this exact docker-compose.yaml file was running flawlessly on another machine.
This is my Docker Setup:
and this is my docker-compose.yml
version: "2.2"
services:
openhab:
image: "openhab/openhab:2.5.0"
container_name: openhab
restart: always
network_mode: host
volumes:
# If you are on Windows delete the /etc/localtime and /etc/timezone lines
- "/etc/localtime:/etc/localtime:ro"
- "/etc/timezone:/etc/timezone:ro"
- "${PWD}/openhab_addons:/openhab/addons"
- "${PWD}/openhab_conf:/openhab/conf"
- "${PWD}/openhab_userdata:/openhab/userdata"
environment:
OPENHAB_HTTP_PORT: "8080"
OPENHAB_HTTPS_PORT: "8443"
USER_ID: ${UID}
GROUP_ID: ${GID}
EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Berlin"
ports:
- "8080:8080"
- "8443:8443"
influxdb:
image: influxdb:latest
container_name: influxdb
restart: always
network_mode: host
ports:
- "8083:8083"
- "8086:8086"
- "8090:8090"
- "25826:25826/udp"
- "2003:2003"
env_file:
# Check the file to set default password!
- "${PWD}/env.influxdb"
volumes:
- "${PWD}/influxdb/data:/var/lib/influxdb/"
grafana:
image: grafana/grafana:latest
container_name: grafana
restart: always
network_mode: host
user: "${UID}:${GID}"
ports:
- "3000:3000"
env_file:
- "${PWD}/env.grafana"
volumes:
- "${PWD}/grafana/data:/var/lib/grafana/"
nodered:
# If you are running on RaspBerryPi change the image to
# nodered/node-red-docker:rpi
image: nodered/node-red-docker:latest
container_name: nodered
restart: always
network_mode: host
user: root
ports:
- "1880:1880"
volumes:
- ./nodered:/data
mosquitto:
image: eclipse-mosquitto:latest
container_name: mosquitto
restart: always
network_mode: host
ports:
- "1883:1883"
- "9001:9001"
volumes:
- "${PWD}/mosquitto/conf:/mosquitto/config/"
- "${PWD}/mosquitto/data/:/mosquitto/data/"
- "${PWD}/mosquitto/log/:/mosquitto/log/"
Maybe there is something useful there
@Bruce_Osborne as I suspected - this didn’t change anything.
@BrutalBirdie thanks, for sharing but I don’t think its a configuration issue. Also - why do you have network_mode: host and also ports: section? host basically means that you expose all the ports, so why bother listing the ports?
EDIT:
I’m starting to think that the only way to debug this is by forking the OpenHAB, fixing the code I linked in my previous post so it properly logs the whole exception and building the docker image from Dockerfile myself. Do you guys have other ideas?
Explicit is better then implicit
I know it does no difference but since I created this repo for new users, writing down the Ports can help users figure out how this setup works.
Yes they could read the docs or lookup netstat -tulpen or something like that but why not in the config file 
I agree on the explicit/implicit case. I’d probably remove the network_mode: host then since it does no good, and potentially may expose some unwanted ports implicitly
1 Like
Problem with that is openHAB needs network_mode: host otherwise the container can not communicate with for example Phillips HUE.
I think there was a good topic about the whole docker network_mode difference and pros and cons.
Oh, I didn’t think of that - good thing I asked, thanks 
1 Like
You can check with wget if your DNS/network config has issues by downloading an add-on from the openHAB online repo:
E.g. inside the container:
wget -O /tmp/org.openhab.ui.paper-2.5.5.jar https://openhab.jfrog.io/openhab/libs-release/org/openhab/ui/bundles/org.openhab.ui.paper/2.5.5/org.openhab.ui.paper-2.5.5.jar
Or on the host
docker exec openhab wget -O /tmp/org.openhab.ui.paper-2.5.5.jar https://openhab.jfrog.io/openhab/libs-release/org/openhab/ui/bundles/org.openhab.ui.paper/2.5.5/org.openhab.ui.paper-2.5.5.jar
That is more realistic than just pinging Google. 
Thanks for the commands. Unfortunately looks like the network configuration is not the problem:
root@aec6a27e1667:/tmp# wget -O /tmp/org.openhab.ui.paper-2.5.5.jar https://openhab.jfrog.io/openhab/libs-release/org/openhab/ui/bundles/org.openhab.ui.paper/2.5.5/org.openhab.ui.paper-2.5.5.jar
--2020-05-19 13:59:13-- https://openhab.jfrog.io/openhab/libs-release/org/openhab/ui/bundles/org.openhab.ui.paper/2.5.5/org.openhab.ui.paper-2.5.5.jar
Resolving openhab.jfrog.io (openhab.jfrog.io)... 35.231.52.82
Connecting to openhab.jfrog.io (openhab.jfrog.io)|35.231.52.82|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 935477 (914K) [application/java-archive]
Saving to: ‘/tmp/org.openhab.ui.paper-2.5.5.jar’
/tmp/org.openhab.ui.paper-2.5.5.jar 100%[=================================================================================================================================================>] 913.55K 1.10MB/s in 0.8s
2020-05-19 13:59:14 (1.10 MB/s) - ‘/tmp/org.openhab.ui.paper-2.5.5.jar’ saved [935477/935477]
This was run from inside the OpenHAB container.
Good to know. My testing was just for very basic setup & getting it running.
At least network_mod: host is the easy way.
It seams it can work without that as well, see:
But the experience I had in my specific setup was that I needed network_mode: host otherwise Phillips Hue Bridge would not work, I believe it had something to do with arping or something in the locale network.
1 Like