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.