keine Möglichkeit PI-Hole zu administrieren

[symbol]

@ all,

ich nutze eine DS418 play und habe es heute geschafft PI-Hole im Docker zu installieren.

Nur wenn ich PI-Hole administrieren möchte, bekomme ich leider keinen Zugriff. Getestet habe ich mit dem Edge und Vivaldi, ich nutze nur diese zwei Browser.

Ich tippe in das Browserfeld "192.168.1.25:8080/admin" und erhalte dann die Meldung:

Diese Website ist nicht erreichbar​

192.168.1.25 hat die Verbindung abgelehnt.


Versuchen Sie folgendes:

• Verbindung prüfen
• Proxy und Firewall prüfen

ERR_CONNECTION_REFUSED

Hat jemand einen hilfreichen Tip für mich, was zu tun ist um Zugriff zu erhalten. Wenn möglich einfach erklären, bin schon ein wenig älter, Ü60

Danke,

Symbol

 

[Benie]

http://synology-ip-address: 8080/admin/login

Poste doch mal bitte die von Dir verwendete Yaml oder den Stack

 

[Skyhigh]

Wenn das ,ist dem Link von @Benie nicht klappt,

Könnte das auch mit einem Bug im FTL 6.1 (und auch vereinzelt nach dem hotfix mit 6.2 noch ) zusammen hängen welcher ein "Segmentation Fault" in der /etc/pihole/pihole-FTL.db erzeugt.
Dann crasht der FTL-Service direkt beim Start des Hosts oder Containers.

Passiert bei mir auch hin und wieder, ist bei GitHub bereits gemeldet und hat den Status "fixed in next release"

Wenn du per SSH Zugriff hast, kannst du die pihole-FTL.db einfach löschen oder umbenennen und dann den Host neu starten. Sie wird automatisch neu erzeugt.

 

[symbol]

http://synology-ip-address: 8080/admin/login

Poste doch mal bitte die von Dir verwendete Yaml oder den Stack

Wenn ich den folgenden Link: http://192.168.1.25: 8080/admin/login eingebe in den Browser wird ein neue Fenster geöffnet, sie Anhang.

Was bedeutet Yaml oder Stack?

Danke, Symbol

 

[Annika Hansen]

Da ist ein Leerzeichen zwischen dem : und 8080, deswegen klappt das nicht.
Entferne das Leerzeichen bitte, so dass die URL so aussieht: http://192.168.1.25:8080/admin/login und rufe die URL dann nochmal auf.

Der Begriff YAML bezieht sich auf eine Datei mit dem Namen docker-compose.yaml, also das YAML configuration file, in dem alle Informationen zur Verwaltung von Diensten, Netzwerken und Volumes des gesamten Anwendungsstacks zusammengefasst werden. Danach hat @Benie gefragt und das hilft bei der Analyse von Problemen ungemein. Oder noch besser, Du beschreibst mal, wie Du pi-hole bei Dir installiert hast.

 

[Benie]

Danke Dir.

Das stimmt, ich habe da nicht drüber nachgedacht, daß Leerzeichen entsteht bei mir auf dem Handy an solchen Stellen von alleine, da habe ich es vergessen zu löschen.

(irgendwie auch doof, ich kann das nicht ändern, daß das automatisch gemacht wird. )

 

[Skyhigh]

Sorry etwas OT aber @Benie:
Es steht zwar "nur US" dabei, ist inzwischen aber fast weltweit aktiv.
Hast du folgende Einstellung nicht?

 

[Benie]

Ich weiß was Du meinst, aber auf dem Handy welches ich meistens nutze Nein, leider nicht vorhanden!

 

[symbol]

@ all,

ich nutze eine DS418 play und habe es heute geschafft PI-Hole im Docker zu installieren.

Nur wenn ich PI-Hole administrieren möchte, bekomme ich leider keinen Zugriff. Getestet habe ich mit dem Edge und Vivaldi, ich nutze nur diese zwei Browser.

