The problem still persists and it is most annoying. Any progress?

obviously most people don't suffer from such a problem. But to have a chance to see what might cause that for you, you need to add more details about your setup. full smb.conf would be a good start. Then, please also test with other clients: how do Linux cifs client, smbclient work for that case?

Created attachment 11052 [details]
smb.conf

Here is my configuration.

Rename with smbclient works as expected.

Created attachment 11056 [details]
Network capture of renaming operation from Windows 7 client

And furthermore, here is a network capture of the renaming operation from a Windows 7 client.

From: test1\test2\Test.txt
To:   test1\test2\Renamed.txt

Looking through the Rename.pcap.gz packet cap. attached:


The frames of interest are Frames 672 and 673. 

===
MessageNumber	DiagnosisTypes	Timestamp	TimeElapsed	Source	Destination	Module	Summary	
672	None	2015-05-14T06:16:28.4825610		192.168.2.12	192.168.2.1	SMB2	SetInfoRequest, FileName: test1\test2\Test.txt@#670, InfoType: File, FileInfoClass: FileRenameInformation	
673	None	2015-05-14T06:16:28.4832390		192.168.2.1	192.168.2.12	SMB2	SetInfoResponse, Status: Success, FileName: test1\test2\Test.txt@#670	
===

We can see that Win7 Client is sending the following SetInfoRequest
===
Name	Value	Bit Offset	Bit Length	Type	
Request	SMB2SetInfoRequest{StructureSize=33,InfoType=1,FileInfoClass=10,BufferLength=46,BufferOffset=96,Reserved=0,AdditionalInformation=0,FileId=Persistent = 0x000000003A5B7A8F, Volatile = 0x0000000046F4532D,Buffer=SMB20InfoFileBuffer{SMB20InfoFile=FileRenameInformationForSMB2{ReplaceIfExists=0,Reserved=[0,0,0,0,0,0,0],RootDirectory=0,FileNameLength=22,FileName=Renamed.txt}}}	512	592	SMB2.SMB2SetInfoRequest	

===

Note that "FileName=Renamed.txt", this is causing the file to be moved to the root of the share. According to the SMB2 specs. the expectation is that FileName should contain the complete pathname relative to root of the share.

===
FileName (variable): A sequence of Unicode characters containing the new name of the file.
When working with this field, use FileNameLength to determine the length of the file name
rather than assuming the presence of a trailing null delimiter. If the RootDirectory field is
zero, this member MUST specify a full pathname to be assigned to the file. For network
operations, this pathname is relative to the root of the share. If the RootDirectory field is not
zero, this field MUST specify a pathname, relative to RootDirectory, for the new name of the
file.
===

So from Samba server point of view the server is doing exactly what the client is instructing it to perform. We will need to investigate why Win7 client is not sending the complete pathname.

This is strange, as my Win 7 installation did not change.

What could be wrong?

I am still puzzled why Win 7 is sending an incorrect request here. Does anyone have any idea what might cause this?

Created attachment 11469 [details]
attachment-2093990-0.html

+Jeremy

Hi Jeremy,

If you find some time can you please look at this bug. I have triaged it
but I am not entirely sure how to move forward.

Thanks,
Anubhav
On Sep 30, 2015 6:35 PM, <samba-bugs@samba.org> wrote:

> https://bugzilla.samba.org/show_bug.cgi?id=10985
>
> --- Comment #8 from Patrick Schönbach <pschoenb@gmx.de> ---
> I am still puzzled why Win 7 is sending an incorrect request here. Does
> anyone
> have any idea what might cause this?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

(In reply to Anubhav Rakshit from comment #9)

According to the MS-SMB2 and the Microsoft dochelp team, our behavior
is correct. It was not possible to reproduce the problem.

Patrick: which application are you using? Powershell, cmd and Explorer
rename the file as expected using the full path to the new file name.

This is extremely weird. Explorer, as well as any other file manager, don't work for me.

Maybe, there is some weird registry setting or something that is misconfigured here?

Not szew how to remove NEEDINFO here...

(In reply to Patrick Schönbach from comment #12)

Can you test the same against a windows server?

Patrick: Do you have Folder Redirection or Roaming Profiles enabled?

(In reply to Stefan Metzmacher from comment #13)
Unfortunately not. Don't have one.

(In reply to Anubhav Rakshit from comment #14)
Don't think so. However, to be sure: How do I check this?

(In reply to Patrick Schönbach from comment #15)

Even not a 2nd Windows 7 Machine?

(In reply to Stefan Metzmacher from comment #17)
Unfortunately not.

You can try installing a VM with Win 7.

(In reply to Anubhav Rakshit from comment #19)
Ok, I will.

Still, isn't it a client side problem?

Yes this is a client side problem.
Now we want to prove that the issue is with your Win7 install.
Since you do not have a second Win 7 host, my suggestion is to install VM on your current system. This VM being a fresh Win7 installation should be able to show that rename etc. work as expected.

Ok, tried it. On a fresh Windows install, it works.

Now, the big question: What setting could be wrong? :)

Created attachment 11488 [details]
Registry Settings LanmanWorkstation

Here are my registry settings related to the SMB client of Windows. Are there any anomalies?

I compared the LanmanWorkstation settings of a fresh Windows installation with the ones on my local system. I didn't find any significant differences.

What else could cause this weird behavior?

Now, that is really weird: I did not change my Windows machine, but I upgraded the server to openSUSE Leap 42.1, and the problem is gone suddenly - at least for now.

Any reasonable explanation for this?

The content of attachment 11469 [details] has been deleted for the following reason:

HTML shit

closing as according to comment 25 it worked in a leter updated version