Hallo zusammen.
Seit einigen Tagen habe ich das Problem wenn ich in der Menüleiste "Apps" anklicke bekomme ich nach einiger Zeit folgende Fehlermeldung.
Auch kann ich keine Updates für den die Docker Apps und für die Plugins mehr durchführen.

"Download of appfeed failed.

Community Applications requires your server to have internet access. The most common cause of this failure is a failure to resolve DNS addresses. You can try and reset your modem and router to fix this issue, or set static DNS addresses (Settings - Network Settings) of 208.67.222.222 and 208.67.220.220 and try again.

Alternatively, there is also a chance that the server handling the application feed is temporarily down. See also this post for more information

Last JSON error Recorded: Syntax error".

Jedoch hatte ich an den Einstellungen nichts geändert gehabt.
Die empfohlenen Settings sind auch eingetragen.

Woran kann das liegen?

Gruss Ralf

6 hours ago, eFrame said:

Jedoch hatte ich an den Einstellungen nichts geändert gehabt.
Die empfohlenen Settings sind auch eingetragen.

Woran kann das liegen?

meistens Provider DNS Thema oder lokales DNS Problem (adguard, pihole, ... im Einsatz ?), Firewall im Einsatz ? unify und co ...

oder auch mal Hardware wie ich gerade hart feststellen musste, mein zentraler Switch war defekt, also neuen bestellt, hat auch wunderbar alle 10G Anschlüsse synced, aber ich bekam immer mehr Probleme mit Endgeräten, erst Server wo macvlan nichts mehr außen erreicht hatte, dann Handys wo oft Aussetzer hatten, dann Teams Meetings wo ich auf einmal bei meinen Teilnehmern weg war (ich hab alles gesehen und gehört ...), usw usw ... Zimmer Switches getauscht, sfp+ Module gewechselt wie wild, Router getauscht, ... am Ende blieb nur noch der (neue) switch oder Provider, siehe da, gestern kam der neue switch, alles wieder ok ... hat mich in Summe gut 2 ganze Tage Nerven gekostet ...

kurz, es kann vieles sein, ping mal vom Server aus ghcr.io oder github.com um zu schauen wie es darum steht.

Und, zur Weihnachtszeit hin wird es auch gerne mal schlechter mit Verbindungen zu gewissen Seiten wegen massivem Traffic ;)

Ja, Du solltest Dich mal auf die UNRAID shell bewegen und mit "nslookup" testen, ob da überhaupt noch was rauskommt:

root@F:~# nslookup

> server

Default server: 192.168.0.6

Address: 192.168.0.6#53

Default server: 192.168.0.9

Address: 192.168.0.9#53

Default server: fd00::6

Address: fd00::6#53

> www.heise.de

Server: 192.168.0.6

Address: 192.168.0.6#53

Non-authoritative answer:

Name: www.heise.de

Address: 193.99.144.85

Name: www.heise.de

Address: 2a02:2e0:3fe:1001:7777:772e:2:85

>

als beispiel

(Der Befehl "server" zeigt Dir an, welche Server konfiguriert sind, die Abfrage später zeigt an, welcher davon auch benutzt wird)

(Und ja, die Adresse FD00... zeigt an, dass UNRAID bei IPV6 noch einiges aufzuholen hat (man kann keine statischen und dynamischen Adressen mischen, dumm gelaufen))

Damit Apps und Plugins abgerufen werden können, werden einige Hosts benutzt und abgefragt: (Liste ggf. unvollständig)

• registry-1.docker.io

• auth.docker.io

• raw.githubusercontent.com

• stable.dl.unraid.net

• github.com

• release-assets.githubusercontent.com

• ca.unraid.net

Versuche alle diese Namen aufzulösen und ggf anzupingen (mag bei einigen eventuell blockiert sein).

Edited December 20, 2025Dec 20 by MAM59

Hatte das auch schon öfters. Nervt ungemein. Nach Neustart hält es wieder ne Weile

On 12/20/2025 at 1:11 AM, eFrame said:

Woran kann das liegen?

Gib mal auf der Unraid Konsole folgendes ein:

traceroute www.heise.de

Damit siehst Du wie weit Du kommst.

14 minutes ago, hawihoney said:

traceroute www.heise.de

