Bug 10985 - Problem with moving and renaming files
Problem with moving and renaming files
Product: Samba 4.1 and newer
Classification: Unclassified
Component: File services
All Linux
: P5 critical
: ---
Assigned To: Jeremy Allison
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2014-12-05 13:36 UTC by Patrick Schönbach
Modified: 2015-12-21 12:44 UTC (History)
4 users (show)

See Also:

smb.conf (2.88 KB, text/plain)
2015-05-13 19:40 UTC, Patrick Schönbach
no flags Details
Network capture of renaming operation from Windows 7 client (58.64 KB, application/x-gzip)
2015-05-14 13:26 UTC, Patrick Schönbach
no flags Details
attachment-2093990-0.html (deleted)
2015-10-01 12:08 UTC, Anubhav Rakshit
no flags Details
Registry Settings LanmanWorkstation (112.76 KB, text/x-ms-regedit)
2015-10-12 21:04 UTC, Patrick Schönbach
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Patrick Schönbach 2014-12-05 13:36:23 UTC
My samba server runs on an openSUSE 13.2 x64 box, client is a Windows 7 x64 machine.

If I move a file into a directory that is at least 2 hierarchy levels deep or if I rename a file in such a directory, the file no longer exists in that directory but ends up in the root directory of the share. This happens on any share.
Comment 1 Patrick Schönbach 2015-05-06 12:14:02 UTC
The problem still persists and it is most annoying. Any progress?
Comment 2 Björn Jacke 2015-05-13 19:34:39 UTC
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?
Comment 3 Patrick Schönbach 2015-05-13 19:40:04 UTC
Created attachment 11052 [details]

Here is my configuration.
Comment 4 Patrick Schönbach 2015-05-13 21:33:18 UTC
Rename with smbclient works as expected.
Comment 5 Patrick Schönbach 2015-05-14 13:26:31 UTC
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
Comment 6 Anubhav Rakshit 2015-06-29 07:02:53 UTC
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	SMB2	SetInfoRequest, FileName: test1\test2\Test.txt@#670, InfoType: File, FileInfoClass: FileRenameInformation	
673	None	2015-05-14T06:16:28.4832390	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

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.
Comment 7 Patrick Schönbach 2015-06-29 10:22:23 UTC
This is strange, as my Win 7 installation did not change.

What could be wrong?
Comment 8 Patrick Schönbach 2015-09-30 13:05:22 UTC
I am still puzzled why Win 7 is sending an incorrect request here. Does anyone have any idea what might cause this?
Comment 9 Anubhav Rakshit 2015-10-01 12:08:04 UTC
Created attachment 11469 [details]


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.

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.
Comment 10 Stefan Metzmacher 2015-10-03 09:10:10 UTC
(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.
Comment 11 Patrick Schönbach 2015-10-03 09:51:37 UTC
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?
Comment 12 Patrick Schönbach 2015-10-03 10:02:58 UTC
Not szew how to remove NEEDINFO here...
Comment 13 Stefan Metzmacher 2015-10-05 13:29:36 UTC
(In reply to Patrick Schönbach from comment #12)

Can you test the same against a windows server?
Comment 14 Anubhav Rakshit 2015-10-05 13:41:07 UTC
Patrick: Do you have Folder Redirection or Roaming Profiles enabled?
Comment 15 Patrick Schönbach 2015-10-05 14:05:07 UTC
(In reply to Stefan Metzmacher from comment #13)
Unfortunately not. Don't have one.
Comment 16 Patrick Schönbach 2015-10-05 14:06:24 UTC
(In reply to Anubhav Rakshit from comment #14)
Don't think so. However, to be sure: How do I check this?
Comment 17 Stefan Metzmacher 2015-10-05 23:01:56 UTC
(In reply to Patrick Schönbach from comment #15)

Even not a 2nd Windows 7 Machine?
Comment 18 Patrick Schönbach 2015-10-06 09:26:55 UTC
(In reply to Stefan Metzmacher from comment #17)
Unfortunately not.
Comment 19 Anubhav Rakshit 2015-10-06 09:51:51 UTC
You can try installing a VM with Win 7.
Comment 20 Patrick Schönbach 2015-10-06 09:58:20 UTC
(In reply to Anubhav Rakshit from comment #19)
Ok, I will.

Still, isn't it a client side problem?
Comment 21 Anubhav Rakshit 2015-10-06 10:13:51 UTC
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.
Comment 22 Patrick Schönbach 2015-10-06 21:22:55 UTC
Ok, tried it. On a fresh Windows install, it works.

Now, the big question: What setting could be wrong? :)
Comment 23 Patrick Schönbach 2015-10-12 21:04:41 UTC
Created attachment 11488 [details]
Registry Settings LanmanWorkstation

Here are my registry settings related to the SMB client of Windows. Are there any anomalies?
Comment 24 Patrick Schönbach 2015-10-24 16:04:03 UTC
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?
Comment 25 Patrick Schönbach 2015-11-11 11:37:55 UTC
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?
Comment 26 Björn Jacke 2015-12-21 12:44:15 UTC
The content of attachment 11469 [details] has been deleted for the following reason:

HTML shit