tinglis1

Did you ever resolve this issue? I have recently moved Plex to a container on a secondary unraid server and am having the exact same issue. I tend to notice it when the media scanning isn’t picking up new content. I found it really strange that the file still play though. To fix it I unmount and mount the share again and then it works. If I try to start the Plex docker when the share mount is in this weird state I get the execution error you posted.

There is some work being done on this by the Home Assistant community. Might be worth seeing what they have done. https://community.home-assistant.io/t/unraid-api-connect-and-control-unraid-servers-through-home-assistant-via-mqtt/154198 https://community.home-assistant.io/t/unraid-monitoring/53775

Have you got pipework working with other docker containers with using the vlan bridge? If so then it is likely to do with the br0.5 interface. It could be the name or it could be the way it is handled by pipework. Have you tried nested quotes? This may help if it is a naming issue. Have a look at the code for pipework if you want as well. https://github.com/jpetazzo/pipework/blob/master/pipework The interface name is transfer to the variable ‘IFNAME’ Sent from my iPhone using Tapatalk

I no longer use this as feature as i am using the inbuilt networking in unraid 6.4. I would suggest following the instructions earlier in the thread from unevent. -e 'pipework_cmd=bro.5 @CONTAINER_NAME@ 192.168.5.40/[email protected]'

Assuming the scope of the encryption is to prevent access to the data on the drives if removed from the host then the following types of authentication methods could be useful: - GUI password - unRAID USB hardware id - separate USB hardware id or key file. The later two options would allow for automatic authentication on boot. The last option would allow for easier securing of the drives. In my case my unraid USB is internal, so removing it for periods such as going on holiday etc. to protect from theft of the whole server is not viable. Sent from my iPhone using Tapatalk

What do you mean by this step? as is doesn't sound right. Are you showing the advanced settings and putting the code in the extra parameters section? It sounds like your adding a variable instead. Sent from my iPhone using Tapatalk

The code @CONTAINER_NAME@ automatically enters the container name. It should work if you use that instead of the container name. Sent from my iPhone using Tapatalk

I haven't used openhab for a while now. It looks like they have changed the container tags. Checkout https://hub.docker.com/r/openhab/openhab/tags/ On a side note, I have moved to using HomeAssistant.io. I have achieved more with that in the last 6 months than I did with Openhab in years. Sent from my iPhone using Tapatalk

@gareth_iowc How did you get on with those tests? Sent from my iPhone using Tapatalk

It still works with that version I think. I am currently using 6.3rc without issue. Can you try it with a static ip instead of dhcp. I have had issues with dhcp in the past. Also check your network settings to make sure br0 is active. Try 'ifconfig' to see if it is there. I will have a look in more detail at your setting when I'm near my unraid computer next. Sent from my iPhone using Tapatalk

The use of the internal docker networking functions are discussed here https://lime-technology.com/forum/index.php?topic=51335.0

Can you try the following. - Try without the mac option to see if that is having an impact. -e 'pipework_cmd=br0 @CONTAINER_NAME@ 192.168.1.119/[email protected] - What is the pipework log saying? If it is showing errors please post a sample of the log. - Some containers do not play well with network functions. I have tried both pipework and the inbuilt docker networking tools but have found the same results for both. Can you try setting the ip on another container.

Previously discussed here. https://lime-technology.com/forum/index.php?topic=51335.0

I did not assign anything to the nic, just left it as up. I have stopped testing docker networking with my server now I started to get very strange results. By manually creating the bridge between the docker network and eth1 using brctl all of my traffic from VM's and dockers (even using pipework, not sure about docker networking) started to come from my unraid host ip on eth0. This caused havoc in my system as low priority traffic was considered high priority as it was coming from my unraid ip. I will put the Docker networking testing on hold again as the trouble is not worth it while I have a solution that currently works.

Just to clarify. I have not tried dns setting using pipework. I have pipework giving dockers their own static IP and then using my router to manage traffic priority or pushing the traffic through a vpn if necessary.

I had turned on bridging but wanted it off. so rather than reboot I just deleted the bridge. I will turn the bridge off next time I shut my array down. I didn't realise the network setting persisted after reboot. The bridge between the docker bridge and the nic wont though as these commands are done in unraid not docker. There is a lot more to do, especially around the nic bridging, before this would be ready for inclusion in the gui. Also at the moment the docker network option is only available to those with a spare nic. This is already possible using pipework and much simpler than the docker networking method. At the moment this has to many balancing parts that make it suitable for my non development dockers.

