GuiltlessGibbon

I just had a bad time migrating from 7.2.6 to 7.3.0. System: 4 data disks + 2 parity, all SSD, XFS filesystem. No cache pools. Docker and VMs disabled. Upgrade path: 7.2.6 → 7.3.0 stable Symptoms: After upgrading, /mnt/user/ only showed 3 directories (leftover Docker mount points). shfs process was not running at all. Data was confirmed present on individual disks (/mnt/disk1/ through /mnt/disk4/) but the FUSE aggregation layer never initialized. Attempting to stop the array hung indefinitely — emhttp showed fsState="Stopping" with message "Retry unmounting user share(s)" despite no mounts under /mnt/user/. After a clean reboot back into 7.3.0, the problem reproduced identically. Array start in maintenance mode worked, but stopping maintenance mode hung the same way. mdcmd stop returned "Device or resource busy." Downgrading to 7.2.6 resolved the issue — shfs started normally and all shares re-appeared. However, a stale /mnt/user/personal/ phantom directory (0 bytes, empty subdirs) persisted from the 7.3.0 session and had to be manually removed before emhttp would fully re-scan shares. Key syslog entry from 7.2.6 after downgrade (the same pattern likely occurred silently under 7.3.0): emhttpd: error: malloc_share_locations, 8656: Operation not supported (95): getxattr: /mnt/user/personalThis repeated in a tight loop, suggesting a race or failure in the getxattr call against the FUSE mount. Relevant release note: The 7.3.0 release mentions an "md/unraid driver crash that could make encrypted XFS array disks report a missing or wrong encryption key when affected systems used 4Kn parity." While these disks are not encrypted and not 4Kn, the failure mode (shfs never starting, array unable to cleanly stop) appears related.