Investigating durable handle errors

[Sjors Gielen]

Dear list,

If anyone could spare a few minutes to explain the below branch of durable disconnect to me, I would be thankful and could continue with my investigation of failing reconnections on a macOS client. I am hoping to investigate towards a meaningful patch in Samba if it turns out to be a code issue on the Samba side.

Thank you,
Sjors

Op zo 18 jan 2026, om 1:50 schreef Sjors Gielen:
> Dear list,
> 
> Since an upgrade to macOS Tahoe about two months ago, I've been having issues in Time Machine backups to my Samba server. I've been investigating them over the past few weeks (learning the protocol, taking pcaps, checking log messages, writing test clients and reading source code), and have upgraded to Samba 4.23.4 and improved various configurations. With this, the backups do run for a while, but eventually always seem to result in a TCP reset and subsequent failing reconnection / reopening of durable handles. The TCP resets I understand, but the failing reopening of durable handles seem to be caused by many different reasons that I'm trying to untangle and fix one by one.
> 
> One of the error messages I often see is the following:
> 
>> Failed to disconnect durable handle for file charmeleon.sparsebundle/Info.plist: NT_STATUS_NOT_SUPPORTED - proceeding with normal close
> 
> This NT_STATUS_NOT_SUPPORTED is coming from the VFS durable_disconnect function, which in my case is a Linux mounted network filesystem so it's implemented by vfs_default_durable_disconnect. In fact, through debugging I've noticed the following branch is going off:
> 
>> if (fsp->current_lock_count != 0 &&
>>     (fsp_lease_type(fsp) & SMB2_LEASE_WRITE) == 0)
>> {
>> return NT_STATUS_NOT_SUPPORTED;
>> }
> 
> Am I right in interpreting that Samba does not support disconnecting a lock if it's held by other sessions as well, but not if held for writing? What about this scenario is unsupported?
> 
> Thanks for any clarifications.
> 
> Best,
> Sjors