Ich tippe in das Browserfeld "192.168.1.25:8080/admin" und erhalte dann die Meldung:

Diese Website ist nicht erreichbar​

192.168.1.25 hat die Verbindung abgelehnt.


Versuchen Sie folgendes:

• Verbindung prüfen
• Proxy und Firewall prüfen

ERR_CONNECTION_REFUSED

Hat jemand einen hilfreichen Tip für mich, was zu tun ist um Zugriff zu erhalten. Wenn möglich einfach erklären, bin schon ein wenig älter, Ü60

Danke,

Symbol

@ all,

ich möchte nur ein kurzes Update geben. Danke an alle Erklärungen aber ich habe den Raspi wieder aktiviert und der Pi-Hole läuft darauf wie gewohnt und auch das administrieren geht wie gewohnt.
Ja es ist ein Gerät mehr aber wenn es für mich gut funktioniert, alles gut.

Sommerliche Grüße aus Manitoba, Canada.

 

[senderversteller]

Der Thread kommt grad passend, denn ich habe ein recht ähnliches Problem:

Ich habe pi-hole direkt auf dem Hostsystem eines Raspberry Pi laufen; daneben läuft noch Docker mit Portainer und ein paar Sachen wie z.B. Homebridge darin.

Es ist bei mir nun schon am 2. Sonntag in Folge um ab ca. 7 Uhr so gewesen, dass die Weboberfläche des Pi-Hole auf einmal nicht mehr erreichbar war und das Pi-Hole keine DNS Anfragen mehr aufgelöst hat (Internet tot). Portainer ist auch nicht erreichbar, im Docker läuft unter anderem Homebridge, Uptime Kuma, ist alles nicht mehr erreichbar - weder über die Adminoberfläche noch die Dienste selbst (z.B. die Geräte über die Bridge in Apple Home).

Ich bin also per ssh auf den Pi und habe ihn neu gestartet. Ihr seht (z.B.) die Client Activity in Pi-Hole also auch das Uptime Kuma im Container hat ab 7:00 ein Loch - bis zum Neustart...



Da es nun schon das zweite Mal in Folge am Sonntag um 7:00 passiert ist, glaube ich nicht an einen Zufall. Was kann auf dem System schief gehen, dass das passiert? Was kann ich beim nächsten Mal prüfen, wenn es wieder auftritt. Kann sich jemand einen Reim drauf machen?

 

[Stationary]

Das Problem dürfte ein ganz anderes sein als im Ursprungspost.
Hast Du mal uptime kuma deaktiviert? Passiert das dann auch? Es gab früher mal Berichge, das Uptime Kuma crasht und den ganzen Server mitreißt.

 

[senderversteller]

Da es zwei Mal in Folge am Sonntagmorgen um 7:00 passiert, dachte ich nicht an einen spontanen Crash sondern an etwas, was genau an dieser Zeit passiert.
Ich kann den Container von Uptime Kuma am Samstagabend mal beenden und dann sehen, ob es am kommenden Sonntag wieder passiert.

 

[Stationary]

Du könntest mal mit

journalctl -s "2025-xx-yy"

(wobei xx der Monat und yy der Tag sind) ins Log des Raspi schauen und hier posten. Vielleicht läßt sich da etwas erkennen. Eine doppelt zugewiesene IP oder etwas in der Art.

 

[senderversteller]

Ok, das Log geht aber nur bis zum letzten Boot. Da muss ich nochmal warten bis es wieder passiert.

 

[senderversteller]

Hab den "Übeltäter" danke des Log gefunden. Es war das raspiBackup Script, was ich versehentlich zum täglichen Backup am Sonntag um 7:00 aktiviert habe - das fährt alle Dienste runter. Danke @Stationary

 

[Annika Hansen]

@senderversteller: Bist Du sicher? Denn wenn ich ehrlich bin, dann verstehe ich diese Erklärung nicht. Das raspiBackup Script stoppt zwar Dienste auf dem Raspberry, nach Beendigung des Backup werden diese aber wieder hochgefahren. D.h. nach dem Backup läuft alles wie vorher, auch Pi-hole.

