Jump to content

Problem with VOLUME mount. Works in Kitematic, not Unraid.


niietzshe

Recommended Posts

Thanks Bungy, I have installed yours and really appreciate all the work you've done there. I just wanted to make my own so I can understand a bit more about dockers. Then I can also make a OH2 version etc...

 

I don't know what the docker run command is, I just start it from unraid or kitematic. I haven't given it any explicit command... Sorry if that's dumb, I'm just trying to piece it together by looking at others work (including your own)..

 

Thanks

Link to comment

Thanks Bungy, I have installed yours and really appreciate all the work you've done there. I just wanted to make my own so I can understand a bit more about dockers. Then I can also make a OH2 version etc...

 

I don't know what the docker run command is, I just start it from unraid or kitematic. I haven't given it any explicit command... Sorry if that's dumb, I'm just trying to piece it together by looking at others work (including your own)..

 

Thanks

You have to manually specify the volume mounts when running the docker. For example:

 

docker run -d --name openhab -v /mnt/cache/appdata/openhav/config:/config <image name>

 

That will map your host directory to the container's local directory.

 

I'm not sure how kitematic works. It may look at what is exposed inside the container and automatically do the volume mounts for you.

Link to comment

Yes, you can certainly make a template to handle all the volume mounts. From the github link you posted, it didn't look like you had a template up and running. If you don't already have a template, the easiest way to test your docker is using the docker run command at the command line.

Link to comment

Yes I have a template repository:

https://github.com/christianwaite/docker-templates

 

So I found the docker run command when adding from UnRaid, which is:

 

root@localhost:# /usr/bin/docker run -d --name="OpenHab" --net="host" --privileged="true" -e TZ="Europe/London" -v "/mnt/cache/appdata/openhab":"/config":rw christianwaite/openhab

 

Which seems right. It's going to give rw access to /config at /mnt/cache/appdata/openhab. So I'm running the same docker in Kitematic right now and I have access to everything inside of /config, unraid == nothing...

 

Bit stuck :(

Link to comment

Do you look at the appdata folder through windows explorer or a ssh connection?

If you do the first, try connecting with ssh to the server and issue this command in the /mnt/cache/appdata/openhab folder:

 

ls -la

 

Do you see the folders now?

Link to comment

Yeah I'm checking through ssh as well... No banana...

 

Hmm, so I just went into the docker bash (docker exec -it OpenHab bash) and the /config directory there is empty. So I move folders out of /usr/share/openhab into /config and link back to them. At some point this must be failing on UnRaid, where as it doesn't in Kitematic.. Wait that doesn't make sense because it's built as a container on the hub...

 

What's going on here?

Link to comment

My guess is kitematic isn't linking the volumes. When you browse to /config in kitematic it shows you the container's data. In unraid it shows you the host's data, which is empty. You'll have to manually populate that data.

Link to comment

Ok so this is quite confusing to explain. But thanks for baring with me.

So kitematic automatically has the volume mount because I've specified it in the dockerfile. So /config is available by default on that docker. And is populated with the data I expect. I can't get to any other part of the docker.

 

On Unraid, not only is that data not available as an export, but if I bash into the docker and have a look around, the actual data I've copied from /usr/share/openhab to /config has gone! So somewhere Unraid is writing dead space to that exported directory.

 

If I bash into the kitematic and have a look at the same directories, everything is there...

So it must be how I'm running the docker from UnRaid (which seems correct), or something more buggy is going on.

Link to comment

I decided to take a look at what was happening and found the problem.

Volume mapping is tricky when used in a Dockerfile, and I didn't know this myself either. But because  you used the volume mapping before the install script any changes made to /config doesn't stick. You can read about it in this article http://container42.com/2014/11/03/docker-indepth-volumes/

Even moving the volume mapping after the install script was run didn't make any difference. Not sure why, but I guess there is an explanation for this also. So what I did was to make a new script that runs every time the container starts. It checks if /config/addons exists and if not moves the settings from /usr/share/openhab to /config.

 

I called it firstrun.sh, but you can call it whatever you want. It's added to /etc/my_init so it's run on every start.

 

#!/bin/bash

if [ ! -d /config/addons ]; then
echo '******MOVING**********'
mv /usr/share/openhab/addons /config/
mv /usr/share/openhab/webapps /config/
mv /etc/openhab/configurations /config/

echo '******LINKING**********'
ln -s /config/addons /usr/share/openhab/addons
ln -s /config/webapps /usr/share/openhab/webapps
ln -s /config/configurations /etc/openhab/configurations

chown -R nobody:users /config
chmod -R 777 /config
fi

 

You will have to add this to your Dockerfile:

 

ADD firstrun.sh /etc/my_init.d/firstrun.sh
RUN chmod +x /etc/my_init.d/firstrun.sh

 

Just add it after "RUN bash /install.sh". Remember to remove the config part from the install script.

 

I see from your template that you run the container with network type=host and have exposed ports in the Dockerfile. If the ports exposed are the only ones needed for access to openhab, you can change the network type to bridge.

If you need to run the container with host you can safely remove the expose mappings in the Dockerfile.

Link to comment

Thanks saarg. I remember having similar issues when I was building my openhab docker. I'm going to update my docker with your suggestions.

 

niietzshe - Adding VOLUME /config to your dockerfile doesn't actually mount your host path to your docker path. It only allows that directory to be exposed to the host. I believe if you run your docker run command without the -v volume mounting and then exec -it bash into your container, you'll find that unraid and kitematic perform the same way.

Link to comment

Ahh brilliant! Thanks to both of you!!! I had moved the volume mount in the dockerfile around thinking it might be causing some issues...

 

So firstrun just runs the first time the docker is ever run and never again? And this is a phusion thing? So it automatically runs based on its name and location?

 

It's all working and I can move forward with everything. I'll start a proper thread as things are working as I want them. Need to add in automatic linking of USB device based on env vars etc :)

 

Thanks again so very much!!! I'm very greatfull!

 

Christian x

Link to comment

You should re-read what I wrote ;)

It will be run at every start of the container as long as you followed my instructions.

 

All scripts you put in /etc/my_init/ runs when the container starts. It runs in lexicographic order  :o if you know what that is, I sure don't!

Link to comment

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...