Jabberwocky

Du meinst, dass alle Geräte, die per DHCP die IP von deinem Adguard als DNS bekommt, nicht ins Internet kommen, sobald der Adguard nicht läuft, richtig? Das wäre logisch soweit Nur die Geräte, denen du eine statische IP und als DNS deinen Router eingetragen hast, kommen in dem Fall weiterhin ins Internet.

Updated without any problems but have the "Drives wont spin-down"-Problem as well

Falls sich jemand (genau wie ich) nicht an die eigentliche Anleitung hält und in den selben Fehler läuft - mit den folgenden Schritten konnte ich es lösen: Alte Cache Platten wieder zum Cache hinzufügen damit werden die alten Inhalte auf den alten Platten gelöscht und mit den Inhalten von den neuen Cache Platten überschrieben - zum Glück hatte ich Inhalte bereits auf die neuen gespiegelt Anleitung lesen und die alten Platten sauber aus dem BTRFS Verbund entfernen -> https://docs.unraid.net/unraid-os/manual/storage-management/#remove-a-disk-from-a-pool Sicherheitshalber habe ich dafür Docker / VMs gestoppt, damit es zu keinen Inkonsistenzen kommt

Alternative statt PiHole/Adguard & Unbound: Technitium Vor ein paar Tagen bin ich über die Alternative "Technitium" zu PiHole / Adguard & Unbound gestolpert. Der DNS Server kann einfach über den App-Store installiert werden und bringt neben dem Ad-Blocking per Filterlisten bereits verschiedene Features von sich aus mit wie Rekursive Abfragen oder DOT / DOH usw. Im Gegensatz zu PiHole / Adguard ist er jedoch etwas technischer ausgelegt und hat mehr Funktionen - er kann für die ersten Schritte mit DNS-Sinkholes möglicherweise etwas zu viel sein. Ein Vorteil ist jedoch, dass er weniger Anpassungen / mehrere Docker-Container braucht und von Haus aus alles aus dem DNS Bereicht mitbringt. Da ich gerade etwas knapp bei Zeit bin nur kurz die Grundlagen: Installation über den App Store Installation läuft automatisch ab - die IP Adresse des DNS Server ist dann wie gewohnt in eurem Router (bspw. der Fritzbox wie auch beim PiHole/Adguard einzutragen (hier beschrieben: >Link<) Bei mir lief der DNS Resolver dann erstmal ohne weitere Einstellungen ohne Probleme - aber wir wollen ja das Adblocking haben. Hierzu im Webinterface von Technitium (erreichbar über das Technitium Icon im Docker Tab in Unraid oder direkt über die IP von Technitium) im Tab "Settings" und "Blocking" die Filterlisten eintragen. Hier können die selben nutzen wie bei PiHole / Adguard bspw. von https://firebog.net/ Nachdem ihr die Filterlisten eingetragen habt und Technitium über den DHCP eures Routers / Fritzbox in eurem LAN bekannt gemacht habt, sollte sich das Dashboard von Technitium bereits mit Abfragen der Clients füllen OPTIONAL: Damit im Dashboard aber nicht nur die IP Adressen eurer Clients stehen, könnt ihr noch eine neue "Zone" anlegen, damit Technitium den Namen der Clients bei eurem Router nachfragt. Hierzu geht ihr in Technitium auf "Zones" und legt dort eine neue Zone an mit den folgenden Details: Der Name der Zone spiegelt den IP Bereich eures LANs wieder - in meinem Fall also bei einem 192.168.0.X Netzwerk wie im Screenshot sichtbar. Wenn ihr den Bereich 192.168.178.X nutzt, müsst ihr also "178.168.192.in-addr.arpa." eintragen (der Punkt am Ende ist notwendig!) Unter "Forwarder" tragt ihr die IP eures DHCP Servers - also idR. eures Routers ein Die Zone sollte dann so aussehen: OPTIONAL: Zum Abschluss könnt ihr noch weitere DNS-Protokolle aktivieren, die Technitium für die Clients bereitstellen soll wie DOT, DOH oder DNS over Quic. Da der Zugriff der Clients bei euch im heimischen LAN geschieht, ist diese Verschlüsselung eigentlich nicht notwendig aber testen kann ja nicht schaden Das sollte es bereits sein Weitere Details gibt's unter: https://technitium.com/dns/help.html

Ich wollte gerade die Daten mit Unbalanced auf das Array schieben und den Cache-Pool einfach komplett neu anlegen aber der Cache Pool taucht in Unbalanced nicht auf - es wird nur das reguläre Array angezeigt. Die Daten auf dem Cache Pool sind aber zum Glück normal erreichbar und Docker usw. läuft ohne Probleme. Hat jemand eine Idee, was falsch gelaufen ist und wie man es beheben kann?

Hallo Unraid-Community, ich wollte bei meinem Unraid System die Festplatten aus dem Cache-Pool (btrfs auf 860 EVO SSDs) mit größeren (970 Evo M2s) tauschen und bin den Schritte hier gefolgt: Also die zwei neuen Festplatten ins System gesteckt und sie wurden ohne Probleme erkannt, diese dem Cache-Pool zugewiesen und den "btrfs device replace" Prozess durchlaufen lassen. Danach einmal neu gestartet und der Cache Pool war in Ordnung (temporär dann mit 4 Platten) und die Daten darauf waren verfügbar. Danach das Array gestoppt, die zwei alten Platten aus dem Cache Pool genommen und das Array neu gestart mit der Checkbox "Bei Start des Arrays wird die fehlende Cache Disk entfernt" (so ungefähr formuliert). Nun läuft alles wieder ohne Probleme jedoch habe ich in der Hauptübersicht weiterhin den Hinweis, dass der Cache nicht installiert ist. Bevor ich nun die alten Cache Platten komplett entferne - kann man den Cache wieder auf 2 Festplatten reduzieren? Danke & viele Grüße

Hello, in Unraid würde ich zum einen direkt auf die Fritzbox (leitet dann zum DNS vom PiHole / Adguard / Unbound weiter) und als Backup bspw. die DNS von Google hernehmen. So hast du, wenn PiHole / Adguard / Unbound noch nicht verfügbar sind bspw. bei einem Neustart von Unraid, auch weiterhin die DNS Auflösung über die public DNS. Viele Grüße

@Civic1201 Ich konnte den SERVFAIL Fehler nachstellen - er entsteht durch das DENSSEC vom Unbound und taucht im PiHole Log dann auf - in meinem Fall bei www.amazon.de (!) Nach einem Reload der Webseite, hat der Aufruf dann wieder normal geklappt. Das Problem kann scheinbar verschiedene Ursachen haben wie ich verstanden habe (siehe >> LINK << und >> LINK << und >> LINK <<) - wer hierzu noch Ideen hat, immer her damit DNSSEC wurde auf der aufgerufenen Webseite nicht korrekt implementiert Durchaus wahrscheinlich und möglich - wobei große Seiten wie Amazon das schon hinbekommen sollten denke ich Die Root Server für den rekursiven Aufruf sind nicht aktuell Sollte "eigentlich" keine Probleme machen, da sich diese nicht so oft ändern und Unbound bei jedem Update eine neue lädt Kann man mal aktualisieren indem man auf der CLI von Unraid (also NICHT im Docker Image von Unbound) Per Nano die Unbound.conf öffenen (je nachdem wo das Docker Image am Unraid liegt Und dieser diesen Hinweis beispielsweise bei den Basic Settings einfügst root-hints: root.hints Und die "root.hints" dann füllst mit curl --output /mnt/user/appdata/unbound/root.hints https://www.internic.net/domain/named.cache Das Ergebnis sollte dann so aussehen: Der Trust-Anchor ist nicht aktuell in der Anleitung ist in der unbound.conf explizit der root.key unter /var/root.key angegeben - durch den unbound-anchor Befehl wird eine zusätzliche "root.key" im Unbound Ordner angelegt, was aber keine Probleme machen sollte. Sieht man bei mir auch im vorherigen Screenshot, dass die Datei im Hauptverzeichnis unter der root.hints liegt Kann man aktualisieren, indem man eine CLI im Docker Image von Unbound öffnet Auf der nun recht schlichten CLI den folgenden Befehl absetzt unbound-anchor Nach dem Absetzen des Befehls bekommt man (leider) keine Bestätigung aber kann über den folgenden Befehl die root.key prüfen unbound-anchor -v Das Ergebnis sollte dann so aussehen Die Systemzeit vom Unbound ist nicht korrekt Zum prüfen hierzu einfach eine CLI im Docker Image von Unbound öffnen Und den folgenden Befehl absetzten date Als Ergebnis sollte dann deine Systemzeit zurückkommen. Bei Bedarf einfach updaten. Ich habe jetzt bei mir auch mal die root.hints und die roots.key aktualisiert und muss jetzt etwas beobachten, ob es nochmal auftritt - Fingers crossed

Hi @Civic1201 Interessant, der SERVFAIL kommt also aus dem DNSSEC von deinem Unbound (also der IP 192.168.178.6 in deinem Setup) - also das er s.z. die Echtheit der Domain nicht bestätigt bekommt, wodurch er statt einem "NOERROR" ein "SERVFAIL" zurückgibt. Zum Testen, wenn es wieder auftritt und um den Fehler eingrenzen zu können (frei nach >> LINK <<): Öffne die Kommandozeile von deinem Unraid-System (wenn der "Host Access to custom networks" noch aktiviert ist) Mache einen DIG testweise gegen deinen Unbound mit dem folgenden Befehl (ersetze die IP mit der IP von deinem Unbound) dig +dnssec www.cyberciti.biz @192.168.0.6 Er sollte dir nun einen "NOERROR" oder eben "SERVFAIL" zurück geben, wenn alles geklappt hat. Testweise kannst du auch noch den folgenden Befehl absetzten, der garantiert ein "SERVERFAIL" zurück gibt (wieder mit der IP von deinem Unbound). dig +dnssec www.dnssec-failed.org @192.168.0.6 Das Ergebnis sollte dann etwas so aussehen (also mit der jeweiligen IP von deinem Unbound): Damit kann man zumindest den PiHole als Fehlerursache ausschließen. Vielleicht liegt es daran, dass alte Root-Keys zur Prüfung verwendet werden (nach >> LINK << und >> LINK <<). Ich nehme an, dass ein SERVFAIL auch zustande kommen kann, wenn die DNSSEC Validierung wegen einem alten Root-Key nicht erfolgreich durchgeführt werden kann. "Eigentlich" sollten die Root-Keys bei jedem Start vom Container aktualisiert werden. Zum Checken: Öffne eine Konsole von deinem Unbound Docker Container Prüfe hier, ob der Root-Trust-Anchor aktualisiert wurde mit dem folgenden Befehl. unbound-anchor -v Wenn er keinen aktuellen Inhalt hat, kannst du es mit dem folgenden Befehl aktualisieren (er gibt keine explizite Bestätigung aus aber danach sollte der "unbound-anchor -v" dir eine nun positive Rückmeldung geben) unbound-anchor Das Ergebnis sollte dann so aussehen

Freut mich, dass es soweit funktioniert hat Ich habe es gerade nochmal getestet auf der https://fuzzthepiguy.tech/adtest/ und ich habe dort keine Werbung - ich habe im PiHole jedoch alle Listen von Firebog hinzugefügt. Die Adguard Chrome Erweiterung kenne ich leider nicht aber gibt es dort mglw. Einstellungen, wo du die Listen nachsehen kannst? Du solltest sie dort dann einfach kopieren und in Adguard einfügen können. Hier ein Screenshot der Einstellung der Erweiterung "uBlock", die letztlich dasselbe macht. Dort kommt man auf die Inhalte und die Quelle der jeweiligen Liste

Just changed my OneDrive Password so the access token in the OneDrive installation was not accepted anymore. In the logs it showed up as: ERROR: Microsoft OneDrive API returned an error with the following message: Error Message: HTTP request returned status code 400 (Bad Request) Error Reason: AADSTS70000: The user could not be authenticated as the grant is expired. The user must sign in again. Trace ID: XXXXXXX Correlation ID: XXXXXXX Timestamp: 2024-04-20 09:07:31Z ERROR: Microsoft OneDrive API returned an error with the following message: Error Message: HTTP request returned status code 401 () Error Reason: Access token is empty. Error Timestamp: 2024-04-20T09:07:31 API Request ID: XXXXXX ERROR: Check your configuration as your refresh_token may be empty or invalid. You may need to issue a --reauth and re-authorise this client. The old token can be removed / archived like this (adjust the path to the token accordingly to match your setup) mv /mnt/user/appdata/onedrive/username/refresh_token /mnt/user/appdata/onedrive/username/refresh_token.backup Afterwards start the re-authorization at STEP 13 of the guide again

@ich777 Sehr gerne aber ich bin gerade leider ziemlich zu mit Themen aus der Arbeit - ich melde mich bei dir, wenn ein Ende in Sicht ist, ok?

Ja, wollte ich auch nochmal ausprobieren aber bin leider noch nicht dazu gekommen. Der Vorteil von LXC ist ähnlich wie bei einem Hypervisor oder? Also man kann den Containern dediziert Ressourcen zuweisen?

@Curiosity Mit HomeAssistant habe ich leider keine Erfahrung aber ein paar Ideen: Kannst du versuchen beide Docker in das selbe Netz (in dem Fall br0 mit eigenen IPs / oder beide auf Host) zu setzten? Einzeln sind beide aber erreichbar oder? Nur die Verbindung zwischen den beiden funktioniert nicht?

Jup, sollte im Betrieb keine Probleme machen Von den Firebog Listen habe ich alle nicht-durchgestrichenen der verschiedenen Breiche Suspicious, Advertising, Trackings... (sind bei mir grob 1,4 Mio. Einträge im PiHole) im Einsatz und bisher noch keine Probleme damit gehabt. Im PiHole lassen sich die Listen auch recht leicht hinzufügen - einfach blockweise markieren und direkt im PiHole einfügen. Falls mal eine Seite nicht funktioniert, kannst du im PiHole über "Query Log" auch nachvollziehen, ob diese geblockt wurden und diese dann nachträglich auf die Whitelist setzten. Wenn es zu viele "False-Positives" sind, kannst du nachträglich die Listen auch einfach wieder reduzieren.

Jetzt etwas weiter gefasst, da ich es in der Anleitung am Anfang verlinkt habe Wenn du im Unbound Log unter /mnt/user/appdata/unbound/unbound.log die folgenden Warnmeldungen hast, sollte das kein Problem darstellen. Sie stellen eher einen Hinweis dar und sind keine Beeinträchtigung im Betrieb. warning: subnetcache: serve-expired is set but not working for data originating from the subnet module cache. warning: subnetcache: prefetch is set but not working for data originating from the subnet module cache. Für mehr Details siehe >Klick< Man kann diese vermeiden in dem man in der unbound.conf die beiden Parameter ändert und damit das Prefetching bzw. Cache-Verhalten ändert. serve-expired: no prefetch: no Im Alltag im heimischen LAN sollten das Deaktivieren idR. nicht bemerkbar sein. Erklärung der beiden Parameter: prefetch: <yes or no> If yes, message cache elements are prefetched before they expire to keep the cache up to date. Turning it on gives about 10 percent more traffic and load on the machine, but popular items do not expire from the cache. Default is "no". serve-expired: <yes or no> If enabled, Unbound attempts to serve old responses from cache with a TTL of serve expired-reply-ttl in the response without waiting for the actual resolution to finish. The actual resolution answer ends up in the cache later on. Default is "no".

Freut mich, wenn es funktioniert Die Option in der Fritzbox "Bei DNS Störungen auf öffentliche DNS Server zurückgreifen" könntest du als Notfall-Notfall-Option aktivieren - Probleme sollten dadurch nicht aufkommen. Als Beispiel und nach den Vorschlägen in der Anleitung: In der Fritzbox hast du im DHCP den DNS Server auf deinen PiHole/Adguard (der dann über Unbound auflöst) eingestellt. Damit lösen alle Geräte im LAN, die ihre IP & DNS per DHCP erhalten, über deinen PiHole/Adguard auf In der Fritzbox hast du den von der Fritzbox genutzten DNS Server auf PiHole/Adguard eingestellt (unter Internet -> Account Information -> DNS Server). Hier kannst du neben dem "Prefered DNS Server" (PiHole/Adguard) noch einen "Alternative DNS Server" (Bspw. 8.8.8.8) eintragen. Damit löst die Fritzbox selbst erstmal über PiHole/Adguard auf und wenn der nicht erreichbar ist, fragt es bei dem Alternativen DNS nach Hilfreich ist das für Geräte mit festem IP Setup wie beispielsweise dem Unraid System an sich. Bei einem Neustart kann Unraid ja nicht auf den PiHole/Adguard als DNS zurückgreifen, da dieser noch nicht gestartet ist. Damit kannst du in Unraid als DNS einfach deine Fritzbox eintragen - Initial löst diese dann über den Alternativen DNS Server auf und greift, wenn PiHole/Adguard wieder läuft, auf diesen zurück Die Option "Bei DNS Störungen auf öffentliche DNS Server zurückgreifen" wäre damit nochmal ein zusätzliches Backup, wenn sowohl dein "Prefered DNS.." als auch dein "Alternative DNS.." nicht erreichbar sind - was eigentlich sehr selten der Fall sein sollte, da gerade die großen DNS wie 8.8.8.8 von Google oder 1.1.1.1 von Cloudflare sehr stabil sein sollten

Also war davor "Pihole-DoT-DoH" und Unbound und die dig Abfrage direkt an Unbound schlug fehl. Und jetzt "Pihole" und Unbound und die dig Abfrage direkt an Unbound hat geklappt. Komisch, das sollte sich ja eigentlich nicht beeinflussen. Aber gut zu hören, dass es jetzt funktioniert! PS. Deine Unbound.conf sieht auf den ersten Blick auch i.o. aus

Hmm interessant, laufen tut er also aber er löst nicht auf, was man an dem SERVFAIL sieht. Mit anderen Adressen wie google usw. bekommst du vermutlich den selben Fehler zurück? PiHole läuft bei dir bereits ohne Probleme meintest du oder? VLAN / Firewall Einstellungen oder so hast du vermutlich nicht am laufen, was die x.x.x.208 blockieren könnte? Kannst du mal deine unbound.conf zum durchsehen anhängen oder posten?

Du hast einen Tippfehler in der dig Abfrage Ich gehe davon aus, dass dein Unbound auf der x.x.x.208 läuft. Probiert nochmal mit dig www.heise.de @192.168.178.208

Ich würde es so lassen, wie es ist (also sowohl Cache im Adguard als auch im Unbound) - der erste in der Abfragekette, der die Antwort auf eine DNS Anfrage im Cache hat, wird sie dann zurück geben. Dazu auch >Klick< Du kannst im Adguard noch DNSSEC und DOT / DOH deaktivieren, falls du es noch aktiv hast. Die eigentliche Abfrage wird ja durch Unbound durchgeführt und muss nicht doppelt verfiziert werden (DNSSEC) bzw. Unbound macht kein DOT / DOH.

Prima! Dann funktioniert also ein dig gegen Adguard ohne Unbound und ein dig gegen Unbound jeweils ohne Probleme nehme ich an? Dann sollte die Zusammenarbeit von beiden wie du geschrieben hast passen. Die Konfiguration von Adguard sollte auch passen - hier ist mMn. erstmal nur wichtig, dass dein Unbound als Upstream DNS eingetragen ist. Die zwei "Warnings" im Log sind kein Problem und nur als Hinweis von Unbound zu verstehen >Klick< (Hatte bzw. habe ich auch im Log) Zu dem DNS Leak Test: Das sollte so passen. Wenn du hier deine eigene IP siehst (kannst du nochmal prüfen bspw. mit www.ipchicken.com & What-is-my-dns-server) heisst es ja nur, dass du selbst der DNS Server bist bzw. der Besitzer von diesem bist - was mit Unbound ja gewollt ist >Klick< Auch passend die Erklärung auf der Seite "The owners of the servers above have the ability to associate your personal IP address with the names of all the sites you connect to and store this data indefinitely." Ich füge oben noch ein paar Links zu Testmöglichkeiten für PiHole / Adguard & Unbound und dem erwarteten Erebnis hinzu

Klasse & gerne - freut mich, wenn es funktioniert und jemandem weiterhilft. Hatte schon befürchtet, dass ich irgendeinen Schritt übersehen habe Der "Host access to custom networks" sollte nur für die Tests per dig notwendig sein und nicht für die eigentliche Verbindung zwischen PiHole / Adguard & Unbound. Macht es aber einfacher zum testen finde ich. Ich habe es oben mal als Vorbereitung aufgenommen und entsprechend kommentiert. Kann man eigentlich Posts nachträglich einfügen? Dann tippe ich mal noch Wiregurad & Adguard / PiHole als typischen UseCase zusammen und verlinke es. Hatte da eine etwas veraltete Anleitung aber hat nach etwas anpassen dann noch geklappt.

Kannst du mal in Unraind unter "Settings" -> "Docker" -> "Host access to custom networks" aktivieren und es nochmal testen? Es sollte dann so aussehen (mit dem IP Bereich von deinem LAN & eventuell durchgeführten Anpassungen natürlich):

Neue Idee: Kannst du mal in deinen Unraid Settings unter Docker den "Host access to custom networks" aktivieren? Funktionert es dann? Sollte dann so aussehen (mit deinem IP Bereich & eventuell durchgeführten Anpassungen natürlich)(oben im Guide neu hinzugefügt): Hast du im Adguard möglicherweise noch einen Backup DNS eingetragen? Das würde erklären, dass er, obwohl er auf einen Timeout läuft, dennoch funktioniert. Falls es mit dem Custom Network noch nicht gelöst ist - Kannst du deine unbound.conf mal posten / hier anhängen und einen Screenshot von der Konfiguration des Unbound Containers machen?