Time Machine "max size" ignored on btrfs shares (dfree command overrides vfs_fruit)

I ran into something with Time Machine shares on btrfs that looks like a bug, and I'd like a second opinion before opening a GitHub issue.

My Mac's backups started failing with "disk is full", and while digging into it I noticed that the Time Machine max size I'd set on the SMB share wasn't doing anything. I had it set to 1T, but the Mac was seeing the free space of the whole btrfs filesystem (about 1.45 TB free). So Time Machine had no reason to hold itself back.

It turns out OMV adds a dfree command to every btrfs-backed share. Here's roughly what the generated config looks like:

[timemachine-example]
    vfs objects = catia fruit streams_xattr btrfs shadow_copy2
    fruit:time machine = yes
    fruit:time machine max size = 1T
    ...
    dfree command = /usr/sbin/omv-btrfs-dfree
    dfree cache time = 30

The catch is that when a share has a dfree command, Samba runs it and skips the VFS modules' own free-space calculation entirely (sys_disk_free() in source3/smbd/dfree.c). That's exactly where vfs_fruit applies the Time Machine max size (fruit_disk_free()), so the limit never takes effect. Samba documents dfree command as a replacement for its internal routines, so I don't think Samba is doing anything wrong. It's just that OMV emits both settings on the same share.

As a workaround, I put this in the share's Extra options:

dfree command =

It lands after the generated line and overrides it. Once I applied that, the Mac saw the right size (1100G total for 1T), with free space going down as the backups grow.

For a proper fix, I think shares.j2 could just skip the dfree lines when a share has a Time Machine max size, since vfs_fruit provides the size itself in that case. Something like this, though I haven't actually tested it:

{%- if not (share.timemachine | to_bool and share.timemachinemaxsize | length > 0) %}
dfree command = {{ dfree_command }}
dfree cache time = {{ dfree_cache_time }}
{%- endif %}

This is on openmediavault 8.5.9-1 with samba 2:4.24.7 (Debian backports), a single-device btrfs filesystem, and a Mac on macOS 27.0.1. As far as I can tell it would affect anyone using the max size option (added in GitHub issue #1555) on btrfs.

Does this seem worth a bug report on GitHub? I've got one drafted and I'm happy to open it. (The GitHub template said I should post here before filing.)

Thanks!