Damit siehst Du wie weit Du kommst.

Keine schlechte Idee (sofern er die Namen überhaupt auflösen kann). Allerdings muß man darauf hinweisen, dass Heise zwar PINGs erlaubt, traceroutes von Linux aber blockt (tracert von Windows geht durch, aber der funktioniert auch komplett anders).

Also: erst gucken, ob Namen gehen, dann "ping".

Wenn der nicht geht, dann traceroute und protokollieren, wie weit man kommt.

(ein besseres "Opfer" ist z.B www.bahn.de, da geht auch der traceroute komplett durch)

Einfach mal das Ergebnis abwarten.

1.) Kann nicht aufgelöst werden - wirds angezeigt.

2.) Kommt er nicht aus Unraid raus - wirds angezeigt

3.) Kommt er nicht raus aus seinem Netzwerk - wirds angezeigt.

4.) Bleibt er irgendwo draußen hängen - wirds angezeigt.

Es soll ja nur der Weg raus aus seinem Netzwerk geprüft werden. heise.de habe ich aus der Diskussion oben rauskopiert. Die Domäne ist dafür irrelevant.

Ich tippe auf 1. oder 2.

root@Tower:~# traceroute www.heise.de

traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets <--- er kann auflösen

1 fritz.box (192.168.178.1) 1.085 ms 1.340 ms 1.564 ms <--- er kommt aus Unraid raus

2 p3e9bf1dc.dip0.t-ipconnect.de (62.155.241.220) 16.814 ms 16.847 ms 16.896 ms <--- er kommt aus seinem Netzwerk raus

3 f-ed12-i.F.DE.NET.DTAG.DE (217.0.195.6) 18.628 ms f-ed12-i.F.DE.NET.DTAG.DE (217.5.115.114) 22.596 ms f-ed12-i.F.DE.NET.DTAG.DE (62.154.18.110) 19.484 ms

4 62.157.251.38 (62.157.251.38) 28.130 ms 28.762 ms 28.836 ms

5 82.98.102.7 (82.98.102.7) 28.065 ms 82.98.102.71 (82.98.102.71) 28.075 ms 28.557 ms

Das Ganze etwas moderner (und mit halber Latenz) sieht so aus:

root@F:~# traceroute www.heise.de

traceroute to www.heise.de (2a02:2e0:3fe:1001:7777:772e:2:85), 30 hops max, 80 byte packets

1 ipv6-addr.wco.de (2a02:2c60:f18a:73b0:ab6:57ff:fe8d:401f) 0.236 ms 0.201 ms 0.177 ms

2 ipv6-addr.wco.de (2a02:2c60:a000::1) 10.759 ms 10.736 ms 10.713 ms

3 ipv6-addr.wco.de (2a02:2c60:a001:11::2) 10.688 ms 11.948 ms 10.642 ms

4 2a02:5a0:1f02:ff03::2 (2a02:5a0:1f02:ff03::2) 10.621 ms 10.598 ms 10.575 ms

5 et-2-0-5.0.vs-core-r1.6838.ip.vsenet.de (2a02:5a0:301:12::236:17) 11.742 ms 11.719 ms 47.202 ms

6 et-2-0-2.0.vs-core-r2.6838.ip.vsenet.de (2a02:5a0:301:11::236:18) 10.487 ms 10.742 ms 10.713 ms

7 * * *

8 * * *

9 2a02:2e0:3fe:0:c::1 (2a02:2e0:3fe:0:c::1) 15.661 ms !X 16.455 ms !X 15.971 ms !X

Hmm interessant zu sehen, wieviel schneller "neue" Fritzboxen (0.2ms) im Vergleich zu "alten" (1,3ms) reagieren... Obwohl, in der Praxis merkt man wohl kaum was vom Geschwindigkeitsunterschied, aber es summiert sich auf...

Hallo zusammen.
Ich habe jetzt mal folgende Versuche gemacht.
Wenn ich es richtig interpretiere kann Unraid nach draussen kommunizieren, oder sehe ich das Falsch?

root@Eframeserver:~# traceroute www.heise.de

traceroute to www.heise.de (193.99.144.85), 30 hops max, 60 byte packets

1 Eframeserver.fritz.box (192.168.2.19) 100.080 ms !H 100.068 ms !H 100.060 ms !H

