如果你擁有一台 32 位元 ARM 架構的 QNAP（如 TS-431P3、TS-231P3、TS-x31X、TS-431KX、TS-1635 等）並且發現大多數 Docker 映像在 Container Station 內啟動後立刻崩潰——返回 exit code 139，而且日誌完全為空——這裡有完整說明與實際可行的解法。
為什麼會這樣（有兩個主要原因）：
- 這些處理器（Annapurna AL314、Cortex-A15）屬於 32 位元 ARMv7。只有符合
linux/arm/v7架構的映像可以執行，對於 arm64 或 amd64 的映像則完全無法運行。 - QNAP 在這些機型的核心（kernel）上預設啟用 32 KB 記憶體分頁大小，而非標準的 4 KB（官方知識庫也有記載：「How to debug and fix common container issues in Container Station」）。任何依 4 KB 對齊的執行檔，載入時都會直接崩潰（segfault）。這造成 Alpine ≥ 3.18、Debian bookworm、Ubuntu 24.04 等新版本用戶空間（userland）無法使用——也就是多數現代映像，例如 Pi-hole v6、Home Assistant、Nextcloud 都受影響。目前 QTS 5.2.x 仍然出貨這顆核心（4.2.8 版）。
經測試可用的基底映像： Ubuntu 22.04、Debian bullseye、Alpine ≤ 3.17、靜態編譯的 Go 執行檔。
**解決方式：**大部分應用的主程式都已經是靜態編譯、可支援不同分頁大小——只有 Alpine userland 會崩潰。只要把官方原始映像的 binaries 打包到 ubuntu:22.04 上即可正常執行。我已經幫 Pi-hole v6 和 Syncthing 製作好現成的 arm/v7 映像（每週自動根據上游重建）、提供 Dockerfile 範例、Container Station 的 compose 範例、v5 升級 v6 的 Pi-hole 移轉教學，還有一步一步的 DIY 修復說明：
所有說明都已在 TS-431P3，QTS 5.2.9 實測通過。MIT 授權。（若是 Home Assistant 則可參考 albertogeniola/homeassistant-qnap-32k，原理相同。）