Problem recurrence： On the server side, a process opens a file in a shared directory and adds a POSIX write lock. For example, use WPS to open 123.xls. On the client side, an error (NT_STATUS_FILE_LOCK_CONFLICT) will be reported when using smbclient or libsmbclient to download an opened file. But opened files can be downloaded normally through CIFS. The preliminary test found that the file download can be completed after completing the following modifications: Change the initial value of the flags variable in the functions SMBC_server_internal and do_connect to CLI_FULL_CONNECTION_OPLOCKS. What I want to ask is: Is there any risk to this modification. Is there a configuration to control oplock behavior on the client side. Looking forward to your reply, thanks!
This is dependent on the server locking settings. To make clients ignore server-side POSIX write locks, set: posix locking = no on the share definition in your smb.conf. When you say: "But opened files can be downloaded normally through CIFS." I'm assuming you mean the Linux kernel cifsfs client. That also depends on settings on the mount. oplocks are nothing to do with server-side byte range locks.
Thanks for your reply. The man page says setting "posix locking = no" is not a good idea. With the server using the default settings ("posix locking = yes"), cifsfs can access files opened on the server because its oplock is Lease (0xff), which is the same as Win11, but smbclient cannot access files opened on the server because Its oplock is always No oplock (0x00). cifsfs will use lease oplock by default unless the mount option nolease is used. Does smbclient support oplock related configuration, similar to the nolease mount option of cifsfs?
Please do not re-open bugs I have closed due to mis-understandings. If you re-open again I will have your account removed from the bugzilla. oplocks have *NOTHING* to do with byte range locks. The two are completely disjoint. Please do some research on the difference between oplocks/leases and byte range locks. It isn't my job to educate you on this bugzilla. I'll be happy to answer any questions you may have on the samba mailing list, but our bug tracking database isn't the place for questions like this.