Antonio
2024-Feb-02 12:30 UTC
[Samba] 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?
Jeremy Allison
2024-Mar-21 17:53 UTC
[Samba] byte range lock for Write starting on Zero and negative length ( -9223372036854775808 )
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).