RiccoFrosT

Update — root cause found and confirmed fixed! Thanks @JorgeB — you were exactly right. I had recently enabled Unraid's persistent syslog server (Settings → Syslog Server) pointed at /mnt/user/system. Since rsyslogd starts very early in boot — before the array/shfs mounts /mnt/user — it was creating /mnt/user and /mnt/user/system as plain directories before the real FUSE share mount could attach there. That pre-existing plain directory then blocked shfs from ever mounting properly, on every single subsequent boot. Fix: Settings → Syslog Server → set "Local syslog server" to Disabled. Rebooted immediately after — /mnt/user mounted correctly, zero getxattr errors, all 12 shares back, and it's stayed stable since. For anyone else hitting this: if you're using persistent syslog (or any custom script/cron job) and see malloc_share_locations/getxattr errors on /mnt/user, check whether anything is configured to write into /mnt/user/... early in boot — before the array starts, that path doesn't exist yet as a real mount, and anything writing there will create a stray directory that permanently blocks the real share mount until it's manually cleared. If you want to keep persistent logging, point it at a real disk path instead (e.g. /mnt/disk5/system) rather than through /mnt/user. Also found (unrelated, but for completeness): a Docker container of mine had a stray /mnt/user bind-mount that was a plausible contributing factor for the original failure, though removing it alone didn't fix things — the rsyslog issue above was the real, complete cause. Thanks for the quick, correct diagnosis — much appreciated after a long day of chasing this down!

