Proxmox disks showing as 0% usage

[nsleigh]

Describe the bug
On both of my Proxmox connections the disk usage is 0%, in both cases I have added the 2 pools rpool and zfs-pool:

Expected behavior
The correct disk usage is collected!

I think this might explain the issue - 'df' doesn't show the actual disk usage but the proxmox command 'pvesm status' does.

root@pve:~# df
Filesystem                               1K-blocks       Used  Available Use% Mounted on
udev                                      30230428          0   30230428   0% /dev
tmpfs                                      6575804       4880    6570924   1% /run
efivarfs                                       256         57        195  23% /sys/firmware/efi/efivars
rpool/ROOT/pve-1                         828235520    9596160  818639360   2% /
tmpfs                                     32879012      34320   32844692   1% /dev/shm
tmpfs                                         5120          0       5120   0% /run/lock
tmpfs                                     32879012          0   32879012   0% /tmp
tmpfs                                         1024          0       1024   0% /run/credentials/systemd-journald.service
rpool                                    818639488        128  818639360   1% /rpool
rpool/var-lib-vz                         818760448     121088  818639360   1% /var/lib/vz
zfs-pool                                5302507136        128 5302507008   1% /zfs-pool
rpool/ROOT                               818639488        128  818639360   1% /rpool/ROOT
rpool/data                               818639488        128  818639360   1% /rpool/data
/dev/fuse                                   131072         36     131036   1% /etc/pve
tmpfs                                         1024          0       1024   0% /run/credentials/getty@tty1.service
tmpfs                                      6575800          4    6575796   1% /run/user/0
root@pve:~#
root@pve:~# pvesm status
Name              Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
local              dir     active       818760448          121088       818639360    0.01%
local-zfs      zfspool     active       949358820       130719428       818639392   13.77%
nfs-backup         nfs     active      8742400000      5983340544      2757483520   68.44%
pbs-local          pbs     active      1032201728       481278464       550923264   46.63%
pbs-nas            pbs     active      1036085120       937045760        99039360   90.44%
zfs-pool       zfspool     active      7667187712      2364680580      5302507132   30.84%

Environment

