i just added this to extra parameters in a container that doesn't connect and it's connected after one reboot so far, not exactly rigorous testing i know...

 

--dns 8.8.8.8

 

make that 2 reboots now.

 

also sab and headphones are connecting with this in extra parameters.

 

3 reboots and no connectivity issues with the containers i added it to.

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

Trying now, will report back shortly.

i just added this to extra parameters in a container that doesn't connect and it's connected after one reboot so far, not exactly rigorous testing i know...

 

--dns 8.8.8.8

 

make that 2 reboots now.

 

also sab and headphones are connecting with this in extra parameters.

 

3 reboots and no connectivity issues with the containers i added it to.

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

if it does, is there anyway to get my nameserver from my network settings in unraid webui in to that config file, so if my network config changes (it could do next week with change to router setup and moving ip ranges for my lan) i don't have to update the .cfg.

i just added this to extra parameters in a container that doesn't connect and it's connected after one reboot so far, not exactly rigorous testing i know...

 

--dns 8.8.8.8

 

make that 2 reboots now.

 

also sab and headphones are connecting with this in extra parameters.

 

3 reboots and no connectivity issues with the containers i added it to.

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

if it does, is there anyway to get my nameserver from my network settings in unraid webui in to that config file, so if my network config changes (it could do next week with change to router setup and moving ip ranges for my lan) i don't have to update the .cfg.

 

With zero coding ability I assume you could do something like:

DOCKER_OPTS="--storage-driver=btrfs --dns=$dnsip"

 

@eschultz

It didn't seem to work sorry.

DOCKER_OPTS="--storage-driver=btrfs --dns=192.168.1.1"
DOCKER_IMAGE_FILE="/mnt/cache/docker.img"
DOCKER_IMAGE_SIZE="10"
DOCKER_ENABLED="yes"

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

Seems to be working for me, only the host based dockers didn't have the Sparklyballs treatment, but Emby & Plex are now working as expected.  Good work Eric.  Is that the fix Tom mentioned yesterday?

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

Seems to be working for me, only the host based dockers didn't have the Sparklyballs treatment, but Emby & Plex are now working as expected.  Good work Eric.  Is that the fix Tom mentioned yesterday?

 

