I just noticed that all my dockers were no longer communicating to the internet. I could communicate internal to my LAN fine, but sickrage, couchpotato, transmission could not send email notification tests, scrape providers, update shows, add movies, etc.

 

I tried numerous things such as shutting down all of them, restarting, shutting down docker service and restarting, shutting down the VM Manager (no VMs were running).

 

I then tried to restart unRAID itself. No dice.

 

lastly, i went into the docker config for each docker and change network type from bridge to host. That didnt fix it. I then changed it back to bridge and voila! I repeared the change from bridge to host and back to bridge for each docker and they are all running now.

I just noticed that all my dockers were no longer communicating to the internet. I could communicate internal to my LAN fine, but sickrage, couchpotato, transmission could not send email notification tests, scrape providers, update shows, add movies, etc.

 

I tried numerous things such as shutting down all of them, restarting, shutting down docker service and restarting, shutting down the VM Manager (no VMs were running).

 

I then tried to restart unRAID itself. No dice.

 

lastly, i went into the docker config for each docker and change network type from bridge to host. That didnt fix it. I then changed it back to bridge and voila! I repeared the change from bridge to host and back to bridge for each docker and they are all running now.

 

i'm noticing something similar but with only particular docker , shout-irc.

intermittently it refuses to connect to irc, stop/starting it does nothing, the only way to get it back i've found is to delete and redownload the container.

if it happens again, i'll try switching net modes and see if i get the same result as you.

 

 

I just noticed that all my dockers were no longer communicating to the internet. I could communicate internal to my LAN fine, but sickrage, couchpotato, transmission could not send email notification tests, scrape providers, update shows, add movies, etc.

 

I tried numerous things such as shutting down all of them, restarting, shutting down docker service and restarting, shutting down the VM Manager (no VMs were running).

 

I then tried to restart unRAID itself. No dice.

 

lastly, i went into the docker config for each docker and change network type from bridge to host. That didnt fix it. I then changed it back to bridge and voila! I repeared the change from bridge to host and back to bridge for each docker and they are all running now.

Tom has a preferred way to report issues, found here: Guidelines for Defect Reports.  In particular, I think he will want to know how you replicate the problem, and a syslog covering the period when it occurs.

I just noticed that all my dockers were no longer communicating to the internet. I could communicate internal to my LAN fine, but sickrage, couchpotato, transmission could not send email notification tests, scrape providers, update shows, add movies, etc.

 

I tried numerous things such as shutting down all of them, restarting, shutting down docker service and restarting, shutting down the VM Manager (no VMs were running).

 

I then tried to restart unRAID itself. No dice.

 

lastly, i went into the docker config for each docker and change network type from bridge to host. That didnt fix it. I then changed it back to bridge and voila! I repeared the change from bridge to host and back to bridge for each docker and they are all running now.

 

Tom has a preferred way to report issues, found here: Guidelines for Defect Reports.  In particular, I believe he will be most interested in a way to replicate the problem, and a syslog covering the period when it occurs.

 

 

 

