Bug 15485 - INVALID_PARAMETER is returned when trying to open a file with its inode number changed
Summary: INVALID_PARAMETER is returned when trying to open a file with its inode numbe...
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services (show other bugs)
Version: 4.18.3
Hardware: All All
: P5 regression (vote)
Target Milestone: ---
Assignee: Samba QA Contact
QA Contact: Samba QA Contact
Depends on:
Reported: 2023-10-04 02:13 UTC by YOUZHONG YANG
Modified: 2023-10-08 11:58 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description YOUZHONG YANG 2023-10-04 02:13:33 UTC
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
Comment 1 Volker Lendecke 2023-10-06 15:03:23 UTC
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
Comment 2 YOUZHONG YANG 2023-10-06 15:31:34 UTC
(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.
Comment 3 Volker Lendecke 2023-10-08 11:58:50 UTC
(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.