**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

Edited August 7Aug 7 by RiccoFrosT

On my system shfs exists under /usr/libexec/unraid.

It might be worth running a check filesystem on all your drives to make sure you do not have a corrupt file system causing problems.

Aug 6 19:13:44 UNRAID emhttpd: error: malloc_share_locations, 8948: Operation not supported (95): getxattr: /mnt/user/system

There's something creating /mnt/user/system before the array is started, this is not supported, and it's what is causing the problem, fix the script or whatever is creating that, and it should resolve the issue.

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!

8 hours ago, RiccoFrosT said:

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.

Had you set a custom path? Because at least if you select a share from the dropdown it works fine, had it running like that for years.

Edited August 8Aug 8 by Kilrah