Apr 29 17:16:39 Unraid-Nas php: /usr/bin/docker start Shout-Irc
Apr 29 17:16:39 Unraid-Nas kernel: device vethc32f35d entered promiscuous mode
Apr 29 17:16:39 Unraid-Nas avahi-daemon[4492]: Withdrawing workstation service for veth4fd13bd.
Apr 29 17:16:39 Unraid-Nas kernel: eth0: renamed from veth4fd13bd
Apr 29 17:16:39 Unraid-Nas kernel: docker0: port 12(vethc32f35d) entered forwarding state
Apr 29 17:16:39 Unraid-Nas kernel: docker0: port 12(vethc32f35d) entered forwarding state
Apr 29 17:16:40 Unraid-Nas php: Shout-Irc
Apr 29 17:16:54 Unraid-Nas kernel: docker0: port 12(vethc32f35d) entered forwarding state
Apr 29 17:18:21 Unraid-Nas avahi-daemon[4492]: Withdrawing workstation service for vethc32f35d.
Apr 29 17:18:21 Unraid-Nas kernel: docker0: port 12(vethc32f35d) entered disabled state
Apr 29 17:18:21 Unraid-Nas kernel: device vethc32f35d left promiscuous mode
Apr 29 17:18:21 Unraid-Nas kernel: docker0: port 12(vethc32f35d) entered disabled state
Apr 29 17:19:09 Unraid-Nas kernel: device vethc5aa837 entered promiscuous mode
Apr 29 17:19:10 Unraid-Nas avahi-daemon[4492]: Withdrawing workstation service for veth09df19d.
Apr 29 17:19:10 Unraid-Nas kernel: eth0: renamed from veth09df19d
Apr 29 17:19:10 Unraid-Nas kernel: docker0: port 12(vethc5aa837) entered forwarding state
Apr 29 17:19:10 Unraid-Nas kernel: docker0: port 12(vethc5aa837) entered forwarding state
Apr 29 17:19:25 Unraid-Nas kernel: docker0: port 12(vethc5aa837) entered forwarding state
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/_UNPACK_Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236)/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.DD5.1.H264 (39) Directory not empty
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/_UNPACK_Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236) (39) Directory not empty
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/_UNPACK_Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236)/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.DD5.1.H264 (39) Directory not empty
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/_UNPACK_Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236) (39) Directory not empty
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236)/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.DD5.1.H264 (39) Directory not empty
Apr 29 17:19:33 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236) (39) Directory not empty
Apr 29 17:19:38 Unraid-Nas emhttp: /usr/bin/docker logs --tail=350 -f Shout-Irc 2>&1
Apr 29 17:20:13 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236)/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.DD5.1.H264 (39) Directory not empty
Apr 29 17:20:57 Unraid-Nas shfs/user: shfs_rmdir: rmdir: /mnt/cache/XBMC-Media/Downloads/Movies/Cobain.Montage.of.Heck.2015.DOCU.1080p.WEB-DL.cp(tt4229236) (39) Directory not empty
Apr 29 17:21:25 Unraid-Nas emhttp: read_line: client closed the connection
Apr 29 17:22:38 Unraid-Nas emhttp: read_line: client closed the connection
Apr 29 17:22:59 Unraid-Nas emhttp: read_line: client closed the connection
Apr 29 17:23:51 Unraid-Nas kernel: mdcmd (96): spindown 6
Apr 29 17:24:26 Unraid-Nas emhttp: read_line: client closed the connection
Apr 29 17:24:39 Unraid-Nas emhttp: read_line: client closed the connection

 

I can't reliably replicate the issue as it's intermittent.........

 

but changing net mode from bridge to host and back again results in the container being able to connect to irc where it didn't before.

video of it.

 

 

 

 

NOTE:

 

just realised the time where the webui wouldn't come up for the container, sab was unpacking a movie.

I think there are some issues with Docker 1.5.0 that may be resolved with Docker 1.6.0.  We will be including Docker 1.6 in the next release and I am going to be eagerly awaiting feedback from those who experienced hangups, networking issues, or any other Docker oddities.  Preliminary testing has been good with 1.6.0.

I think there are some issues with Docker 1.5.0 that may be resolved with Docker 1.6.0.  We will be including Docker 1.6 in the next release and I am going to be eagerly awaiting feedback from those who experienced hangups, networking issues, or any other Docker oddities.  Preliminary testing has been good with 1.6.0.

 

do you have an ETA on the next release or have a beta-beta program for users to test the internal builds?

video of it.

 

NOTE:

 

just realised the time where the webui wouldn't come up for the container, sab was unpacking a movie.

 

I even find that I dont have to "Update" the container after click to host. I just select host, then select bridge again and hit apply.

 

Also, I don't recall this happening until AFTER I enabled VM Manager. I also setup a network bridge in unRAID when I enabled VM manager.

 

VM Manager is currently off and will remain so a for a few days to see if I can replicate this with some predictability.

I think there are some issues with Docker 1.5.0 that may be resolved with Docker 1.6.0.  We will be including Docker 1.6 in the next release and I am going to be eagerly awaiting feedback from those who experienced hangups, networking issues, or any other Docker oddities.  Preliminary testing has been good with 1.6.0.

 

do you have an ETA on the next release or have a beta-beta program for users to test the internal builds?

 

