Version: 7.2.0 (kernel 6.12.54-Unraid)

  Array state: STARTED, 25 disks, no invalid/missing/disabled per mdcmd status                                                      

  emhttpd: not running                                                                                                                

                                                                                                                                      

  Symptoms                                                                                                                            

  --------                                                     

  - WebGUI stale for weeks (disks.ini mtime frozen at 2026-04-01)                                                                     

  - POST /update.htm actions fail: nginx error.log shows                                                                              

    connect() to unix:/var/run/emhttpd.socket failed (111: Connection refused)                                                      

  - Parity-cancel from Main doesn't register                                                                                          

  - Array, shares, dockers still function via shfs; only the GUI / emhttpd is down                                                    

                                                                                                                                      

  What I've verified over SSH                                                                                                         

  ---------------------------                                                                                                         

  1. pidof emhttpd is empty. Manual restarts /etc/rc.d/rc.emhttpd restart)                                                       

     log:                                                                                                                             

         emhttpd: unclean shutdown detected

         emhttpd: shcmd (6): /usr/local/emhttp/webGui/scripts/update_access                                                           

         emhttpd: shcmd (7): modprobe zfs                                                                                             

         emhttpd: Lifetime key detected, GUID: ...                                                                                    

         emhttpd: get_diskFsSizes 8588 diskFsType.0 not found                                                                         

     …and the process exits.                                                                                                          

                                                                                                                                      

  2. /boot/config/disk.cfg has no slot-0 keys at all — no diskId.0,                                                               

     diskSlot.0, diskFsType.0, nothing. Slots 1–23 are fully populated.                                                           

                                                                                                                                      

  3. /var/local/emhttp/disks.ini still has the parity entry correctly                                                               

     (idx=0, name=parity, device=sdk, id=HUH721212ALE601_8HGYTV7Y, status                                                             

     DISK_OK, size 11718885324). So the md driver knows about parity;                                                                 

     only the persisted config has lost slot 0.                                                                                       

                                                                                                                                      

  4. /boot/config/forcesync has been present since 2026-02-28 14:34.                                                                

     Parity history /boot/config/parity-checks.log):                                                                               

         2026 Feb 28  3600s  sbSyncExit=-4 (cancelled)                                                                                

         2026 Mar 21  764317s  15,700,473 errors  sbSyncExit=0                                                                        

     i.e. parity has been unhealthy for months.                                                                                       

                                                                                                                                      

  5. Earlier in this sequence, one of my SSH sessions caught this in syslog:                                                          

         put_config ... rename: /boot/config/ident.cfg.new /boot/config/ident.cfg                                                     

         → No such file or directory                                                                                                  

     It's transient now (/boot is rw, touches succeed), but it matches the                                                            

     pattern of a botched put_config write that could have truncated                                                                  

     disk.cfg too.                                                                                                                    

                                                                                                                                      

  What I've done                                               

  --------------                                                                                                                      

  - Backed up disk.cfg → /boot/config/disk.cfg.backup-20260418-001039

  - No config edits, no mdcmd stop, no reboot.                                                                                      

  - Generated diagnostics (attached).                                                                                                 

                                                                                                                                      

  Questions                                                                                                                           

  ---------                                                                                                                           

  1. What's the correct slot-0 stanza for a parity disk in disk.cfg on 7.2.0?

     I can reconstruct from disks.ini but want the exact expected keys before                                                         

     writing.                                                                                                                         

  2. Does rename: /boot/config/ident.cfg.new ... indicate flash corruption                                                          

     worth addressing before the next reboot?                                                                                         

  3. Safe to clear /boot/config/forcesync before the first good emhttpd                                                             

     start, or leave it so the next boot runs a full parity check?                                                                    

                                                                                                                                      

  Holding off on reboots and mdcmd stop until I have guidance. Happy to run                                                           

  specific commands and report back.         

levyserver-diagnostics-20260418-0010.zip

Note that manually restarting emhttp is not supported, but LT is already aware and looking into it. You can follow the progress here: emhttpd crashes on manual restart — get_diskFsSizes: diskFsType.0 not found | Unraid

Recommend rebooting for now, if the GUI doesn't start, delete/rename /config/disk.cfg on the flash drive and reboot once more, this will not remove the assignments.

Please try updating to 7.2.5-rc.2 and retest, there was some additional telemetry output added to the syslog which may help identify what is causing emhttp to crash.

7.2.5-rc.2 Now Available - Announcements - Unraid

Confirming this bug on 7.2.0 with a second, independent case — and adding two fix attempts that did NOT work, in case they help narrow it down.

Same crash signature, on array Start (cmdStart):

emhttpd[NNNNN]: segfault at 0 ip ... error 4 in libc-2.42.so[182387,...]

"segfault at 0" + "error 4" = a NULL-pointer READ, i.e. emhttpd hands a NULL string to a libc string function while enumerating disk/pool config at Start. It reproduces 100% of the time and dies ~2 seconds after cmdStart with no emhttpd log output. Crucially it faults at the SAME libc offset (182387) every time.

Environment:

- Unraid 7.2.0, kernel 6.12.54, glibc 2.42

- Dual-socket Supermicro, LSI SAS3008 HBA

- Parity is DISABLED on this array (mdNumDisabled=2), so slot 0 has no assigned device

- Data disk is ZFS; a large multi-vdev ZFS pool is also configured as a pool

Like the OP, /boot/config/disk.cfg is missing its slot-0 key set. The ONLY slot-0 keys present are:

diskIdSlot.0="-"

diskSpindownDelay.0="-1"

diskSpinupGroup.0=""

There is no diskId.0, no diskFsType.0, no diskSize.0, no diskName.0 — while slots 1-23 are fully populated (diskFsType.1="zfs", etc.).

What I tried, and what happened:

1) Regenerate disk.cfg (the recommended workaround): backed up disk.cfg, renamed it out, rebooted. Unraid regenerated it — but the regenerated file STILL had no diskFsType.0 (with parity disabled, regen never writes a parity-slot fs key). Array Start still segfaulted.

2) Manually added diskFsType.0="" and diskSize.0="0" to disk.cfg and restarted emhttpd. Array Start STILL segfaulted, at the identical libc offset (182387).

The takeaway from (2): because giving diskFsType.0 a valid value did not change or eliminate the crash, the NULL field being dereferenced is NOT diskFsType.0 — it's some other slot-0 / start-time config value that's missing when parity is disabled. It can't be pinned down from userspace on 7.2.0 (no gdb/strace shipped).

The common trigger across both cases looks like a partially-defined slot 0 (parity slot present in config as diskIdSlot.0="-" but with no diskId/diskFsType/diskSize/diskName keys), which the 7.2.0 Start path dereferences without a NULL check.

Data is 100% safe here — both pools import and mount cleanly with zero errors; only the emhttpd Start path is affected. I'm running services via a manual mount + docker bring-up outside emhttpd in the meantime.

Happy to provide full diagnostics, the exact disk.cfg, or to run a debug emhttpd build / an rc with the added telemetry to identify which slot-0 field is dereferenced with parity disabled. Let me know what would be most useful.

unraid-diagnostics-20260807-1023.zip