# Openhab Docker image starts "unhealthy" **URL:** \ **Category:** Installation\ **Created:** [May 13, 2024, 11:51am UTC](https://community.openhab.org/t/openhab-docker-image-starts-unhealthy/155943 "2024-05-13T11:51:23Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Sulla](https://community.openhab.org/letter_avatar_proxy/v4/letter/s/6bbea6/32.png) [@Sulla](https://community.openhab.org/u/Sulla)\ **Post date:** [May 13, 2024, 11:51am UTC](https://community.openhab.org/t/openhab-docker-image-starts-unhealthy/155943/1 "2024-05-13T11:51:23Z")
Dear all! I want to move my OH installation from a dedicated Raspberry Pi to an already running x64 debian server (that already runs various things like samba, postfix, dovecot, tvheadend, oscam, dlna…). On my debian 12 bookworm I installed docker and tried to get the openhab up and running according to [https://www.openhab.org/docs/installation/docker.html](https://www.openhab.org/docs/installation/docker.html) and [https://hub.docker.com/r/openhab/openhab/](https://hub.docker.com/r/openhab/openhab/) My starting command is: ```auto sudo docker run \ --name openhab \ --net=host \ -v /etc/localtime:/etc/localtime:ro \ -v /etc/timezone:/etc/timezone:ro \ -v /srv/docker/openhab/conf:/openhab/conf \ -v /srv/docker/openhab/userdata:/openhab/userdata \ -v /srv/docker/openhab/addons:/openhab/addons \ -d \ -e USER_ID=998 \ -e GROUP_ID=997 \ -e CRYPTO_POLICY=unlimited \ --restart=always \ openhab/openhab:latest-debian ``` but the docker image starts “unhealthy”, as `sudo docker ps -a` tells me. A quick look into the logfile `/srv/docker/openhab/userdata/logs/openhab.log` reveals: ```auto 2024-05-13 12:50:06.625 [ERROR] [j.pax.web.service.internal.Activator] - Unable to start Pax Web server: Failed to bind to /0.0.0.0:8080 Caused by: java.net.BindException: Address already in use 2024-05-13 12:50:08.870 [WARN] [org.openhab.core.net.NetUtil] - Found multiple local interfaces - ignoring 192.168.8.2 ``` That IP 192.168.8.2 is the (external) IP of my debian server on the intranet. This will most likely be due to the fact that this same debian machine is already running a docker image of pihole that also happens to listen to port 8080 (ie to 192.168.8.2:8080). As a note, the openhab docker container does not answer sensibly on https port 8443 either. Now, forgive me, I am not a docker expert, but as the installation instruction in [https://www.openhab.org/docs/installation/docker.html](https://www.openhab.org/docs/installation/docker.html) says, the option `--net=host` should make the specification of port mapping obsolete, and indeed, if i specify `-p 8081 \` in the startup command this gets ignored: `WARNING: Published ports are discarded when using host network mode`. However, me thinks I don’t understand the net=host option sufficiently, I still have a feeling that I should remap the conflicting ports between pihole and openhab, but I don’t really know how to specify this correctly in the docker run command. Which ports would I have to map to get all openhab components working, ie Log-Page, MainUI (I think MainUI uses 8080), Sitemaps, Samba-Shares, persistence-services… I think I could also use a different port for the webinterface of the pihole image, actually I already map the ports external-8080 to pihole-80 (in the pihole yml file), I could just map external-8081 to pihole-80 and leave external-8080 to openhab-8080? Thanx, Sulla ---
**Author:** ![Sulla](https://community.openhab.org/letter_avatar_proxy/v4/letter/s/6bbea6/32.png) [@Sulla](https://community.openhab.org/u/Sulla)\ **Post date:** [May 13, 2024, 1:32pm UTC](https://community.openhab.org/t/openhab-docker-image-starts-unhealthy/155943/2 "2024-05-13T13:32:36Z")
Like Einstein said: Recognising the problem is more important than finding the solution. This is because a precise analysis of the problem almost automatically leads to the right solution. Instead of mapping the ports with `- p 8081:8080` which is ignored when specifying `--net=host` I used the environment variable `-e OPENHAB_HTTP_PORT=8081` and openhab docker now starts in a “healthy” state. However, this environment variable solved only this specific port 8080 conflict (and there is another one to solve 8443 conflicts), however there remain a great many ports that cannot be remapped with environment variables. Should one of the other great many openhab ports conflict with an existing service (eg the logging port 9001), there still is no solution that keeps the `--net=host` option that seems so very important for the good functioning of openhab. This is not an ideal situation. ---
**Author:** ![JimH](https://community.openhab.org/letter_avatar_proxy/v4/letter/j/a4c791/32.png) [@JimH](https://community.openhab.org/u/JimH)\ **Post date:** [May 13, 2024, 1:52pm UTC](https://community.openhab.org/t/openhab-docker-image-starts-unhealthy/155943/3 "2024-05-13T13:52:36Z")
You can use OPENHAB\_HTTPS\_PORT= to reassign the HTTPS port. ---
**Author:** ![rlkoshak](https://community.openhab.org/user_avatar/community.openhab.org/rlkoshak/32/75251_2.png) [@rlkoshak](https://community.openhab.org/u/rlkoshak)\ **Post date:** [May 13, 2024, 3:48pm UTC](https://community.openhab.org/t/openhab-docker-image-starts-unhealthy/155943/4 "2024-05-13T15:48:42Z")
> [@Sulla](#): > > Should one of the other great many openhab ports conflict with an existing service (eg the logging port 9001), there still is no solution that keeps the > `--net=host` > option that seems so very important for the good functioning of openhab. > > This is not an ideal situation. The openHAB Docker image doesn’t provide Frontail. It doesn’t provide any “logging port” so you don’t have to worry about 9001. If you are using Frontail you can change the port on that service’s configuration. Except for the LSP port 5007, the rest of the ports that OH opens are standard autodiscovery/multicast/upnp type ports plus a few special ports that individual bindings may open. If you’ve something already running on that machine opening those ports, that stuff in OH isn’t going to work anyway so you may as well not use `--net=host` and map the the ports you need yourself, nmot expose the rest and forego a some network discovery capabilities in OH.