Temps de lecture estimé: 2 minutes

Il y a quelques jours, j'ai rencontré un curieux problème: Pi-hole in esecuzione su Docker, all’interno del mio NAS basato su OpenMediaVault, continuava a generare errori inspiegabili nel log di pihole-FTL. Apparemment, tout a fonctionné, mais des lignes comme celles-ci sont apparues dans le journal:

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 !

ou encore:

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

Dopo un po’ di ricerche e test ho capito che il problema non era Pi-hole, né Docker, mais mergerfs, il filesystem che uso per unire più dischi in un’unica condivisione.

---

Le problème

Per chi non lo conoscesse, mergerfs est un union filesystem basato su FUSE, molto comodo per creare un grande volume “virtuale” partendo da più dischi fisici. Lo uso da anni su OpenMediaVault per aggregare i miei dischi dati e di backup.

Cependant, c’è un piccolo dettaglio: FUSE non gestisce bene le operazioni di memoria condivisa (mmap) che alcuni programmi usano per accedere velocemente ai file di database. E tra questi programmi c’è, coïncidence, proprio Pi-hole.

Il file incriminato è /etc/pihole/pihole-FTL.db, base de données de l'ONU SQLite in cui FTL salva statistiche, query e dispositivi di rete. Quando questo file si trova in una directory montata tramite mergerfs, SQLite tenta di usare mmap() sul database, ma mergerfs risponde con un errore I/O… e il risultato è un Pi-hole che continua a lamentarsi.

---

La solution

La soluzione in realtà è semplice: evitare di far passare il database attraverso mergerfs.

Nel mio caso avevo montato le directory di configurazione di Pi-hole così:

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

Queste cartelle si trovavano sotto una condivisione mergerfs (/srv/mergerfs/main_share), e quindi Pi-hole scriveva il database in un percorso “virtuale”. Il trucco è stato sostituire quei percorsi con i path assoluti del disco reale, bypassando mergerfs.

Ecco come:

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

(Colombe XXXX è l’UUID del disco fisico su cui vuoi salvare i file di Pi-hole.)

---

Passaggi pratici

Per sicurezza, ho eseguito questi passaggi:

1. Ho fermato il container:

   • docker compose down

2. Ho spostato il vecchio database (quello corrotto):

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

3. Ho riavviato Pi-hole:

   • docker compose up -d

Pi-hole ha ricreato automaticamente un nuovo database e, da quel momento, nessun errore “disk I/O” è più comparso nel log.

---

Conclusions

In sostanza, Pi-hole e mergerfs possono convivere senza problemi — basta sapere che i database SQLite non amano essere ospitati su filesystem FUSE. Se hai errori simili anche con altri container (per esempio Home Assistant o Nextcloud AIO), prova a spostare i file .db su un disco reale e vedrai che spariscono.

Il resto — configurazioni, Connectez-vous, liste di blocco — può tranquillamente rimanere sotto mergerfs.

Remarque: puoi comunque includere le directory di Pi-hole nel tuo volume mergerfs per i backup automatici, purché il container scriva fisicamente altrove.