HAHA!  Well Linux 4.0.1 is out and btrfs progs 4.0 are out, so we will probably upgrade kernel to that, add QEMU 2.3.0, new libvirt version (can't remember right now which, but latest), and Docker 1.6.  Quite possibly the next release will be RC1 and quite possibly this week.

So I have no lost communication since the initial discovery and my first post in this topic.

 

I have also not restarted the VM Manager service since as well. Saturday morning I'll restart the VM Manager service (no VMs running but two are "setup") and we'll see what happens.

 

Stay Tuned...

I'm experiencing the same issue, docker containers loosing internet access when they are restarted.

 

I've found the same "solution", I edit the containers and change the network type.

It happens with all my containers (lms, plex and transmission). I've had as well VM enabled and bridge.

 

I've played too much with parameters trying to fix this issue to be able to provide a better report but if it continues I'll take the time

to carefully report it.

 

 

Same issues here.

 

All three of my docker containers sometimes loose internet connectivity.

 

Changing everything to Bridge fixes it for me, but i'll have to wait and see if it is permanent.

Well internet connectivity remains fine with all of my dockers with the VM Manager enabled. I have not as of yet "spun" up an VM's. I'll wait a few more days and test with those running as well.

 

Mike

I just realised that this has occurred for me as well.

 

I don't have any VM's enabled, but I am booting with Xen (without any images configured).

I'm having DNS lookup problem with SABnzbd docker too. It goes away if the docker's setting is changed to Host and back to Bridged again; but comes back when reboot.

 

Any of you guys experiencing dns-only issue? Or is it more like complete connection loss?

 

Anyone getting it fixed by going to rc1/2?

I havent had any issues since leaving VM's off. The VM Manager is enabled but no VM's have been started. Not a single issiue.

I havent had any issues since leaving VM's off. The VM Manager is enabled but no VM's have been started. Not a single issiue.

 

I am unfortunately still having it, even with the VM screen enabled (no VMs though). That being said, since about a week ago it seems to not have a timeout issues during use, just during startup.

I just upgraded to RC2 and after the reboot none of the dockers (plex, sabnzbd, sonarr, Minecraft server)could reach the outside world. I was able to get them to connect by editing them and saving the configs without making any changes. They were all working before the update from beta15. I had this happen once in beta15 after a reboot but i had thought it was something I did since I had just updated to unraid 6.

I'm also seeing this issue, noticed this morning when accessing server remotely, I've been rebooting between beta 15 and RC2 trying to add in DVB drivers. Currently on beta 15, rebooting hasn't solved the issue.

 

Also appears to be a DNS issue.

 

Let me know if any specific logs would be helpful.

 

I'm having DNS lookup problem with SABnzbd docker too. It goes away if the docker's setting is changed to Host and back to Bridged again; but comes back when reboot.

 

Any of you guys experiencing dns-only issue? Or is it more like complete connection loss?

 

Anyone getting it fixed by going to rc1/2?

I had the problem upgrading  to -rc2 and now -rc3, and the fix is just how you describe, but I haven't rebooted yet.

FYI we're working on this...

Is anyone having the problem tried mapping a readonly volume of /etc/resolve.conf from unraid host into the docker?

 

I havent experienced this issue at all but then again I have the resolve.conf file mapped on mine from when I noticed and reported the issue that docker containers were not respecting the hosts nameserver settings months ago.

I assume related, it's been progressively getting worse though since b15. RC3 is horrendous when it comes to stud define and connection time outs for Plex and Sonarr for me. Others seem to experience it but it's most noticeable in Plex. Transcoding shudders along on files that worked fine a month ago. Would this be considered related? Looking at my docker app logs they show connection timeouts.

I assume related, it's been progressively getting worse though since b15. RC3 is horrendous when it comes to stud define and connection time outs for Plex and Sonarr for me. Others seem to experience it but it's most noticeable in Plex. Transcoding shudders along on files that worked fine a month ago. Would this be considered related? Looking at my docker app logs they show connection timeouts.

 

I don't think so, I wasn't seeing Timeouts. Plus, when this issue occurs ALL communications are lost with all dockers.

I have this problem still on RC4.

Is there a way to force update the dockers via the terminal, so I can put those commands in the go file?