Tempo di lettura stimato: 2 minuti

Qualche giorno fa mi sono scontrato con un problema curioso: Pi-hole in esecuzione su Docker, all’interno del mio NAS basato su OpenMediaVault, continuava a generare errori inspiegabili nel log di pihole-FTL. Tutto funzionava apparentemente, ma nel log comparivano righe come queste:

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 !

oppure ancora:

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, ma mergerfs, il filesystem che uso per unire più dischi in un’unica condivisione.

---

Il problema

Per chi non lo conoscesse, mergerfs è 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.

Tuttavia, 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’è, guarda caso, proprio Pi-hole.

Il file incriminato è /etc/pihole/pihole-FTL.db, un database 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 soluzione

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

(Dove 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.

---

Conclusioni

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, log, liste di blocco — può tranquillamente rimanere sotto mergerfs.

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