misconfiguration disclosure
Not a CVE. Not a bees bug. Not NFS itself. A FAT32 boot hook that looks like “the AI gateway is down.”
After a NAS reboot the Unraid console printed Permission denied while a startup script ran. Clients could not mount the model pool. A desk-host Docker volume aimed at …:/mnt/ai-data/uv-cache failed with connection refused. The fast-models container was healthy. bees was still walking the pool inside the container.
( sleep 45; /boot/config/plugins/fast-models/host-nfs-export.sh ) &
Unraid /boot is FAT32. The script was -rw-------. After 45 seconds the shell tried to exec it. Permission denied. The persist script never ran: no host mount, empty /etc/exports, no nfsd.
| Stopgap | Why it fails |
|---|---|
rc.nfsd start | Daemon up, export table empty |
| Settings → NFS | Turns on array-share NFS; this stack wants it off |
| Blame the chat-proxy container | That process never reached its config |
| “NFS has been down for weeks” | It was live in early August. It died on this reboot |
( sleep 45; bash /boot/config/plugins/fast-models/host-nfs-export.sh ) & bash /boot/config/plugins/fast-models/host-nfs-export.sh showmount -e <nas-host-ip>
CVE-FAUX-2026-0815 (same day, earlier) was a joke number for an agent stating “the NAS rebooted” without checking uptime. CVE-FAUX-2026-0815-2 is the follow-on: narrating the chat stack instead of reading the console Permission denied. No CVE reservation. No vendor advisory. Published so the next Unraid operator does not spend an evening on the table above.
Markdown twin: docs/INCIDENT_FAT32_GO_HOOK_2026-08-15.md