root@Eframeserver:~# traceroute fritz.box

traceroute to fritz.box (192.168.2.1), 30 hops max, 60 byte packets

1 fritz.box (192.168.2.1) 0.662 ms 0.893 ms 1.081 ms

root@Eframeserver:~# traceroute p3e9bf1dc.dip0.t-ipconnect.de

traceroute to p3e9bf1dc.dip0.t-ipconnect.de (62.155.241.220), 30 hops max, 60 byte packets

1 Eframeserver.fritz.box (192.168.2.19) 953.136 ms !H 953.118 ms !H 953.107 ms !H

root@Eframeserver:~# traceroute 62.157.251.38

traceroute to 62.157.251.38 (62.157.251.38), 30 hops max, 60 byte packets

1 Eframeserver.fritz.box (192.168.2.19) 2310.650 ms !H 2310.632 ms !H 2310.624 ms !H

Das siehst Du falsch, aber sowas von...

Nur bis zur Fritzbox gehts, dann ist Sabbat. (na ja, geht eigentlich bis zu allen Kisten im LAN, aber eben NICHT ins Internet)

Komischerweise scheint die Defaultroute auf diesen "EFrameserver.Fritz.Box" (192l168.2.19) zu zeigen und nicht auf die Fritzbox selber (192.168.2.1) ?

Das geht dann auch voll in die Hose, wie man an den vernichtenden Kritiker ("!H") sehen kann.

Was und Wo hast Du denn als Defaultroute eingestellt (sollte bei DHCP ja automatisch und richtig gesetzt werden...) ???

Danke für die Info.
Wo stelle ich denn die Defaultroute ein?
In Unraid selbst?
Ich habe nie was bewusst verstellt gehabt

Edited December 27, 2025Dec 27 by eFrame

4 minutes ago, eFrame said:

Wo stelle ich denn die Defaultroute ein?
In Unraid selbst?

na ja, kommt drauf an. Wenn Du DHCP aktiviert hast, dann wird sie von dem Server geliefert, bei statischen Adresse wird sie von Hand in Unraid selbst eingestellt.

(Die Felder werden aber erst sichtbar, wenn man das Array stoppt!)

Und da gehört dann die Adresse der Fritzbox rein!!!

So sieht es bei meinem Server aus.
Ich habe eine Melanox 10Gbe installiert.

Ich sehe unten auch eine Meldung bezüglich des Ethernet Ports.

30 minutes ago, eFrame said:

Ich habe eine Melanox 10Gbe installiert.

Und was ist dann eth1? Wie sehen die Einstellungen aus? Brauchst du wirklich ein Bonding?

Just now, _alo_ said:

Und was ist dann eth1? Wie sehen die Einstellungen aus? Brauchst du wirklich ein Bonding?

Das steht bei mir unter eth1

Also ich verstehe ja die Idee hinter diesem Bond, allein, sie funktioniert so nicht. Es ist recht unschlau Karten mit unterschiedlichen Geschwindigkeiten in einem Bond zusammenzufassen. Der Kernel weiss dann nicht so genau, wie schnell er die Pakete loswerden kann und die Queue Berechnung kommt durcheinander. Das ist dann Stottern bis hin zu Blockaden mit Abbrüchen.

Also:

• deaktiviere den Bond auf beiden Karten

• geh in die Netzwerkregel und vertausche die MAC Adressen in den Listboxen (eth0 und eth1 tauschen dann die Karten, die Mellanox ist dann die "Haupt"karte)

• das Defaultgateway sieht richtig aus, allerdings sorgt die Metrik von 1008 (oder so), dafür, dass es unter Umständen gar nicht zum Zug kommt. Hier gehört eine "1" rein

Danke für die tolle Hilfe hier.
Ich schätze mal das der Bond daraus resultierte weil ich vor knapp 2 Jahren die Mellanox 10Gbe eingebaut hatte in dem bestehenden Unraid System.
Ich habe nachdem ich der Beschreibung von @MAM59 gefolgt bin, die Onboard 1Gbe im Bios deaktiviert.
Jetzt ist nur noch die Mellanox 10Gbe aktiv. Der Verbindungsfehler tritt jetzt nicht mehr auf :-)