it's a fix of sorts, i tried (didn't work) using my pfsense ip instead. (i'd like one place to set dns for the entire network, and not use google dns so much either)

To clarify I was using 8.8.8.8

To clarify I was using 8.8.8.8

 

rebooted using 8.8.8.8 in the docker.cfg

 

sickbeard , no connection

 

headphones, no connection

To clarify I was using 8.8.8.8

 

Do you have any VMs? If not, do you have the VM part enabled still?

Same question to you sparklyballs?

To clarify I was using 8.8.8.8

 

rebooted using 8.8.8.8 in the docker.cfg

 

sickbeard , no connection

 

headphones, no connection

 

Hmmm, the only thing I can think of is that since RC6 often, although not always, it would appear that the docker service is starting before my unassigned device mounted SSD is ready and I have no containers until I stop and restart the docker service.

 

EDIT: Yes I have VMs but not set to autostart.

To clarify I was using 8.8.8.8

 

rebooted using 8.8.8.8 in the docker.cfg

 

sickbeard , no connection

 

headphones, no connection

 

8.8.8.8 worked for me, which is cool in one way but another way its crap cause there is no way I want to use Google DNS full time.

To clarify I was using 8.8.8.8

 

rebooted using 8.8.8.8 in the docker.cfg

 

sickbeard , no connection

 

headphones, no connection

 

8.8.8.8 worked for me, which is cool in one way but another way its crap cause there is no way I want to use Google DNS full time.

 

208.67.222.222 

To clarify I was using 8.8.8.8

 

rebooted using 8.8.8.8 in the docker.cfg

 

sickbeard , no connection

 

headphones, no connection

 

8.8.8.8 worked for me, which is cool in one way but another way its crap cause there is no way I want to use Google DNS full time.

 

208.67.222.222 

 

Not really any better IMO but thanks.

208.67.222.222 

Not really any better IMO but thanks.

Hence the laughter..  What do you use for DNS then?

I've not had any issues previously, but just noticed SickBeard was failing to connect externally. I checked, saw it was in bridge mode, and switching to host mode has fixed this. I've never had an issue prior to upgrading to RC6 this morning.

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

A second reboot and it hasn't worked..

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

A second reboot and it hasn't worked..

 

No change to the settings? Sorry for asking the obvious.

Just to clarify, this DNS tweak only works when the docker is in bridge mode, correct ? 

 

Does setting the overall dns for docker instead of on a container-basis achieve the same success? http://lime-technology.com/forum/index.php?topic=39604.msg376106.msg#376106

 

Seems to be working for me, only the host based dockers didn't have the Sparklyballs treatment, but Emby & Plex are now working as expected.  Good work Eric.  Is that the fix Tom mentioned yesterday?

 

it's a fix of sorts, i tried (didn't work) using my pfsense ip instead. (i'd like one place to set dns for the entire network, and not use google dns so much either)

This is weird,

 

stopping and restarting the docker service doesn't fix it,

passing through the DNS to individual containers does fix it but passing DNS through docker.cfg doesn't

only happens to certain people and on certain versions of Unraid/Docker?

 

Only thing known to fix is EDIT/SAVE triggering a reboot from docker hub even if no data is pulled.

 

EDIT: I'm rolling back to RC5 for the time being, working over the weekend on nights so if you need me to test post here or PM me and I'll do my best.

Only thing known to fix is EDIT/SAVE triggering a reboot from docker hub even if no data is pulled.

 

As mentioned before, that is required if container was created in -beta14 or earlier.  I'll put that in the OP.

 

This issue stems from (what we consider to be) a bug with docker and the way they handle resolv.conf file in containers.  In a nutshell, what they do is have docker daemon set up an "inotify watch" for a file modification event on the host /etc/resolv.conf file.  When this triggers, the daemon goes and updates that file in all stopped containers, though subject to various rules.  Notice I said "stopped".  For containers that are started, changes to resolv.conf on host will not get propagated until the next time the container is restarted.

 

What happens if docker starts a container and the hosts resolv.conf file is blank?  It initializes the container's resolv.conf file with the google public name server IP addresses 8.8.8.8 and 8.8.4.4    Therefore if there are any issues with host resolv.conf they are effectively "masked" by this docker behavior.  This is why lots of containers seemed to work earlier.

 

Besides this hack-ish behavior, it appears the docker daemon only runs through its resolv.conf update code as a result of the inotify watch triggering.  This means if docker and containers are started before network is up, containers will never get the right resolv.conf contents unless they are manually restarted.

 

To fix this we did 2 things:

1. We wait for the network to "come up" early in system startup (with 60 sec timeout so it won't hang forever), and

2. In rc.docker, right after daemon started but before containers start, we trigger the inotify watch on resolv.conf.

 

The reason you have to rebuild containers created prior to -beta15 is that above resolv.conf hackery was put into the docker release that we put in -beta15.

 

But to be safe, I'd recommend rebuilding all your containers (the Edit/Save trick).

Only thing known to fix is EDIT/SAVE triggering a reboot from docker hub even if no data is pulled.

 

As mentioned before, that is required if container was created in -beta14 or earlier.  I'll put that in the OP.

 

This issue stems from (what we consider to be) a bug with docker and the way they handle resolv.conf file in containers.  In a nutshell, what they do is have docker daemon set up an "inotify watch" for a file modification event on the host /etc/resolv.conf file.  When this triggers, the daemon goes and updates that file in all stopped containers, though subject to various rules.  Notice I said "stopped".  For containers that are started, changes to resolv.conf on host will not get propagated until the next time the container is restarted.

 

What happens if docker starts a container and the hosts resolv.conf file is blank?  It initializes the container's resolv.conf file with the google public name server IP addresses 8.8.8.8 and 8.8.4.4    Therefore if there are any issues with host resolv.conf they are effectively "masked" by this docker behavior.  This is why lots of containers seemed to work earlier.

 

Besides this hack-ish behavior, it appears the docker daemon only runs through its resolv.conf update code as a result of the inotify watch triggering.  This means if docker and containers are started before network is up, containers will never get the right resolv.conf contents unless they are manually restarted.

 

To fix this we did 2 things:

1. We wait for the network to "come up" early in system startup (with 60 sec timeout so it won't hang forever), and

2. In rc.docker, right after daemon started but before containers start, we trigger the inotify watch on resolv.conf.

 

The reason you have to rebuild containers created prior to -beta15 is that above resolv.conf hackery was put into the docker release that we put in -beta15.

 

But to be safe, I'd recommend rebuilding all your containers (the Edit/Save trick).

 

But Tom, I do the Edit/Save trick and that works.  BUT and it's a big but, only until a reboot...

But Tom, I do the Edit/Save trick and that works.  BUT and it's a big but, only until a reboot...

 

After a reboot instead of edit/save, if you type:

 

docker restart <container>

 

Does it then work?

 

Do you have anything "non-standard" (vs. stock unRaid) in your config?

Pretty sure all of my containers were built in RC3 I think as I deleted my docker.img and recreated at some point, so well past beta 14, I'm happy to do so again to check if that helps.

 

My go file is stock.

 

I am running a mediabuild version of bzimage/bzroot but I think I'm the only one here that is.

 

I have the usual plugins installed Unassigned Devices, Community Applications, Nerd tools, Media Tree Check, ProFTPd, Powerdown, Preclear, Server Layout and the Dynamix Ones.

 

I'm just about to go to work,  If I can get a mobile reception at work tonight and we're not too busy I'll try VPNing to my box and try that command.

 

I have not tried rc6, yet, but just wanted to point out that ever since I reported a docker dns bug back in November/December of last year I have also been running with the --dns options in the main docker.cfg file as well as the file mapping of resolv.conf and have never run into the docker dns issues since that time.

I am running a mediabuild version of bzimage/bzroot but I think I'm the only one here that is.

wtf is that?

I have not tried rc6, yet, but just wanted to point out that ever since I reported a docker dns bug back in November/December of last year I have also been running with the --dns options in the main docker.cfg file as well as the file mapping of resolv.conf and have never run into the docker dns issues since that time.

 

Yes that should do the trick.  With the --dns option are you specifying an IP address that is not in the host /etc/resolv.conf file?

 

What that option does is add that IP address as nameserver entries in the containers /etc/resolv.conf file.  You can specify multiple --dns options as well.