samba - Mar 2024 - byte range lock for Write starting on Zero and negative length ( -9223372036854775808 )

Dear All,

I'm sorry to bother the list with a problem that I am not sure 
originates in Samba.
File server (no domain) is serving a mix of Windows 10 and Centos 7 
clients, I have strange byte range locks.

- Server is Samba 4.17.5 / Kernel 5.14.0 Rocky 9.2

smbstatus -B gives:

- When client is Windows 10:
Byte range locks:
Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
--------------------------------------------------------------------------------
1551641??? 2431:14156401:0 W??? 1000013752 1 /home/geral/DAT????????? 
APLIC/CC/ENCOMEND.DBF

- When client is CentOS 7 (Samba 4.10.16 / kernel 3.10.0)
Byte range locks:
Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
--------------------------------------------------------------------------------
1835914??? 2431:14156401:0 W??? 1000013752 1 /home/geral/DAT/APLIC/CC 
ENCOMEND.DBF

These are correct and the expected behaviour on both cases, files are 
shared and the 1 byte locks for ~write~are correctly honoured.

Problem is with new clients CentOS Stream (Samba 4.18.6 / kernel 5.14.0)
Byte range locks:
Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
--------------------------------------------------------------------------------
1832643??? 2431:14156401:0 R??? 0???????? -9223372036854775808 
/home/geral/DAT????????? APLIC/CC/ENCOMEND.DBF

The file gets locked for ~read~ starting at Zero and with a strange 
(negative) size. No other client can access the file...

The application is an "Harbour Project" production control, accessing 
many DBF/NTX files. It has been behaving rock solid for many years, many 
thanks to all the Samba Team.

Linux clients (Centos7 / Centos Stream ) access the server via automount 
cifs shares:
$cat /etc/auto.geral
 ? geral -fstype=cifs,rw,noperm,credentials=/root/smb.creds ://sol/geral

Windows clients access the server via normal network shares:
 ? net use f: \\sol\geral

The Linux executable is a single file served by the Samba server, so 
both clients (Centos7 and Centos Stream) use the same executable.

My question: Has anyone seen this before, and could kindly give any 
advice in which direction to search for a solution ?
I have searched the list archive, read everything related to "byte range 
locks" but found no clue...

Thanks a lot.
Ant?nio Vila Ch?

On Fri, Feb 02, 2024 at 12:30:11PM +0000, Antonio via samba
wrote:
>Dear All,
>
>I'm sorry to bother the list with a problem that I am not sure 
>originates in Samba.
>File server (no domain) is serving a mix of Windows 10 and Centos 7 
>clients, I have strange byte range locks.
>
>- Server is Samba 4.17.5 / Kernel 5.14.0 Rocky 9.2
>
>smbstatus -B gives:
>
>- When client is Windows 10:
>Byte range locks:
>Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
>--------------------------------------------------------------------------------
>1551641??? 2431:14156401:0 W??? 1000013752 1 /home/geral/DAT????????? 
>APLIC/CC/ENCOMEND.DBF
>
>- When client is CentOS 7 (Samba 4.10.16 / kernel 3.10.0)
>Byte range locks:
>Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
>--------------------------------------------------------------------------------
>1835914??? 2431:14156401:0 W??? 1000013752 1 /home/geral/DAT/APLIC/CC 
>ENCOMEND.DBF
>
>These are correct and the expected behaviour on both cases, files are 
>shared and the 1 byte locks for ~write~are correctly honoured.
>
>Problem is with new clients CentOS Stream (Samba 4.18.6 / kernel 5.14.0)
>Byte range locks:
>Pid??????? dev:inode?????? R/W? start???? size SharePath?????????????? Name
>--------------------------------------------------------------------------------
>1832643??? 2431:14156401:0 R??? 0???????? -9223372036854775808 
>/home/geral/DAT????????? APLIC/CC/ENCOMEND.DBF
>
>The file gets locked for ~read~ starting at Zero and with a strange 
>(negative) size. No other client can access the file...
This (-9223372036854775808) is just 2^64-1 unsigned. i.e. 0xFFFFFFFFFFFFFFFF

Which means lock from 0 until max file size.

Looks like we're not printing out the size correctly (using a decimal
representation).