Geschätzte Lesezeit: 2 Minuten

Vor ein paar Tagen stieß ich auf ein merkwürdiges Problem: Pi-Loch läuft auf Docker, in meinem NAS-basierten OpenMediAvault, warf ständig unerklärliche Fehler in das Protokoll pihole-FTL. Anscheinend hat alles funktioniert, aber Zeilen wie diese tauchten im Protokoll auf:

ERROR: SQLite3: disk I/O error in "SELECT VALUE FROM ftl WHERE id = 0;"
WARNING: Database not available, please ensure the database is unlocked when starting pihole-FTL !

oder nochmal:

ERROR: SQLite3: os_unix.c:43514: (19) mmap(/etc/pihole/pihole-FTL.db-shm)

Nach ein wenig Recherche und Tests wurde mir klar, dass das Problem nicht Pi-hole war, geborener Docker, aber Fusionen, das Dateisystem, das ich verwende, um mehrere Festplatten in einer einzigen Freigabe zusammenzuführen.

---

Das Problem

Für diejenigen, die ihn nicht kennen, Fusionen ist Union-Dateisystem basierend auf FUSE, Sehr praktisch zum Erstellen eines großen „virtuellen“ Volumes ausgehend von mehreren physischen Festplatten. Ich verwende es seit Jahren auf OpenMediaVault, um meine Daten und Backup-Discs zusammenzufassen.

Jedoch, Es gibt ein kleines Detail: FUSE verarbeitet Shared-Memory-Vorgänge nicht gut (mmap) die einige Programme verwenden, um schnell auf Datenbankdateien zuzugreifen. Und unter diesen Programmen gibt es, zufällig, eigenes Pi-hole.

Die betreffende Datei ist /etc/pihole/pihole-FTL.db, un Datenbank SQLite wo FTL Statistiken speichert, Abfragen und Netzwerkgeräte. Wenn sich diese Datei in einem über mergerfs gemounteten Verzeichnis befindet, SQLite versucht zu verwenden mmap() sul-Datenbank, aber mergerfs antwortet mit einem I/O-Fehler … und das Ergebnis ist ein Pi-Hole, das sich ständig beschwert.

---

Die Lösung

Die Lösung ist eigentlich einfach: Vermeiden Sie es, die Datenbank über Mergerfs auszuführen.

In meinem Fall hatte ich die Pi-hole-Konfigurationsverzeichnisse so gemountet:

volumes:
  - ./etc-pihole:/etc/pihole
  - ./etc-dnsmasq.d:/etc/dnsmasq.d

Diese Ordner befanden sich unter einer Mergerfs-Freigabe (/srv/mergerfs/main_share), und dann schrieb Pi-hole die Datenbank in einen „virtuellen“ Pfad. Der Trick bestand darin, diese Pfade durch i zu ersetzen absolute Pfade der realen Festplatte, Fusionen umgehen.

Hier erfahren Sie, wie:

services:
  pihole:
    image: pihole/pihole:latest
    container_name: pihole
    volumes:
      - /srv/dev-disk-by-uuid-XXXX/etc-pihole:/etc/pihole
      - /srv/dev-disk-by-uuid-XXXX/etc-dnsmasq.d:/etc/dnsmasq.d

(Taube XXXX ist die UUID der physischen Festplatte, auf der Sie die Pi-hole-Dateien speichern möchten.)

---

Praktische Schritte

Zur Sicherheit, Ich habe diese Schritte befolgt:

1. Ich habe den Container gestoppt:

   • docker compose down

2. Ich habe die alte Datenbank verschoben (der Korrupte):

   • mv /srv/dev-disk-by-uuid-XXXX/etc-pihole/pihole-FTL.db* /srv/dev-disk-by-uuid-XXXX/etc-pihole/backup/

3. Ich habe Pi-hole neu gestartet:

   • docker compose up -d

Pi-hole hat automatisch eine neue Datenbank neu erstellt und, von diesem Moment an, Keine „Festplatten-E/A“-Fehler es erschien nicht mehr im Protokoll.

---

Schlussfolgerungen

Grundsätzlich, Pi-Hole und Mergerfs können problemlos nebeneinander existieren – wissen Sie das einfach SQLite-Datenbanken mögen es nicht, auf FUSE-Dateisystemen gehostet zu werden. Wenn Sie ähnliche Fehler auch bei anderen Containern haben (zum Beispiel Home Assistant oder Nextcloud AIO), Versuchen Sie, die Dateien zu verschieben .db auf einer echten Festplatte und Sie werden sehen, wie sie verschwinden.

Der Rest – Konfigurationen, einloggen, Blocklisten – können sicher unter Mergerfs bleiben.

Hinweis: Sie können für automatische Backups weiterhin Pi-Hole-Verzeichnisse in Ihr Mergerfs-Volume einschließen, solange der Container physisch woanders schreibt.