When i start the container it is immediately stopped with Exit code 139. The container that comes with the "officially" QNAP Pi-hole "app" (composed docker container) with image version pihole/pihole:2022.12.1 is working.
We don't have a QNAP app but that docker tag is years old.
Any information you can supply will be helpful, logs, screenshots, pretty much anything...
NAS Hardware information:
CPU: Annapurna Labs Alpine AL-314, quad-core 1.7 GHz processor
RAM: 2GB DDR3L RAM
The first container which is the latest version isn't working, exiting directly after starting the container. Exit code 139, the log is completely empty.
The second container with the old Pi-hole version that comes bundled with the composed docker application is working fine.
I've read something about segmentation faults while searching for docker error 139, maybe that is the reason that the container is not working? At the bottom of the container station it shows a warning:
The current system page size is 32K. Ensure that third-party applications are compatible with the current page size before installing the application.
From the QNAP FAQ:
Why do the installed third-party containers not run successfully on specific 32-bit ARM devices?
Last modified date: 2024-09-02
QNAP updated the system page size from 4K to 32K for better performance and user experience on the following 32-bit ARM devices. This change in the compute environment could limit the container’s access to memory. To avoid container segmentation faults, verify third-party container page size compatibility before installation.
The 32K page size quoted above is indeed the root cause — and here is a working fix, since this thread is where search engines send people who hit exit code 139 on QNAP.
QNAP builds the kernel on these models (TS-231P3 / TS-431P3 and other Annapurna AL314-based 32-bit ARM NAS) with a 32 KB memory page size instead of the standard 4 KB. Pi-hole v6's official image is Alpine-based, and Alpine >= 3.18 links its userland for 4 K pages — so /bin/sh inside the container segfaults before FTL even starts. That's why the container dies with exit code 139 and a completely empty log.
The interesting part: the official static pihole-FTL binary runs fine on these devices — only the Alpine userland around it crashes. So the fix is repackaging the unmodified official FTL binary, web UI and scripts on an ubuntu:22.04 userland (linked for 64 K pages, works on 32 K kernels).
I published ready-made arm/v7 images (rebuilt weekly against upstream latest), the Dockerfiles, a Container Station compose example, and a v5 -> v6 migration guide, verified on a TS-431P3: GitHub - laroy-sh/qnap-32k-containers: Fixed Docker images (Pi-hole v6, Syncthing) for QNAP 32-bit ARM NAS that crash containers with exit 139 — TS-431P3/TS-231P3 and other 32K-page-kernel models · GitHub
For anyone debugging other containers on these NAS models — base images that work: Ubuntu 22.04, Debian bullseye, Alpine <= 3.17, static Go binaries. Broken: Alpine >= 3.18, Debian bookworm, Ubuntu 24.04, and anything arm64 (these CPUs are 32-bit only).