Problem
After upgrading dashdot (mauricenino/dashdot) from 5.x to 6.x on a ZFS host, GET /load/storage returns [-1,-1,-1,...] — one -1 per physical disk — and the Storage widget shows nothing useful. GET /info still enumerates the disks correctly, so it is an attribution failure, not a detection failure.
Verify it is a regression rather than a config problem by running both versions side by side; the old image is still local right after the pull:
docker run -d --rm --name cmp --privileged -p 30002:3001 -v /:/mnt/host:ro <old-image-id>
curl -s localhost:30002/load/storage # 5.2.3 -> one aggregate byte count, then zeros
curl -s localhost:30001/load/storage # 6.3.4 -> [-1,-1,...]Cause
ZFS pool members have no mounted filesystem of their own, so dashdot cannot map sda..sdj to usage. The pool itself appears in df under a name that is not a device path (qi, rpool/ROOT/ubuntu), which dashdot treats as a virtual filesystem it must be told about.
Fix
Name the pools as virtual mounts, and hide the raw members:
-e DASHDOT_FS_VIRTUAL_MOUNTS=qi,rpool/ROOT/ubuntu \
-e DASHDOT_FS_DEVICE_FILTER=sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdjUse the exact filesystem name from df -PT (the dataset, e.g. rpool/ROOT/ubuntu), not just the pool name — rpool alone yielded no entry while rpool/ROOT/ubuntu did. Result is better than 5.x: every pool reports separately instead of one aggregate number.
Also worth knowing
The only documented breaking change in dashdot 6.0.0 is a units flip in the static speedtest file, which is unrelated and only matters if you supply one.