Description
TrueNAS SCALE version: 25.10.4
Summary:
After a hardware fault (loose molex power connector causing multiple drives to drop mid-scrub), my pool “swim” went SUSPENDED. After resolving the power issue, clearing errors, and reimporting the pool, every dataset now mounts under /mnt/mnt/swim instead of /mnt/swim. This happened across multiple detach/reimport cycles through the UI, not just one bad import.
Evidence:
-
midclt call pool.query reports the pool’s path as /mnt/swim:
“path”: “/mnt/swim”, “status”: “ONLINE”, “healthy”: true -
The actual live mount table shows every dataset doubled under /mnt/mnt/swim:
swim /mnt/mnt/swim zfs rw,noatime,xattr,posixacl,casesensitive 0 0
swim/apps /mnt/mnt/swim/apps zfs rw,noatime,xattr,posixacl,casesensitive 0 0
[… same pattern across all 30+ datasets, including apps, media, homes, backups, ix-apps] -
ZFS mountpoint properties are clean, set to legacy at the pool root with everything else correctly inheriting:
swim mountpoint legacy local
swim/apps mountpoint legacy inherited from swim
[all child datasets inherited, no local overrides] -
The storage_volume table in freenas-v1.db has no path column at all, only id, vol_name, vol_guid:
CREATE TABLE storage_volume (id INTEGER PRIMARY KEY, vol_name VARCHAR(120), vol_guid VARCHAR(50))
Row: 11 | swim | 2487823359732032901
This means the mount path is built dynamically at mount time, not read from a stored config value. Since pool.query already reports the correct /mnt/swim path, something in the mount logic appears to be prepending /mnt/ a second time onto an already-complete path.
Steps taken, none resolved it:
- zpool clear / zpool scrub, completed clean, 0 errors
- zfs set mountpoint=/mnt/swim swim, caused doubling
- zfs inherit mountpoint swim, failed with read-only filesystem error at root
- zfs set mountpoint=legacy swim, no change to the doubling
- zpool export via CLI, reimport via CLI, no change
- Detached pool through Storage UI (no destroy), reimported through Storage UI Import Pool, no change
- swim/ix-apps also affected, apps subsystem reports /mnt/.ix-apps does not exist
Current workaround:
Symlinked /mnt/swim to /mnt/mnt/swim so shares and apps can find data. This is a stopgap, not a fix, and does not address the apps subsystem’s separate mount expectations under /mnt/.ix-apps.
Would appreciate guidance on where in middlewared the mount path gets constructed, or confirmation this is a known bug. Happy to provide further logs or run diagnostic commands on request.