TL;DR: After upgrading 7.2.4 → 7.2.5 and rebooting (first reboot in ~3 weeks), emhttpd is silently skipping the shfs invocation during array start. /mnt/user is left as a rootfs stub with only the four hard-coded system stub directories (appdata, domains, isos, system). Failure persists across downgrade, Safe Mode, and stock-minimum boot. Underlying disk data is fully intact — every byte of every share is accessible via /mnt/disk1–/mnt/disk21 and /mnt/cache. This is purely a missing user-share namespace, not lost data. Below troubleshooting was done with the help of AI and from my knowledge of anything that was changed recently.

Bug report is filed (link below), but I'm posting here separately because someone in the community may have hit this and have a fix. Server has been down for nearly a day, including Nextcloud sync (active dev work) and a Home Assistant VM (home automation).

The forensic smoking gun

In a normal boot, emhttpd invokes shfs via an shcmd entry around shcmd 220–221, which mounts /mnt/user as fuse.shfs. Then services start.

What I'm seeing instead, on every boot:

shcmd (219): /usr/local/sbin/update_cron       ← last pre-shfs cmd
                                                 ← 13 seconds of silence, no log entries
emhttpd: Starting services...                   ← services start anyway
shcmd (221): chmod 0777 '/mnt/user/appdata'     ← chmodding rootfs stub

The shcmd numbering shifts boot-to-boot based on optional steps, but the missing entry is always the shfs invocation. No error message. No failure message. No log entry of any kind during those 13 silent seconds. emhttpd proceeds to "Starting services" as if user shares were enabled, then runs chmod against the rootfs stub.

Because shfs isn't running, when Docker/libvirt autostart they create fake docker.img (500GB sparse) and libvirt.img (1GB) in RAM at /mnt/user/system/... instead of pointing at the real images on cache. The real images on /mnt/cache/system/ are untouched and intact.

Hardware / config

• Unraid 7.2.4 (originally 7.2.5, downgraded — failure mode identical)

• 21-disk XFS array, 2 parity, ~156TB

• Single 2TB Samsung 860 PRO XFS cache pool (no ZFS pools on this server)

• 21 legitimate shares: 4 system (appdata, domains, isos, system), 15 user-defined (Books, Movies, TV Shows, Music, etc.), 2 anomalous (8hszb7dd_rlib.cfg, lost+found.cfg)

• Plugins: ca.mover.tuning, dynamix.cache.dirs, unassigned.devices-plus, ca.backup, user.scripts, dockerMan, parity.check.tuning, fix.common.problems, recycle.bin, prometheus_node_exporter, tailscale, unbalanced, folderview.plus, dynamix.cron, nvidia-driver

Things I've eliminated

#	Hypothesis	Test	Result
1	7.2.5 regression	Tools → Downgrade OS to 7.2.4	Same failure on 7.2.4, but it started with the upgrade reboot
2	FUSE not loaded	dmesg | grep fuse	init (API version 7.41) — loaded fine
3	Plugin interference	Boot in Safe Mode (all plugins disabled)	Same failure
4	User Scripts race	Disabled frequency=start script	Same failure
5	Loose files at /mnt/cache root	Quarantined 30 .md/.txt/.tsv files	Same failure
6	shareUser="e" config corruption	Compared to working backup; toggled in GUI	"e" is correct/expected for "yes" in this version
7	Cache xattr support broken	setfattr test on /mnt/cache	xattr works fine
8	75 orphaned "Books deleted" ghost share configs	Quarantined ghosts + 2 anomalous, leaving only 19 legitimate configs	Same failure (ghosts were also in the working Apr 27 backup)
9	Flash config drift since last working state	Diffed full /boot/config/ against Apr 27 backup zip	Configs byte-identical for share.cfg, disk.cfg, pools/cache.cfg
10	Hardware fault	SMART check, mount tests	All disks healthy
11	Stale tmpfs / parity-check race (per [other forum thread])	Stopped Docker/libvirt, wiped /mnt/user to canonical empty nobody:users 0777, rebooted with no parity check running	Same failure, identical 13-second silent gap
12	Custom /boot/config/go file (had ffmpeg symlinks under /mnt/user/appdata/)	Replaced with absolute stock minimum (just /usr/local/sbin/emhttp), verified no rc.local, no plugin boot scripts anywhere	Same failure

What's intact (helpful for triage)

• Cache pool mounted, XFS healthy, all data present

• All 21 array disks mounted, XFS healthy, all data present

• Real docker.img and libvirt.img on cache untouched

• All Nextcloud and other appdata at /mnt/cache/appdata/ intact

• /boot/config/ configuration intact

My ask

If anyone has hit this exact symptom — emhttpd deterministically and silently skipping shfs invocation, with /mnt/user reduced to four stubs — I'd love to know:

1. What was the eventual fix?

2. Was there a specific file, setting, or state on the flash that triggered it?

3. Is there a known-safe strace procedure on emhttpd during boot anyone can share?

Bug report with full diagnostics: bug report - diagnostics on 7.2.5 and after rollback to 7.2.4 attached below as well.

Happy to run any diagnostic the community suggests. Server is in a stable broken state — array up, all data accessible via disk shares, no risk of further damage.

Thanks for reading this far.

tower-diagnostics-20260501-1700.zip tower-diagnostics-Broken-725-Downgrade-20260501_0619.zip

Edited May 2May 2 by abhi.ko

RESOLVED. Root cause was a self-heal cron entry I'd added to /boot/config/plugins/dynamix/nextcloud.cron four days earlier — its OR-fallback (docker exec ... || mkdir -p /mnt/user/appdata/...) ran during boot when Docker wasn't up yet, polluting rootfs before shfs could mount. emhttpd then silently skipped shfs invocation as a safety measure. Removed the dangerous cron entry and shfs mounted cleanly on the next reboot. Lesson: any cron touching /mnt/user/ paths must guard against the boot-time race since crond starts before Docker. Had to dig through every change I made in the last 2-3 weeks one-by-one and try re-voting after removing each of them. Finally figured it out.