Samba strange byte range locks

[António]

Dear All,
Using samba as file server , client machines are a mix of Centos Linux 7 and Windows 10.  All clients using the same Harbour application to access shared DBF/NTX files.

File server (Rocky Linux 9.2)  is:   samba-4.17.5-103.el9_2.x86_64  
/etc/samba/smb.conf contains basically:
[global]
        workgroup = XPTO
        security = user
        passdb backend = tdbsam
        level2 oplocks = No
        oplocks = No
        hostname lookups = Yes
        acl allow execute always = Yes
        dos filemode = Yes


Trying to move client machines away from Centos 7, I have been seeing strange byte range locks on a new Rocky Linux 9.2 client test machine.

With old clients  Centos 7.9 -> samba-client-4.10.16-24.el7_9.x86_64:
Byte range locks:
Pid        dev:inode       R/W  start     size      SharePath               Name
3396       2431:14156401:0 W    1000013612 1         ENCOMEND.DBF
Correct and expected behavior: 1 byte  (1000013612) locked for writing.


 But with new client Rocky Linux 9.2 -> samba-client-4.17.5-102.el9.x86_64:
Byte range locks:
Pid        dev:inode       R/W  start     size      SharePath               Name
8780       2431:14156401:0 R    0         -9223372036854775808  ENCOMEND.DBF           

The same file gets blocked an not available to any other client, either for reading or writing.
Searched for that size of "-9223372036854775808" it appears to be the lowest  signed integer that can be stored in 64bits...
Having a range of negative length must mean something is wrong.
Has anyone seen this, and could share some direction where to look for ?

Have just built both Harbour (2023-07-07 00:07) and my application on Rocky 9, with no luck...

Thanks in advance,
António Vila-Chã, Portugal

[Gerald Drouillard]

Here is our smb.conf:

;Make sure /etc/security/limits.conf has the following or you will run out of file handles
;* soft nofile 524288
;* hard nofile 524288

;When testing connectivity issues it may be a good idea to do a: "net use * /delete" or reboot to test
;If netperf testing is locking up using one machine, it is possible that there is an issue with the NIC
; try testing from another machine(s)
[global]
    log level = 1
;    may be need to join the domain with smb1 is the max protocol
    client ipc max protocol=CORE
    client ipc min protocol=NT1
client max protocol = NT1
client min protocol = CORE
   idmap config * :              backend = tdb
   idmap config * :              range   = 30000-79999
   idmap config ASKMI : backend = tdb
   idmap config ASKMI : range   = 100000-999999

    aio write size=0
    aio read size=0

;gd 12/8/20: removing these 3 that were added 8/2/20... may no be playing nice
;    lock spin time=0
;    max xmit=65535
;    socket options = IPTOS_LOWDELAY TCP_NODELAY SO_RCVBUF=131072 SO_SNDBUF=131072

    ;can trim 6 seconds off the netperf test and seems to lower cpu just a little.
;    socket options = IPTOS_LOWDELAY TCP_NODELAY
    ;These did not seems to make much of a diff
    ;SO_RCVBUF=65536 SO_SNDBUF=65536
    socket options = TCP_NODELAY
    ;SO_RCVBUF=65536 SO_SNDBUF=65536
    server signing=No

    ;ubuntu 18: this caused the netperf to lock up if set to yes for ext4 and zfs
    posix locking=no    

    ;stat cache =yes ;default

    ;no much of a diff between y/n
    kernel share modes=no

    kernel oplocks=no

    ;if yes the cpu climbs a little and test time almost double
    strict sync=no

    sync always=no
    strict locking=no
    unix extensions=no

    map acl inherit=yes
    smb2 leases=no



    server min protocol=SMB2
    server max protocol=SMB2
   
    #3/12/16 the following line did not make any diff with netperf
    #server max protocol = SMB3

    #needed for joining a domain that is "server role=classic primary domain controller"
    server role = member server
    #6/18 increased files from 65535 to 131070
    max open files = 131070
    load printers = no
    printing=bsd
    printcap name=/dev/null
    show add printer wizard=no
    disable spoolss=yes
    wide links =no

    name resolve order = wins bcast host
    dns proxy=no


    workgroup = YOURDOMAIN
    #3.x servers can use:
    security = domain

    #For version 4.x this will probably be needed:
    #security=user

    #for BDC
    #domain logons=yes
    #domain master=no
    #for PDC
    #domain logons=yes
    #domain master=yes

    map to guest = bad user
    guest account=nobody
   
    password server = 192.168.0.11
    wins server = 192.168.0.11
;   winbind separator=\
    winbind enum users = Yes
    winbind enum groups = Yes
    winbind use default domain = Yes
    winbind nested groups = Yes
   local master =no
   domain master=no
   template shell=/bin/bash

;   smb ports=445

    create mask=000
    directory mask=000
    force create mode=660
    force directory mode=770
    obey pam restrictions=no
    #if obey pam restrictions=yes you may need to change /etc/login.defs to 002
    usershare prefix deny list = /
    nt acl support=no
    veto oplock files =/*.dbf/*.DBF/*.fpt/*.FPT/*.cdx/*.CDX/*.RYO/
    oplocks = no
    level2 oplocks = no
    use sendfile=no
    veto files=/.snapshot/.zfs/

;Client side caching policy values:  manual,documents,programs,disable  default=manual
;    csc policy=disable

    ;Don't send the client's "file explorer" new file sizes, etc when the file changes...make them request a refresh.
    ;change notify=no


[data]
    path = /zfspool/srv/pubdocs
    wide links=yes
    inherit acls=yes
    inherit permissions=yes
    guest ok=no
    writable = yes
    public = yes
    printable = no
    force group = users
    acl allow execute always=true
    create mask=0660
    force create mode=0660
    #the following directory settings work and create directory with 42770, chmod 2770 /srv/costing
    force directory mode=02770
    directory mask=02770

--
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
Unsubscribe: harbour-user...@googlegroups.com
Web: https://groups.google.com/group/harbour-users
---
You received this message because you are subscribed to the Google Groups "Harbour Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to harbour-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/harbour-users/d3a77dcc-1c37-4075-8e3b-437a4bdd3b7an%40googlegroups.com.