Приблизительное время чтения: 2 минут

Несколько дней назад столкнулся с любопытной проблемой: Пи-дыра in esecuzione su Docker, all’interno del mio NAS basato su OpenMediaVault, continuava a generare errori inspiegabili nel log di pihole-FTL. Все видимо заработало, 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, мама mergerfs, il filesystem che uso per unire più dischi in un’unica condivisione.

---

проблема

Per chi non lo conoscesse, mergerfs является 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.

Однако, 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’è, совпадению, proprio Pi-hole.

Il file incriminato è /etc/pihole/pihole-FTL.db, база данных ООН 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 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

(голубка 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.

---

Выводы

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, журнал, liste di blocco — può tranquillamente rimanere sotto mergerfs.

примечание: puoi comunque includere le directory di Pi-hole nel tuo volume mergerfs per i backup automatici, purché il container scriva fisicamente altrove.