samba - Mar 2025 - New Samba 4.22 and SMB3 Directory Leases

I decided to try the recently released Samba 4.22. I installed it on a file
server, with no changes to smb.conf.

The new SMB3 Directory Leases function is enabled by default on a
non-clustered system. In my case, it was therefore automatically enabled. I
noticed the behavior I am about to describe.

A directory on this server supports a timestamping service. Any document
copied to that location by the Windows users gets renamed to a timestamp in
the format "doc-YYYYMMDD-HHMMSS". One of the users contacted me,
saying that
the service was not working anymore, whereas in the previous day everything
was fine. I made a test, copying a file to the dir. Contrary to the usual
behavior, which almost immediately presented us with a renamed file, nothing
seemed to be happening. After some time, the original file suddenly
disappeared from Windows Explorer, leaving an apparently empty window. Even
repeatedly refreshing the window manually by using F5 still showed it empty.
Watching the process from the Linux side the renamed file was there as it
should. Finally, after literally several *minutes*, the file appeared on the
Explorer window. I made further testing and the same happened every time.
Remembering that the only change overnight had been the new SMB3 Directory
Leases, I edited the smb.conf file to include "smb3 directory leases =
no".
After reloading the Samba config, the files began to appear instantaneously
on the Explorer window, as usual.

Three question remain:

Is this delay of minutes to be expected with "smb3 directory leases"?

If so, which scenario does the function serve effectively, why and when
would it be needed?

Being new behavior, which can produce unexpected results, shouldn't the
smb.conf default be "no" instead of "auto"? Shouldn't
new behavior be
specifically asked for?

Thank you.

Am 08.03.2025 um 13:40 schrieb miguel medalha via samba:
> I decided to try the recently released Samba 4.22. I installed it on a file
> server, with no changes to smb.conf.
>
> The new SMB3 Directory Leases function is enabled by default on a
> non-clustered system. In my case, it was therefore automatically enabled. I
> noticed the behavior I am about to describe.
>
> A directory on this server supports a timestamping service. Any document
> copied to that location by the Windows users gets renamed to a timestamp in
> the format "doc-YYYYMMDD-HHMMSS". One of the users contacted me,
saying that
> the service was not working anymore, whereas in the previous day everything
> was fine. I made a test, copying a file to the dir. Contrary to the usual
> behavior, which almost immediately presented us with a renamed file,
nothing
> seemed to be happening. After some time, the original file suddenly
> disappeared from Windows Explorer, leaving an apparently empty window. Even
> repeatedly refreshing the window manually by using F5 still showed it
empty.
> Watching the process from the Linux side the renamed file was there as it
> should. Finally, after literally several *minutes*, the file appeared on
the
> Explorer window. I made further testing and the same happened every time.
> Remembering that the only change overnight had been the new SMB3 Directory
> Leases, I edited the smb.conf file to include "smb3 directory leases =
no".
> After reloading the Samba config, the files began to appear instantaneously
> on the Explorer window, as usual.
>
> Three question remain:
>
> Is this delay of minutes to be expected with "smb3 directory
leases"?
>
> If so, which scenario does the function serve effectively, why and when
> would it be needed?
>
> Being new behavior, which can produce unexpected results, shouldn't the
> smb.conf default be "no" instead of "auto"?
Shouldn't new behavior be
> specifically asked for?
>
> Thank you.
>
>
>
Hello,

I experience the delay as well. If I create an file on the linux server it takes
a while till it appears on a windows client.
Seeme hitting F5 does alos not trigger an cache flush and reread of the dir.
Turning of the smb3 directory leases" fixes that.

Achim~