• Home Assistant version: 2026.5.4
• SMART Sniffer integration version: 0.5.13
• Agent version: (check with curl http://<host>:9099/api/health) 0.5.13
• Agent OS: (e.g., Proxmox, Ubuntu, macOS, Windows) Proxmox
• Drive type: (ATA/SATA SSD, ATA/SATA HDD, NVMe, USB) NVMe and HDD

Logs
Relevant logs from Home Assistant (Settings → System → Logs, filter for smart_sniffer) and/or the agent (journalctl -u smartha-agent).

root@pve:~# journalctl -u smartha-agent
May 28 10:51:53 pve systemd[1]: Started smartha-agent.service - SMART Sniffer Agent — disk health REST API.
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 using smartctl: /usr/sbin/smartctl (version 7.5)
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 SMART Sniffer Agent v0.5.13
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 smartctl version: 7.5
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 Drives detected: 4
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 Listening on: 0.0.0.0:9099
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 Auth: disabled
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 mDNS: enabled (interface: vmbr0)
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 Standby mode: standby
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 first poll: using --scan-open for protocol detection, waking drives for S>
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 cache refreshed: 4 drive(s)
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 Filesystem monitoring: 2 mount(s)
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 mDNS: interfaces: interface vmbr0
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 mDNS: preferred IP: 192.168.20.10
May 28 10:51:53 pve smartha-agent[274986]: 2026/05/28 10:51:53 mDNS: advertising smartha-pve._smartha._tcp.local. on port 9099
May 28 11:21:54 pve smartha-agent[274986]: 2026/05/28 11:21:54 cache refreshed: 4 drive(s)
May 28 11:51:54 pve smartha-agent[274986]: 2026/05/28 11:51:54 cache refreshed: 4 drive(s)
May 28 12:21:54 pve smartha-agent[274986]: 2026/05/28 12:21:54 cache refreshed: 4 drive(s)

Let me know if you need anymore information - or if I have just configured it incorrecly!

P.S. This integration is just what I was looking for, thanks.

[DAB-LABS]

Welcome to the operation, Agent @nsleigh. Great bug report -- and you nailed the root cause. 🕵️‍♂️

You're right that df and the underlying statfs syscall report dataset-level usage on ZFS, not pool-level. Our agent uses statfs to collect disk usage, which works correctly for ext4/xfs/NTFS but returns misleading numbers for ZFS -- the parent dataset (rpool, zfs-pool) shows near-zero usage because all the actual data lives in child datasets and zvols.

We already have a fallback for btrfs (which has a similar problem), and we're building one for ZFS that will use zpool list under the hood to get the real pool-level numbers. This is on our roadmap for an upcoming release.

Unfortunately there's no workaround on your end in the meantime -- the 0% readings will persist until we ship the ZFS fix. We'll update this issue when it lands.

Side note, one of your Seagate ST8000NM drives is showing reallocated sectors (the "1 critical" flag on the card). That's working as intended, the agent caught it. Keep an eye on that one. 🍻

Thanks for the kind words, and welcome aboard! 🫡

~DAB

---

📋 Field Brief: ZFS Pool Usage Misreported as 0%

Subject: Agent reports 0% disk usage for ZFS pools because statfs returns dataset-level values, not pool-level
Classification: Bug (platform limitation)

Situation: User configured filesystem monitoring for /rpool and /zfs-pool on Proxmox VE. Both show 0% usage in HA. The pools are actually 13.77% and 30.84% full respectively. The user identified that df (which uses statfs) shows near-zero usage for parent ZFS datasets, while pvesm status (which queries ZFS directly) shows correct numbers.

Root Cause: syscall.Statfs() on a ZFS dataset mountpoint returns values scoped to that dataset, not the pool. Parent datasets hold almost no direct data; child datasets and zvols hold the actual data but are not aggregated by statfs on the parent path.

What statfs reports	What user expects
Dataset direct usage (~128 KB)	Pool total usage (130 GB / 2.36 TB)
Dataset logical total (~818 GB)	Pool total capacity (~949 GB / 7.67 TB)
0% used	13.77% / 30.84% used

Resolution: Build a ZFS-specific fallback in the agent, similar to the existing btrfs fallback (filesystem_btrfs.go). When fstype == "zfs", shell out to zpool list -Hp <poolname> to get pool-level size/allocated/free. Extract pool name from the dataset path.

Approach	CLI tool	Output format	Available on ZFS systems
Pool-level stats	zpool list -Hp	Tab-delimited bytes	Always (part of ZFS utils)
Dataset-level stats	zfs list -Hp	Tab-delimited bytes	Always

Affected platforms:

Platform	ZFS usage	Impact
Proxmox VE	Default filesystem	High -- large user base, ZFS is the default
TrueNAS SCALE	Only filesystem	High -- every TrueNAS user
TrueNAS CORE	Only filesystem (FreeBSD)	Medium -- FreeBSD, different statfs behavior TBD
Ubuntu Server	Optional	Medium -- growing ZFS adoption

Roadmap:

Feature	Status
btrfs fallback (statfs returns 0)	Shipped (v0.5.3)
ZFS pool-level fallback	Planned
Advanced filesystem fallback framework	Research in progress

[nsleigh]

Thanks, I saw the code for btrfs and thought would probably need something for zfs.

That drive issue is what prompted me to go looking for a monitor. It has actually been like it for a couple of years and not changed. I think I will setup an alert to see if it ever gets worse. Maybe a feature request to reset alerts in this monitor.

[nsleigh]

@DAB-LABS would you be interested in a PR to fix this? It is entirely Claude AI as I no very little about 'go' (although I have been programming for 40 years so I hope I know a bit). I have it working on my system and it looks ok. There was also one additional gotcha - the UUID for ZFS is not populated by the install.sh. The PR fixes this but it does mean that an existing HA entity will be duplicated and would need to be deleted.

[DAB-LABS]

@nsleigh -- thanks for the offer, and seriously impressive that you got a working ZFS fallback up and running. The fact that you hit the UUID/entity ID issue tells me you've been deep in the code, which is appreciated.

That entity ID problem is exactly why we want to handle this carefully on our end. Changing how filesystem IDs are generated would break existing HA entities for anyone already monitoring ZFS paths (even if they show 0%), and we'd rather not ship something that creates orphaned entities users have to clean up manually.

Bit of backstory, SMART Sniffer was built for SMART drive health monitoring. Filesystem usage was added as a lightweight side sensor ("while we're here, we might as well report disk space too"). It's turned out to be way more popular than we expected, which is great, but it also means we've been playing catch-up on edge cases where statfs doesn't tell the full story. We already have a btrfs fallback for multi-device configurations where statfs returns zeros, and ZFS is the next one on the list.

Rather than patching filesystems one at a time, we're planning a holistic pass across all the advanced filesystems where statfs misreports ~ ZFS first (highest priority given the Proxmox install base), then others like LVM thin provisioning. We want one well-tested framework rather than individual fixes that each introduce their own edge cases.

We'll update this issue when the ZFS fix lands. Your working implementation is useful reference for our approach, knowing what you ran into (especially the UUID gap in install.sh) saves us discovery time.

🫡

~DAB

[nsleigh]

@DAB-LABS I'll push a PR so you can see what I did as it might be useful.

The UUID being currently empty meant for multiple drives the drive property was indeterminate (but I suspect would be the same each time). I guess once the duplicate came in it could be matched by name. I also found it meant the install had to change and re-run so the UUID was picked up and put in the config. Personally, that was enough impact to mean I didn't mind the duplicates but others may not think so. The ZFS UUIDs are not actually UUIDs just 64bit numbers, I don't think that mattered as the key was just the first 8 characters.

The other thing I had to address was that the btrfs logic was if info.TotalBytes == 0 && cfg.FSType == "btrfs" { } but for zfs the bytes aren't zero so I just do if cfg.FSType == "zfs" { }. Hopefully Claude has commented this correctly :-)