Here is how to reproduce it: - On Windows, create a file in a writable directory: echo hello > file - On Linux, try to make the above file have a different inode number: cp file new-file ; mv new-file file - On Windows, try to move the file: move file file-move It returns "move : The parameter is incorrect." After that, any attempt to open the file fails with the same 'The parameter is incorrect'. This is mostly related to https://bugzilla.samba.org/show_bug.cgi?id=14737
My guess would be that the Windows client holds the file open with a handle lease or batch oplock. Can you try the same with oplocks = no smb2 leases = no in the [global] section of your smb.conf? If not, can you upload a full debug level 10 log of the failure? You can find information how to create these under https://wiki.samba.org/index.php/Client_specific_logging
(In reply to Volker Lendecke from comment #1) After setting those 2 options, the issue is no longer reproducible. It's not practical for us not to use oplocks and leases.
(In reply to YOUZHONG YANG from comment #2) > It's not practical for us not to use oplocks and leases. Handle leases allow a client machine to keep files open long beyond the Windows application has closed it. In your scenario: What is your exact required semantics? Your client still has the old "file" open. This is gone by the moment you try to rename it, without the client knowing it. It's a classic cache coherence problem: It would be reasonable to expect that the old "file" is to be renamed, not the new one which the client does not know anything about. What should have happened is that at rename time the Linux kernel informs Samba about this fact, triggering the oplock break, in turn triggering the client to close the file. The problem is that the Linux kernel interface (assuming your base OS is Linux) is insufficient to support the SMB2 notion of leases or even the SMB1 notion of oplocks. This might be worth discussing at one of these linux file system summits where many interested developers sit in a room. Maybe it would be appropriate to also invite interested parties from Ganesha and Samba and not leave it just to kernel people to at least finalize requirements and a path forward.