I am unable to created a new thread in the LSIO category.
However the default Radarr container is unable to search for any movies: There was an error searching for 'XYZ'.
Sonarr, configured the same way, using the same Jackett container and Deluge downloader, is working fine. I’ve read online this might be a Mono issue in the container. Anyone else facing a similar problem?
Post the command you used to create the container
docker run -d --name=radarr --network 0x04 -p 192.168.200.1:7878:7878 -e PUID=1050 -e PGID=1050 -e TZ=Asia/Singapore -e UMASK_SET=022 -v /srv/downloader/radarr/config:/config -v /srv/downloader/radarr/movies:/movies -v /srv/downloader/downloads:/downloads --restart unless-stopped linuxserver/radarr
why are you doing this?? My first thought with your logs is you had no network connectivity… you’ve got some weird --network thing here and then you’re locking docker to an ip address that most likely doesn’t actually exist unless you specifically created a docker network with this ip address… by default they are 172 addresses. Also the only thing i recognize 0x04 from is some form of rejection code.
Please share the output of docker inspect radarr | grep IPAddress and potentially change --network 0x04 -p 192.168.200.1:7878:7878 to -p 7878:7878 and retest 
That 0x04 network actually exists and works fine for all other containers.
# docker inspect radarr | grep IPAddress
"SecondaryIPAddresses": null,
"IPAddress": "",
"IPAddress": "192.168.200.4",
# docker network inspect 0x04
[
{
"Name": "0x04",
"Id": "d06d05fadeaac244a852dc4509740a32bfc917719e1a4e6d4b8998544b369050",
"Created": "2019-12-08T14:08:37.9108389+01:00",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": true,
"IPAM": {
"Driver": "default",
"Options": {},
"Config": [
{
"Subnet": "192.168.200.0/24",
"Gateway": "192.168.200.1"
},
{
"Subnet": "2001:x:y:a003:1:afaf::/80",
"Gateway": "2001:x:y:a003:1::1"
}
]
},
"Internal": false,
"Attachable": false,
"Ingress": false,
"ConfigFrom": {
"Network": ""
},
"ConfigOnly": false,
"Containers": {
"2a32a9491022e3d07359e46dcaa303430a0f20a35825fd7c1e42a21f32055620": {
"Name": "wireguard",
"EndpointID": "c75c20fd4ab73dc97914f0044daa4032429f0942b789bb2c2779ce682aaf7d00",
"MacAddress": "02:42:c0:a8:c8:64",
"IPv4Address": "192.168.200.100/24",
"IPv6Address": "2001:x:y:a003:1::3/80"
},
"5d917c4dda08b856f4b71e7064fb31f4e83a922f80793ff45ccddbfd7ba26f36": {
"Name": "box",
"EndpointID": "421c8ab7d2eb35acbc121b6c2d8f4edd5e75e50e51db6237e298d7ecc37b586c",
"MacAddress": "02:42:c0:a8:c8:32",
"IPv4Address": "192.168.200.50/24",
"IPv6Address": "2001:x:y:a003:1::2/80"
},
"6bb015cc107f7b5bc678197fcba3ffc5eefcc0d9fd3792d0b0fc81a96987bfc2": {
"Name": "resilio-sync",
"EndpointID": "7b58c7eaea2f0d5f0118ad61b6381ad0641383ddf9e0bbb69baed2a62ef60a98",
"MacAddress": "02:42:c0:a8:c8:08",
"IPv4Address": "192.168.200.8/24",
"IPv6Address": "2001:x:y:a003:1::a/80"
},
"76aa472ca64685f066b760547cf7f2a3c95cd164a122ca3748e6d030c4100b43": {
"Name": "jackett",
"EndpointID": "2f0cac50eb61db357fc1d8ce9ca969a6dcac1a2753f0b34902fdce2546585478",
"MacAddress": "02:42:c0:a8:c8:03",
"IPv4Address": "192.168.200.3/24",
"IPv6Address": "2001:x:y:a003:1::5/80"
},
"8715b1bb1a0694d9118a15ce14b83f399f12109eeddf155c77f0552b8b4fd4de": {
"Name": "deluge",
"EndpointID": "a44d8ee2046ca794b95fc62b2ab1594cd46f9f9d3e2e3f0ba561330e59debf41",
"MacAddress": "02:42:c0:a8:c8:02",
"IPv4Address": "192.168.200.2/24",
"IPv6Address": "2001:x:y:a003:1::4/80"
},
"a7a306f8a88c78a4c3e72993dd7b0fa7f6a01876da907c3e87354efc4a9b11b6": {
"Name": "sonarr",
"EndpointID": "8885d052e4339d80683b534455d04fabf7d1ae46b39dc1a0c4765d931fa9c7d0",
"MacAddress": "02:42:c0:a8:c8:06",
"IPv4Address": "192.168.200.6/24",
"IPv6Address": "2001:x:y:a003:1::8/80"
},
"d0809346c9833319119a2a9a4618bcdef1c3dc6bc80faac497692c721c82df3d": {
"Name": "smokeping",
"EndpointID": "6289050e080b3eb06c8a99baf91bc481bb913ad97c0a862ad49b5d6388a2bae3",
"MacAddress": "02:42:c0:a8:c8:05",
"IPv4Address": "192.168.200.5/24",
"IPv6Address": "2001:x:y:a003:1::7/80"
},
"eb9206e1fbe1b56ea872f47d4b75e9e9b0ce1c24be424f27a4cdf01861aeaa85": {
"Name": "radarr",
"EndpointID": "2230067fdee1fd7f1ab5604ba5368a09cfc518aff02e4119b63ac9dfdf088974",
"MacAddress": "02:42:c0:a8:c8:04",
"IPv4Address": "192.168.200.4/24",
"IPv6Address": "2001:x:y:a003:1::6/80"
},
"ecbcbe3d42d369198c66399a2a94cec0dc14ab365b49350519d614964b6be5d6": {
"Name": "bazarr",
"EndpointID": "13a1b8f0b6928aa53447d054971587ad1d491a1342eaaa7f39ef8cfca2f27712",
"MacAddress": "02:42:c0:a8:c8:07",
"IPv4Address": "192.168.200.7/24",
"IPv6Address": "2001:x:y:a003:1::9/80"
}
},
"Options": {},
"Labels": {}
}
]
I’ve added a separate network block to provide IPv6 capabilities, and to create a “lan” network (ie radarr is able to ping jacket hostname, or deluge hostname; without the need of using IPs)
OK that’s fair, so you manually created a docker network named an error code and then assigned a 192 subnet to it.
As a quick note, you blanked out the ipv6 in your subnet section, but left it showing in the containers, you may want to do a quick edit and obfuscate that!
You mention radarr can ping jackett and deluge, did you actually test that? This is a good test to establish internal connectivity. If that works, i would assume this implies a failure to nat the traffic out onto your LAN (and thus to your WAN)
In this case, the errors you show in your radarr log seem to imply a lack of network connectivity. I would blow the config directory away, stop and remove the container, and recreate it.
Thanks – masked the IP but I guess it’s too late, it’s in the edit logs.
And yes, that network name might be confusing, but I picked that hex code for a reason. It works (as a name) though.
ping (was not installed, installed it) seems to default to IPv6. That’s interesting:
root@eb9206e1fbe1:/# ping jackett -c 1 ; ping deluge -c 1
PING jackett(jackett.0x04 (2001:x:y:a003:1::5)) 56 data bytes
From radarr.0x04 (2001:x:y:a003:1::6) icmp_seq=1 Destination unreachable: Address unreachable
--- jackett ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
PING deluge(deluge.0x04 (2001:x:y:a003:1::4)) 56 data bytes
From radarr.0x04 (2001:x:y:a003:1::6) icmp_seq=1 Destination unreachable: Address unreachable
--- deluge ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms
root@eb9206e1fbe1:/# ping jackett -c 1 -4 ; ping deluge -c 1 -4
PING jackett (192.168.200.3) 56(84) bytes of data.
64 bytes from jackett.0x04 (192.168.200.3): icmp_seq=1 ttl=64 time=0.465 ms
--- jackett ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.465/0.465/0.465/0.000 ms
PING deluge (192.168.200.2) 56(84) bytes of data.
64 bytes from deluge.0x04 (192.168.200.2): icmp_seq=1 ttl=64 time=0.118 ms
--- deluge ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.118/0.118/0.118/0.000 ms
I’m not entirely sure why within the docker container network IPv6 refuses to work (ie pinging IPv6 from one container to the other), but externally it’s working fine:
root@eb9206e1fbe1:/# ping6 google.be
PING google.be(ams16s32-in-x03.1e100.net (2a00:1450:400e:80c::2003)) 56 data bytes
64 bytes from ams16s32-in-x03.1e100.net (2a00:1450:400e:80c::2003): icmp_seq=1 ttl=54 time=1.25 ms
64 bytes from ams16s32-in-x03.1e100.net (2a00:1450:400e:80c::2003): icmp_seq=2 ttl=54 time=1.46 ms
^C
--- google.be ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.255/1.359/1.464/0.110 ms
root@eb9206e1fbe1:/# ping fb.com -4
PING fb.com (185.60.216.35) 56(84) bytes of data.
64 bytes from edge-star-mini-shv-01-frx5.facebook.com (185.60.216.35): icmp_seq=1 ttl=55 time=8.22 ms
64 bytes from edge-star-mini-shv-01-frx5.facebook.com (185.60.216.35): icmp_seq=2 ttl=55 time=8.31 ms
64 bytes from edge-star-mini-shv-01-frx5.facebook.com (185.60.216.35): icmp_seq=3 ttl=55 time=8.27 ms
^C
--- fb.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 8.225/8.271/8.312/0.082 ms
That being said, I did notice this a while back – not sure if that matters:
W: Conflicting distribution: http://download.mono-project.com/repo/ubuntu bionic/snapshots/5.20 InRelease (expected bionic/snapshots/5.20 but got bionic)
W: GPG error: https://mediaarea.net/repo/deb/ubuntu bionic Release: The following signatures were invalid: EXPKEYSIG C10E11090EC0E438 MediaArea <info@mediaarea.net>
E: The repository 'https://mediaarea.net/repo/deb/ubuntu bionic Release' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
So maybe I should just throw everything in a different network without IPv6 enabled. But I’m still confused why Sonarr is working fine, but Radarr isn’t.
so we know internal networking is good; here’s an issue that can crop up.
docker doesnt doesnt handle ipv6 properly… Its quirky as hell. I imagine that if you disable ipv6 on your docker network, the issue will be resolved. It should only take a few minutes to test the network change and see. please let us know what you find.
With that mono error, it could be worth doing as i suggested and blowing away radarr fully (including the config dir) and recreating it to see if that issue remains
Okay – throw all the containers (deluge, sonarr, radarr, bazarr, jackett and deluge) into a network without IPv6 and it works now.
Guess there’s something very wrong with my IPv6 setup.
Thanks !
That error with mono also happens in sonarr so might be a repo issue.
i dont think YOUR ipv6 setup was wrong at all, i think ipv6 in docker is just fucked 