Bei mir dauert das Backup meines Raspberries mit raspiBackup ca. zwei Minuten und nach Abchluß des Backup funktioniert alles wie vor Beginn des Backup. Die Lücke von zwei Minuten sieht man noch nicht mal in der Übersicht von Pi-hole. So läuft es bei mir seit längerem ohne Probleme. Von daher wundert mich Deine Aussage ein wenig.

 

[senderversteller]

@Annika Hansen Doch, es war definitiv das raspiBackup.

Der Grund, warum das bei mir so lange aussetzt ist die Tatsache, dass ich vermutlich das initiale Backup noch nicht komplett ausgeführt habe. Für ein "gutes" Backup - so habe ich die Dokumentation verstanden - sollte während dem Backup immer möglichst alle Dienste beendet werden, damit man am Ende kein "inkonsistentes Backup" hat...

Als ich mich das erste Mal damit beschäftigt habe, wollte ich das den Ordner /backup auf dem Raspberry per NFS auf meine DS mounten und das Backup direkt auf die DS schreiben. Das ging allerdings quälend langsam und so lange konnte und wollte ich in dem Moment nicht auf Pi-Hole verzichten, weil dann hier garnix geht... ich habe also abgebrochen und das Thema irgendwie vergessen. Aber der Cronjob von raspiBackup war noch aktiv. Und dann kam das eben heraus

Aber weil wir grad beim Thema sind, vielleicht kann ich das doch mal korrekt in Betrieb nehmen...
Ist das normal, dass das erste Backup per NFS so lange dauert?
Zunächst kurz wie ich den Mount durchgeführt habe. Sind das die richtigen Parameter um den Mount vom NAS zu Raspberry korrekt durchzuführen?

Ich habe folgende Zeile in /etc/fstab eingefügt:

# Entry for the NAS backup, mount with NFS version 3
# 192.168.10.222:/volume1/Backup/RaspiBackup /backup nfs rw,nfsvers=3 0 0
# Entry for the NAS backup, mount with NFS version 4
192.168.10.222:/volume1/Backup/RaspiBackup /backup nfs4 default,nofail 0 0

Die auskommentierte Zeile wäre für NFSv3, aber NFSv4 funktioniert auch...

Im Freigegebenen Order habe ich folgende Einstellung:


In den Einstellungen zu den Dateidiensten habe ich folgende Einstellung:




@Annika Hansen Deinen Worten entnehme ich, dass wenn das erste Backup durchgeführt ist - die Folgebackups wesentlich schneller vonstatten gehen? Ist das korrekt? D.h. einmal durchführen, wenn Pi-Hole nicht gebraucht wird... die inkrementellen Backups gegen dank rsync schneller? Ist das so korrekt?

 

[Annika Hansen]

An die Mods und/oder Admins: Da das jetzt ein wenig sehr OT wird, vielleicht sollte man das in einen neuen Thread "Probleme bei raspiBackup und Synology" verschieben. Nur so eine Idee...

@senderversteller: Ich habe mich gegen ein Backup mit rsync entschieden, da raspiBackup im Zusammenspiel mit Synos Probleme bei dem Speichern von ACLs hat. Mit anderen Worten: das Backup bricht ab. Ich habe das eben nochmal kurz angetestet:

08-03-2025 15:58:40 --- RBK0085I: Backuperstellung vom Typ rsync gestartet. Bitte Geduld
rsync: [receiver] set_acl: sys_acl_set_file(etc/.rbfeeder.ini.TTnbU9, ACL_TYPE_ACCESS): Operation not supported (95)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1333) [sender=3.2.3]
...
08-03-2025 16:08:24 ??? RBK0021E: Backupprogramm des Typs rsync beendete sich mit RC 23
08-03-2025 16:08:24 --- RBK0033I: Bitte warten bis aufgeräumt wurde
08-03-2025 16:08:27 --- RBK0320I: Unvollständiges Backup wird gelöscht. Das kann etwas dauern. Bitte Geduld

