Hi!

 

Not sure why, but Community Applications can't connect and it's telling me I need to "set static DNS addresses (Settings - Network Settings) of 208.67.222.222 and 208.67.220.220" and try again.

 

I know what DNS servers are and all that, but that's pretty vague.  Can anyone shed a little more light on what that means?

 

Thank you!

It's simply suggesting ti use a static DNS instead of whatever your router is using and is telling you where to set it

4 minutes ago, Squid said:

It's simply suggesting ti use a static DNS instead of whatever your router is using and is telling you where to set it

...oh...well hell, that's simple enough.  Thanks.

14 minutes ago, Squid said:

It's simply suggesting ti use a static DNS instead of whatever your router is using and is telling you where to set it

I am still getting the error so I decided to uninstall and reinstall Community Applications.  Uninstalled and it won't install.  

I noticed that, when I go to the terminal and try to ping out, I get no responses.  How can unRAID not have any network access but the VMs do?  Am I missing something?

 

Not sure what exactly "bonding" does in unRAID, let alone "active backup"...

Greetings,

I had a weird quirk like this a few weeks ago. This may or may not be your problem. You can check in two ways:

- In Settings -> Network - make sure your default route is set to the correct gateway.

or

- In terminal type either:

ip r

route

Route can take a moment to finish - check the default route is set to the proper gateway.

 

You should also check that you don't have any odd routing - you'll likely have 4-6 routes for internal routing which is fine - they should generally only point to internal (non routable) networks.

You can quite possibly sort this out using the Network Settings - delete the wrong route and add a new default route. 

Verify the correct settings are seen in /boot/config/network.cfg - edit if needed.

 

In Terminal you could do it this way:

You can try deleting and adding a new default gateway.

Using the information you gathered earlier - note down the correct interface - probably br0 and the correct gateway IP address and the incorrect ones then:

# route delete default gw <incorrect gateway ip> <incorrect current interface>

and then

# route add default gw <correct gateway ip> <correct interface>

you might need to finish with:

# ip route flush cache

 

Hopefully this helps,

Del

Edited January 25, 20206 yr by Delarius
accidentally pressed save earlier

15 minutes ago, Delarius said:

Greetings,

I had a weird quirk like this a few weeks ago. You can check in two ways:

- In Settings -> Network - make sure your default route is set to the correct gateway.

or

- In terminal type either:

ip r

route

Route can take a moment to finish - check the default route is set to the proper gateway.

 

You should also check that you don't have any odd routing - you'll likely have 4-6 routes for internal routing which is fine - they should generally only point to internal (non routable) networks.

Verify the correct settings are seen in /boot/config/network.cfg - edit if needed.

You can try deleting and adding a new default gateway.

Using the information you gathered earlier - note down the correct interface - probably br0 and the correct gateway IP address and the incorrect ones then:

# route delete default gw <incorrect gateway ip> <incorrect current interface>

and then

# route add default gw <correct gateway ip> <correct interface>

you might need to finish with:

# ip route flush cache

 

 

You nailed it, my friend!  I scrolled down to the routes and it was aaaaaaaaaaaall screwed up.  Route delete, route add, boom.  Good to go.

Thank you!!

Glad I could help,

I'm fairly sure libvirt has its own way of figuring out routing, so that's why your VMs and quite possibly dockers were still working.

Del

Edited January 25, 20206 yr by Delarius

25 minutes ago, Delarius said:

Glad I could help,

I'm fairly sure libvirt has its own way of figuring out routing, so that's why your VMs and quite possibly dockers were still working.

Del

Well, either way, we're good to go now.  Thanks!