Jabberwocky

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?