Für Dich zur Info: das initale (leider gescheiterte) Backup mit rsync dauerte ca. 10 Minuten.

Vielleicht gibt es eine einfache Lösung für dieses ACL-Issue, ich habe das aber nicht weiter untersucht. Also habe ich den Backup-Typ auf "tar" umgestellt, bei dem dieses Problem nämlich nicht auftritt. Kleiner Nebeneffekt: das Backup dauert jede Nacht nahezu gleich lang, bei mir sind das ca. 2 Minuten. Weiterhin nutze ich die Optionen "--preexec" und "--postexec" um meine Docker Container zu "managen" (siehe Details dazu unter 3. und 4.).

Mein Setup sieht wie folgt aus:

1. Eintrag in /etc/fstab:

# Backup storage on DS1019+
ds1019:/volume1/backup /mnt/backup nfs nfsvers=3,rw,_netdev,noauto,x-systemd.automount,x-systemd.device-timeout=10 0 0

2. Crontab für raspiBackup in /etc/cron.d/raspiBackup:

MAILTO=""

29 00 * * *  root mount /mnt/backup
30 00 * * *  root /usr/local/bin/raspiBackupWrapper.sh --preexec /usr/local/bin/pre_backup.sh --postexec /usr/local/bin/post_backup.sh /mnt/backup/raspi
45 00 * * *  root umount /mnt/backup

3. Skript /usr/local/bin/pre_backup.sh:

#!/bin/bash

echo "Stop all docker containers before starting the backup"

/usr/bin/docker stop vaultwarden
/usr/bin/docker stop caddy
/usr/bin/docker stop kmip-server-dsm-kmip-server-dsm-1
/usr/bin/docker stop beszel-agent
/usr/bin/docker stop beszel
/usr/bin/docker stop pihole

Das Skript habe ich eingeführt um sicher zu sein, dass alle Docker Container sauber gestoppt werden (mir ist nicht ganz klar, wie das raspiBackup Script das macht, das ja auch docker runterfährt). Vermutlich ist das nicht notwendig, schaden kann es aber auch nicht.

4. Skript /usr/local/bin/post_backup.sh:

#!/bin/bash

echo "Start all docker containers after the backup has finished"

/usr/bin/docker start pihole
/usr/bin/docker start caddy
/usr/bin/docker start vaultwarden
/usr/bin/docker start kmip-server-dsm-kmip-server-dsm-1
/usr/bin/docker start beszel
/usr/bin/docker start beszel-agent

Ich hoffe das hilft Dir ein wenig weiter.

Nachtrag:
Was ich vergessen hatte zu erwähnen, ist dass Du bei raspiBackup die Services/Dienste angeben kannst, die vor dem Backup gestoppt und nach dem Backup gestarten werden sollen - aber vermutlich weißt Du das:

# Durch && getrennte Befehle, die vor dem Starten des Backups auszuführen sind
DEFAULT_STOPSERVICES=...
# Durch && getrennte Befehle, die nach dem Starten des Backups auszuführen sind
DEFAULT_STARTSERVICES=...

 

[senderversteller]

Danke @Annika Hansen Ich werde es trotzdem mal versuchen mit rsync heute Nacht komplett durchfahren zu lassen, da ich keine ACLs sichern möchte. Laut dem Video von @framp macht rsync mit ACLs Probleme. Da mein Raspberry Pi allerdings unter RaspianOS läuft, sollte das nicht der Fall sein.

 

[hatrue]

Bei Problemen mit PiHole auf Docker....
ich habe vor ca. 2 Jahren eine VM mit Raspberry Pi installiert und darauf läuft mein PiHole. Ab und zu klone ich den Raspberry.
Leider weiss ich nicht mehr woher ich das image (raspios-bullseye-i386) hatte. Dachte die wurde mir direkt auf der Syno als Download angeboten. Meine anderen VM habe ich die Image direkt vom Hersteller runter geladen