https://bugs.documentfoundation.org/show_bug.cgi?id=151865
--- Comment #1 from Chris Sherlock <[email protected]> --- Thank you for the detailed report and clear reproduction steps. This issue is caused by the interaction between LibreOffice's atomic saving mechanism and the Linux CIFS client mount option nobrl. 1. By default, LibreOffice uses an atomic "safe save" routine: when saving changes, it writes to a temporary file and replaces the destination file via rename/unlink rather than overwriting it in-place. 2. In the CIFS/SMB protocol, renaming or unlinking a file that is actively held open by another client (even in read-only mode) requires strict file-sharing and lock negotiation. 3. Because the share is mounted with the nobrl (no byte range locks) option, CIFS lock negotiation with the server is disabled. When User 1 attempts to save, the Linux CIFS kernel client attempts to unlink/replace the target, but because User 2 has an active open handle, the file enters an SMB delete-on-close / pending-delete state. 4. The atomic rename fails with a sharing violation or ENOENT ("file is missing"). The directory entry becomes inaccessible or removed from the share, but User 2's client still holds the data handle open—explaining why User 1 cannot complete the save until User 2 closes the file. Windows clients do not hit this problem because the Windows SMB client natively coordinates share-mode semantics (FILE_SHARE_READ/WRITE/DELETE) directly with the server. Could you please test the following and report back? 1. Test without nobrl in the mount options: Edit /etc/fstab on the Debian clients, remove nobrl, and explicitly specify a modern SMB dialect: Change: uid=1000,gid=1000,dir_mode=0777,file_mode=0777,iocharset=utf8,nobrl,_netdev 0 0 To: uid=1000,gid=1000,dir_mode=0777,file_mode=0777,iocharset=utf8,vers=3.1.1,actimeo=1,_netdev 0 0 Remount the share and check if the file deletion still occurs. 2. Test disabling atomic safe saving in LibreOffice: If nobrl is strictly required in your environment, test disabling atomic saving so LibreOffice writes directly to the existing file handle: - Go to Tools > Options > LibreOffice > Advanced > Open Expert Configuration. - Search for: UseDocumentSafeSaving - Set org.openoffice.Office.Common / Save / Document / UseDocumentSafeSaving to false. - Restart LibreOffice and test saving while User 2 has the file open. Can you clarify the following: Was nobrl added originally to work around specific CIFS locking hangs or performance issues? When the failure occurs, does dmesg -T on User 1's machine log CIFS errors such as STATUS_SHARING_VIOLATION or STATUS_CANNOT_DELETE? When User 2 opens the file, is the hidden lockfile (.~lock.<filename>#) visible to User 1 on the share? -- You are receiving this mail because: You are the assignee for the bug.
