I’m following the instructions here but running into permission issues:
The user id passed to “–user” is actually 999, and then start_debug.sh says “java.io.FileNotFoundException: /openhab/runtime/system/org/ops4j/pax/web/pax-web-api/4.3.0/pax-web-api-4.3.0.jar (Permission denied)”. Attaching to the container, and I can see inside the container the system creates an user whose user id is 9001, and all the directories under /openhab/runtime are only writable by that user.
New issue I’m running into. Anyone else using Docker to run multiple other apps, specifically ones like Plex that may be utilizing a mapping to port 1900? This is causing me issues with Hue Emulation. If I run the Plex container first, it beats out OH2 from locking down the port for use. If I start OH2 first, Plex fails to start. So I find myself having to down OH2 so I can get the Echo to update the list of devices through the Hue Emulation bridge, then down OH2, up Plex again, then up OH2.
It’s an annoying process more than anything as a workaround. I found this issue: https://github.com/openhab/openhab2-addons/issues/698 which is relevant and outlines the same problem I’ve seen. The difference is this is relevant to two plugins I believe conflicting, whereas I have 2 different applications on a single host conflicting. Anyone finding a similar issue? My OpenHAB.log is being flooded with the error relevant to the port being in use.
I’ve not seen the same issue but can you use port mapping to move OH or Plex to another port? Or are these well known ports applications are expecting to look for?
I run Plex in Docker too and have no idea what port 1900 is for and what would happen if you moved it to some other port or blocked it.
If you are running OH with --net=host you have fewer opportunities to move the Hue emulation port in this way.
@rlkoshak - I believe it’s port 1900 and I believe it’s a standard for UPNP for a lot of things unfortunately. In this case, it’s more important to me to have my Plex discoverable than my Hue bridge exposed, but I also want to get HomeKit running, and I suspect this is causing me woes there as well.
I don’t like using Host mode unless I have to. So for now I’ve got Plex mapped to port 1900 already, so mapping OH as well won’t work. I’m going to try just testing if using a different port # will work, but I believe these apps rely on the receiving port to be 1900. Just as if you were sending mail, you’d expect it on 25. Telling the app differently doesn’t seem as easy. I’m no guru though with UPnP so we shall see.
I myself just ran into these issues with my install. Clearly there was a very recent change to the image where now the default user it runs as is openhab which has an ID of 9001 inside the container. Unfortunately most OH users do not have a 9001 user and because the default permissions tend to not give world read the openhab user inside the container does not have permission to read/write the files.
See the following:
The tl;dr: create an openhab user on your host with ID 9001 or give world read/write on the openhab directories and files that get mounted into the container.
My docker host is on 192.168.1.4 and now my OH2 install runs on 192.168.1.7. One thing to note is that my OH2 install can’t speak to the host over IP. My plex server is also setup the same way on a different IP, and OH2 and plex can talk to each other.
@obbers - I just discovered this new supported network type. I’ve seen macvlan and ipvlan - though I’m sorting out which will work better in my environment. For my case, I’m running my docker host on ESXi - which I believe I read somewhere that macvlan will not work properly in a virtualized environment, so it may be ipvlan i need to work with.
Either way, it’s good to hear this has been successful for you. I’m wondering how well the system works if Plex is on the regular bridge network and OH on the macvlan/ipvlan network. The only reason I don’t like the idea of the vlan network types, is because then EACH app will have it’s own IP. Currently I like having one IP with various ports for the services (plex, plexrequests, openhab, unifi-controller, plexpy, etc). Eventually I’ll get to using nginx to proxy everything anyway, so then I won’t be exposing the other apps at all.
One question - have you seen documentation for using these drives with Docker compose? I can’t seem to find any, and that’s my method of spinning up containers currently. I usually try to mimic the levels I’d expect in the yaml file, but I’d rather official documentation. And have you found that you MUST assign the IP or the container just auto-assigns the next IP in the range? This was a disappointing find in one my tests is that the container won’t use DHCP from the gateway assigned. I’d rather this so that all my IP reservations can be done through my PFsense box.
I don’t really deal with docker compose (I probably should). But I can’t imagine docker create doing anything you can’t do in compose.
I’ve seen some hacky things to DHCP that I didn’t like that involved a busybox container for each app container, but other than that, I havent come across a way yet. I
I’m in the same boat as you though. OH+Plex+Unifi is a tough docker combination.
@christoph_wempe - no that’s the main goal as obbers pointed out. You gain the ability to treat the docker container as if it was it’s own host/ip address. The beauty here, is you can use normal firewalling capabilities to protect/open/expose different apps. It also eases things like UPnP (auto discovery) in apps. The main benefit I like of this vs using Host is twofold: 1 - you get separation from the actual host networking so someone can’t by default gain access to the host through this exposure, 2 - you don’t have as much concern about conflicting port assignments either - so if you have multiple apps trying to run on 443/80 - you don’t have to give them all oddball port numbers mapped to the standard port (81:80, 82:80, in docker create/compose).
@obbers - ya I know it must be possible, all compose does is call the create commands. For me, I love it because as I start building out each new service/app I run - it allows you to easily change the docker create command without having to through the usual docker stop, docker rm, docker volume rm, etc - just a simple docker-compose up -d name, and it re-creates the container with the modifications applied in tow. That and it makes it easy when I go through mucking around with things or when I change host later, etc. I encourage use of compose, it’s simplified many things for sure. I don’t want to bear all the “details” of the services, but I’ve got about 12 different containers running my apps, so UPnP and port conflicts are becoming more prevalent!
So just a followup - I can confirm that this successfully works and solves my issue with the conflicting UPnP port problems as well. Now my Plex container is running happily on the Bridge, while my OH container is running on the macvlan network. It has it’s own exposed ports and no need to even specify the ports anymore in the compose file.
2 Caveats to point out:
If you’re running ESXi and your Docker Host is a VM inside - you will need to enable Promiscuous mode on the Port Group. By default Forged Transmits and Mac Changes are allowed, but promiscuous mode allows the packets to get to the VM if the MAC doesn’t match the receiving VM (in this case the Docker Host).
I still haven’t identified or figured out how to create the macvlan network in the compose file, so for now I’ve followed the instructions on just creating a network outside of compose, then using the Networks top-level key to specify this network as an External, named it, then specified this network under the openhab Service key.
And if you’re looking to specify you’re own IP in the compose file, put a sub-key under the Networks section for ipv4_address and specify the IP. This will make sure you get a static mapping, and that you don’t conflict with DHCP ranges potentially on your production network.
Next up is to see if I can get OH to appear/work under the Muximux app so I can have all my apps viewable from one page!
Following up to help anyone else looking for the Compose formatting. I finally had a kind soul point out what I was missing in the formatting on Reddit, and was able to successfully get this network config into my Compose file. Formatting below as a sample - this will allow setting up a macvlan based network in your docker host, along with the ability to specify a manual IP address for the system - this will let you have less problems with your UPnP based integrations and potential port conflicts on said services.
If I do an update of the docker image as described here, rules and items are not working. I tried to force a reload using touch on the files, but it only says something like “Refreshing model ‘home.items’”. Nothing more. I really have to open every file in an editor, change it and save it again.
Is someone experiencing similar problems? Is there another solution to my problem?
I’m both new to docker and openhab so as you can imagine I’m hopelessly lost at this point. I’m very familiar with linux so I’m not a total loss. One thing that has frustrated me and is leading me to abandon this entire docker concept is how convoluted it seems to be. I want to be able to ssh into it and make changes and such, but I have not been able to do so. All of these things you are talking about doing in this thread are not available to me running a docker image in my freenas box. I’m thinking I will just set up individual VM’s for my needs and be done with this idea. Can someone shed light on how I can simply ssh into my docker container let alone make changes to the mqtt.conf so I can have openhab recognize my mqtt container? It’s escaping me at the moment despite my best efforts.
Docker is not designed to work that way. It is considered a bad practice to be able to ssh into a running container.
First of all realize there are two things of concern, Images and Containers. Think of the Image as the contents of a hard drive. That is where you make changes you want to persist. But just like a hard drive, Images are inert.
A Container is like a program that has been loaded into memory and is executing. A Container is ephemeral. And you can have more than one Container running from the same Image.
Now a completely ephemeral container is not much good to anyone. This is what Volumes are for. A volume is a way to mount a folder from the host into the container. This is where you put your configs and databases and such. Because the data gets saved to the host, it gets persisted even when the Image changes and new Containers are created. So, for openHAB 2 one mounts the conf and user data folders into the container. For Mosquito, one mounts /etc/mosquito into the container.
There might be times when you want to make a change to a Container, for example when debugging a problem or adding new features, but your changes will not persist unless you create a new Image from that container, or even better, modify the Dockerfile to make the changes to the Image that gets built.
You can do this by running:
docker exec mosquito /bin/bash
Assuming the name of your container is “mosquito”.
By, like I said above, the proper way to configure mosquito would be to mount a volume to conf. Then you edit the mqtt.cfg file on the host.
Please see the basic tutorial on Docker’s website, review the op above again, paying attention to where it talks about volumes. And review the readme for the openHAB Docker Image on dockerhub and/or the GitHub repo for the docker image.
Appreciate the insight, but I have an additional problem in that I’m using freenas to host the docker containers and there is very little documentation on there middleware so a lot of the volume stuff is managed by that middleware. I think I need to figure that out before I’m going to make it through to actually getting this to work.
or we create our own openhab:openhab user with our own UID/GID, and have to pass the UID to the container and run the container with the openhab user (--user <openhabuserid> and -e "USER_ID=<openhabuserid>"), is that correct?
It would be great if you created an issue on the openhab-docs repo.
It is already covered in the docs on dockerhub:
Environment variables
EXTRA_JAVA_OPTS=“”
LC_ALL=en_US.UTF-8
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
OPENHAB_HTTP_PORT=8080
OPENHAB_HTTPS_PORT=8443
USER_ID=9001
By default the openHAB user in the container is running with:
And have you found that you MUST assign the IP or the container just auto-assigns the next IP in the range? This was a disappointing find in one my tests is that the container won’t use DHCP from the gateway assigned. I’d rather this so that all my IP reservations can be done through my PFsense box.