**Unraid version:** 7.3.2 (checksums verified against official release, so not a corrupted flash drive) **Symptom:** After every boot, /mnt/user never gets mounted by the FUSE share layer. It stays as a bare empty directory (not a mountpoint at all — confirmed with mountpoint /mnt/user → "not a mountpoint"). All array disks /mnt/disk1/mnt/disk5) mount fine individually with all data intact and accessible. /mnt/user0 doesn't even get created. Syslog is flooded continuously, every ~1 second, indefinitely (not just at boot) with: ``` emhttpd: error: malloc_share_locations, 8948: Operation not supported (95): getxattr: /mnt/user/<share> ``` This happens for every share, repeating forever — I let it run 5+ minutes post-boot with no change or self-recovery. **What I've ruled out (troubleshooting steps taken):** - **Reproduced on 3 separate clean reboots/array restarts** — not a one-off glitch. - **All 5 array disks individually tested for xattr support** setfattrgetfattr) — all pass fine, all XFS with attr=2. - **No cache pool assigned at all** (no /mnt/cache*, no pool devices) — ruling out cache-pool-related causes seen in similar threads. - **No stray SSH/tmux/screen sessions** — checked who, ps aux, lsof +D /mnt/user, fuser -vm /mnt/user — only process with an open handle was rsyslogd writing its own log file, which is normal. - **No cron jobs or User Scripts run early enough to cause it** — first getxattr error appears ~5 seconds after emhttpd starts, before Docker rc.docker) even starts (confirmed via syslog timestamps — Docker started ~19s after the first error). Root crontab has no jobs touching /mnt/user. - **Unassigned Devices plugin (2 disks: NVMe + SSD) mounts ~19s after emhttpd starts** — a timing gap exists but errors continue well past when UD finishes, so it's not just a startup race — emhttpd never recovers even once everything else is ready. - **A Docker container (Cronicle job scheduler) had a stray /mnt/user bind mount (likely a contributing factor, not sole cause): Cronicle had /mnt/user and /mnt/user/Movies bind-mounted with rw,slave propagation, added ~a week before the incident while migrating some cron jobs. Docker's slave propagation can "lock in" whatever is at a mountpoint when a container starts — if this container started while /mnt/user was still an unmounted bare directory (likely, given the ongoing failure), it could block the real FUSE share mount from ever attaching there while the container/mount reference exists. Removed this mount entirely and recreated the container (confirmed via docker inspect that it was gone), then rebooted to test — identical failure recurred, same timing, same error count. So this alone doesn't explain the full persistence (also logically doesn't explain the very first error, since Docker starts ~19s after emhttpd's first getxattr failure), but it's a plausible contributing mechanism worth flagging, especially for compounding the original incident. - **Boot flash files verified against sha256** — bzroot, bzimage, bzmodules, bzfirmware all match the official 7.3.2 release checksums. - **No shfs binary exists anywhere on the system** find / -iname 'shfs*' returns nothing) — I understand newer Unraid versions build this into emhttpd directly rather than a separate binary, so wasn't sure if this is expected or a symptom. **Likely trigger identified:** Checked persistent syslog history and found emhttpd: unclean shutdown detected on the first affected boot. The evening before this started, I was troubleshooting a separate NUT/UPS plugin issue and did several reboots plus physically unplugged the UPS — so the actual trigger was almost certainly an unclean shutdown during that process, not anything share-related directly. **New Config tried:** Ran Tools → New Config with "Preserve current assignments: All" (array/disk assignments came back correctly, parity stayed valid, no data loss). This temporarily fixed it — /mnt/user mounted correctly and 6 of 12 shares appeared immediately after. However, **the exact same failure returned on the very next normal reboot** — so New Config only resets the symptom, not the underlying cause. **Plugins ruled out:** Initially suspected a corrupted plugin (mirroring a resolved thread, ["Unclean shutdown, dockers and shares missing from GUI"](https://forums.unraid.net/topic/98042-solved-unclean-shutdown-dockers-and-shares-missing-from-gui/), where Safe Mode fixed shares/Docker completely). Tested directly: booted Safe Mode (all plugins disabled), did a plain array Start (no New Config this time). Result: **still only 1 of 12 shares system) appeared** — same failure, plugins fully disabled. This cleanly rules out any plugin as the cause. **Installed plugins:** appdata.backup, appdata.cleanup.plus, ca.update.applications, community.applications, customtab, disklocation-master, dlandon.cache.dirs, dynamix.system.buttons, dynamix.unraid.net, fix.common.problems, intel-gpu-top, nut-dw (NUT/UPS), unassigned.devices(+preclear), unbalanced, user.scripts. Consistent partial share list (possibly significant): In normal mode, the Shares UI and getxattr error loop consistently show only 6 of 12 shares: Local Media, Movies, Music, Photos, Tv Shows, system. The other 6 (Backups, Comics, Documents, Personal, ROMS, Software, Trailers, Unsorted Photos-Videos) never appear at all, on any boot — including the very first failure. In Safe Mode specifically, this narrowed further to just system alone. None of the 6 "visible" shares are actually working — /mnt/user never becomes a real mountpoint for any of them — they're just the only ones emhttpd lists/attempts. I checked for a pattern explaining the split: share config content/format is identical between the two groups, modification timestamps don't correlate, and disk placement doesn't correlate (all shares have folders spread across multiple disks, no clean split). **Question:** Is this a known regression in 7.3.2 following an unclean shutdown? I've ruled out plugins, cache pool, disk xattr support, stray sessions/cron, Docker mounts, and UD timing through direct testing (details above), and even a full New Config reset only fixes it for one boot. Diagnostics zip attached — happy to provide anything else useful. Diagnostics attached (2 files): unraid-diagnostics-20260806-1919-ORIGINAL.zip — captured ~9 minutes after the very first failed boot (the original unclean-shutdown incident), showing the problem in its original state before any troubleshooting. The second zip — captured just now, showing current state after multiple reboots, a Cronicle mount fix, and a New Config reset. unraid-diagnostics-20260807-1901.zip unraid-diagnostics-20260806-1919-ORIGINAL.zip

I actually have no idea what this file is used for, there is content in the file. Removing it did not seem to have a effect on the system (not that I encountered any way)

Hi All, I have just started getting the following error when running Fix Common Problems - /boot/config/ultra.cfg corrupted A number of things I have tried to resolve the issue - * Renamed ultra.cfg to old.ultra.cfg then copied ultra.cfg from a USB Backup from a number of months ago, rebooted and error still appears (now is listed twice, one for ultra.cfg and another for old.ultra.cfg) * Deleted ultra.cfg and rebooted hoping that Unraid would rebuild the file (it did not) so copied back saved copy of file. As far as I can tell it does not seem to be affecting the usage of the server, no other errors other then in Fix Common Problems. I can still open ultra.cfg via the UNRAID file manager and see the contents of the file. Any ideas? should I be looking at replacing the USB with another? unraid-diagnostics-20250119-1448.zip