Couldn't help myself from having a go at this again as it has been bugging me. I had some success using a "home-assistant" docker and my second and unused nic "eth1". Background network info: - physical router/gateway: 192.168.2.1 - subnet mask: 255.255.255.0 or /24 - docker container static ip: 192.168.2.106 I used the following commands to get my docker network up: docker network create --subnet 192.168.2.0/24 --aux-address "DefaultGatewayIPv4=192.168.2.1" --gateway=192.168.2.2 -o com.docker.network.bridge.name=br-home-net homenet brctl addif br-home-net eth1 ip a del 192.168.2.2/24 dev br-home-net The part about deleting the gateway may not be necessary. But I was following steps from someone else so kept it the same for the meantime. Then to add the ip to the docker i added the following extra parameter: --net homenet --ip 192.168.2.106 Make sure your network is set to "None" I was concerned that the --net config showing up twice, once for "None" and then again for our custom network might cause issues but not in this case. Next step will be: - To test some other containers and see how they go. - Figure out a way for those with only one interface to be able to use this feature. - automate the creation of the docker network - let others test the process and see how it goes - if it work suggest that it be built into unraid GUI A quick note on something I did that isn't normal: I had tried using the inbuilt bridge feature suggested in the earlier post to make br1. This is not what you need to do. So I manually deleted my bridge because I didnt want to take down my VM to do so. I hope that doesnt impact my results but I will test this later. Is used the follwinf command to do so: ip link set br1 down brctl delbr br1

+1 I run a similar setup to the OP and want similar things. This topic seems to come up every couple of months. Last time I saw it. I use to have my docker.img on my UDEV ssd but as of 6.2 that is no longer possible. So at the moment we are going the wrong way.. I would really like to see this as well. But I would be happy if these were added later due to the complexity.

I had a good go at it when 6.2 was in the beta stages and was met by a few issues. It has been a while and cannot remember the details but some of the issues I remember encountering were: - Unable to successfully connect the docker network to an NIC in unraid. I think the info about the bridges being created a few posts back might be able to help this though. - When creating the network in docker there was some trickery required to create a gateway the same as your home network. I remember loosing network connectivity from unraid a few times trying that one out as it redirected all unraid traffic back to my docker network. - Lack of ability to make it work in a set and forget mode. I needed to make scripts that were executed on docker startup to create the network etc. - I spent a significant amount of time on it and did not get a working result so went back to trying to get pipework going on unraid 6.2. That was a more successful mission. Check out this link if you want to have a go at it. This has a workaround for the gateway issue. Note that this is still an open issue on github so I don't think it matters that we are running Docker 1.10. I may try again at this later but a pipework docker is working in a set and forget mode it is not high on my priority list. Though I do have a couple of dockers that I would like to have their own IP but down behave very well with pipework. This maybe more viable once the gateway issue is resolved or if all the required steps/scripts are built into unraid/plugin to make it a seamless experience. Ideally, I would like to see the day when you just select a static/dynamic IP from the docker config screen and all the required work is done behind the scenes.

I might have to have another go at the Docker networking feature now that I know that unraid creates the other bridges. This was where I got stuck last time. I could get the IP assigned to the container but could get it to communicate to the NIC. In saying that, my pipework solution is working exactly how I need it to without any interaction so this is probably very low on my list of things to do.

@johnnie.black That is good to know. Do you have to do anything special to get br1 active? @Flick I would recommend trying br1 instead of eth1.

My signature is pretty much up to date. Just changed my unraid version to reflect what i am actually using. My build has been stable for years now and for the last year I have been using it as my primary workstation as well with GPU passthrough.

In theory this should be achievable using pipework, although I haven't used it with a separate nic. Have a look at the pipework docker; the opening post contains most of the info you need to get started. Pipework Docker - Start by getting the pipework docker from Community Applications. Make sure you get the correct version for your version of unraid. - I think you may need to remove the second nic from being assigned to unraid. I am not sure about this step and it may need some testing. - Change the network type to 'None' in the deluge container. Then add the additional parameter of: -e 'pipework_cmd=eth1 @CONTAINER_NAME@ 192.168.1.100/[email protected]' make sure you change your ip address and subnet to match. The only part of this process that hasn't been tested is the use of eth1 instead of br0.

What are you trying to do exactly? Is the docker to be run on a physically separate network? I have static ip addresses for almost all of my dockers to be able to manage traffic or allow for port access. It is possible just not using the internal docker networking features. Sent from my iPad using Tapatalk

I have attempted to use the advanced networking functions with no luck. So I went back to using pipework. Unraid 6.2 uses docker 1.10 and from what I can tell from the guides online for most are using docker versions newer than that. When looking for help elsewhere on this I usually got the answer of "update docker". Sent from my iPhone using Tapatalk