Reported by: Christof Schmitt <christof.schmitt@us.ibm.com> on the samba-technical mailing list. When a share contains many entries (more than 583 subdirectories in my test, frame 164), the Windows client issues a FIND request, asking for a @GMT timestamp. This does not make sense, and a Windows server responds with STATUS_NO_SUCH_FILE (frame 167). After this, the query works as expected: 78 2.009991000 10.0.100.9 -> 10.0.100.90 SMB2 Ioctl Request FSCTL_GET_SHADOW_COPY_DATA File: 2.009991000 0.009541000 52529 microsoft-ds 79 2.010492000 10.0.100.90 -> 10.0.100.9 SMB2 Ioctl Response FSCTL_GET_SHADOW_COPY_DATA File: 2.010492000 0.000501000 microsoft-ds 52529 80 2.022120000 10.0.100.9 -> 10.0.100.90 SMB2 Ioctl Request FSCTL_GET_SHADOW_COPY_DATA File: 2.022120000 0.011628000 52529 microsoft-ds 81 2.022521000 10.0.100.90 -> 10.0.100.9 SMB2 Ioctl Response FSCTL_GET_SHADOW_COPY_DATA File: 2.022521000 0.000401000 microsoft-ds 52529 82 2.022665000 10.0.100.9 -> 10.0.100.90 SMB2 GetInfo Request FILE_INFO/SMB2_FILE_EA_INFO File: 2.022665000 0.000144000 52529 microsoft-ds 83 2.023028000 10.0.100.90 -> 10.0.100.9 SMB2 GetInfo Response 2.023028000 0.000363000 microsoft-ds 52529 84 2.023243000 10.0.100.9 -> 10.0.100.90 SMB2 Ioctl Request FSCTL_GET_REPARSE_POINT File: 2.023243000 0.000215000 52529 microsoft-ds 85 2.023698000 10.0.100.90 -> 10.0.100.9 SMB2 Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT 2.023698000 0.000455000 microsoft-ds 52529 86 2.023933000 10.0.100.9 -> 10.0.100.90 SMB2 Ioctl Request FSCTL_GET_REPARSE_POINT File: 2.023933000 0.000235000 52529 microsoft-ds 87 2.024355000 10.0.100.90 -> 10.0.100.9 SMB2 Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT 2.024355000 0.000422000 microsoft-ds 52529 88 2.024690000 10.0.100.9 -> 10.0.100.90 SMB2 Create Request File: @ 2.024690000 0.000335000 52529 microsoft-ds 89 2.025357000 10.0.100.90 -> 10.0.100.9 SMB2 Create Response File: 2.025357000 0.000667000 microsoft-ds 52529 90 2.025539000 10.0.100.9 -> 10.0.100.90 SMB2 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: 2.025539000 0.000182000 52529 microsoft-ds 91 2.026015000 10.0.100.90 -> 10.0.100.9 SMB2 GetInfo Response 2.026015000 0.000476000 microsoft-ds 52529 92 2.026113000 10.0.100.9 -> 10.0.100.90 SMB2 Close Request File: 2.026113000 0.000098000 52529 microsoft-ds 93 2.026497000 10.0.100.90 -> 10.0.100.9 SMB2 Close Response 2.026497000 0.000384000 microsoft-ds 52529 94 2.026955000 10.0.100.9 -> 10.0.100.90 SMB2 Create Request File: 2.026955000 0.000458000 52529 microsoft-ds 95 2.027479000 10.0.100.90 -> 10.0.100.9 SMB2 Create Response File: 2.027479000 0.000524000 microsoft-ds 52529 96 2.027643000 10.0.100.9 -> 10.0.100.90 SMB2 Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 2.027643000 0.000164000 52529 microsoft-ds 164 2.063609000 10.0.100.90 -> 10.0.100.9 SMB2 Find Response SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Response SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 2.063609000 0.035966000 microsoft-ds 52529 166 2.064996000 10.0.100.9 -> 10.0.100.90 SMB2 Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: @GMT-2013.08.28-19.49.46 2.064996000 0.001387000 52529 microsoft-ds 167 2.065371000 10.0.100.90 -> 10.0.100.9 SMB2 Find Response, Error: STATUS_NO_SUCH_FILE SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: @GMT-2013.08.28-19.49.46 2.065371000 0.000375000 microsoft-ds 52529 168 2.065492000 10.0.100.9 -> 10.0.100.90 SMB2 Close Request File: 2.065492000 0.000121000 52529 microsoft-ds 169 2.065813000 10.0.100.90 -> 10.0.100.9 SMB2 Close Response 2.065813000 0.000321000 microsoft-ds 52529 170 2.065961000 10.0.100.9 -> 10.0.100.90 SMB2 Create Request File: @ 2.065961000 0.000148000 52529 microsoft-ds 171 2.066310000 10.0.100.90 -> 10.0.100.9 SMB2 Create Response File: 2.066310000 0.000349000 microsoft-ds 52529 With the shadow_copy2 module, Samba returns that that a directory with the @GMT name exists, and that seems to confuse the Windows client. It continues issuing FIND requests for the snapshot timestamps, and the "previous versions" dialog on the client displays the timestamps instead of the directories: 72 6.133792000 10.0.100.9 -> 10.0.100.133 SMB2 Ioctl Request FSCTL_GET_SHADOW_COPY_DATA File: 6.133792000 0.000189000 52523 microsoft-ds 73 6.134517000 10.0.100.133 -> 10.0.100.9 SMB2 Ioctl Response FSCTL_GET_SHADOW_COPY_DATA File: 6.134517000 0.000725000 microsoft-ds 52523 74 6.134659000 10.0.100.9 -> 10.0.100.133 SMB2 Ioctl Request FSCTL_GET_SHADOW_COPY_DATA File: 6.134659000 0.000142000 52523 microsoft-ds 75 6.135322000 10.0.100.133 -> 10.0.100.9 SMB2 Ioctl Response FSCTL_GET_SHADOW_COPY_DATA File: 6.135322000 0.000663000 microsoft-ds 52523 76 6.135478000 10.0.100.9 -> 10.0.100.133 SMB2 GetInfo Request FILE_INFO/SMB2_FILE_EA_INFO File: 6.135478000 0.000156000 52523 microsoft-ds 77 6.135969000 10.0.100.133 -> 10.0.100.9 SMB2 GetInfo Response 6.135969000 0.000491000 microsoft-ds 52523 78 6.136164000 10.0.100.9 -> 10.0.100.133 SMB2 Ioctl Request FSCTL_GET_REPARSE_POINT File: 6.136164000 0.000195000 52523 microsoft-ds 79 6.136580000 10.0.100.133 -> 10.0.100.9 SMB2 Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT 6.136580000 0.000416000 microsoft-ds 52523 80 6.136826000 10.0.100.9 -> 10.0.100.133 SMB2 Ioctl Request FSCTL_GET_REPARSE_POINT File: 6.136826000 0.000246000 52523 microsoft-ds 81 6.137186000 10.0.100.133 -> 10.0.100.9 SMB2 Ioctl Response, Error: STATUS_NOT_A_REPARSE_POINT 6.137186000 0.000360000 microsoft-ds 52523 82 6.137433000 10.0.100.9 -> 10.0.100.133 SMB2 Create Request File: @ 6.137433000 0.000247000 52523 microsoft-ds 83 6.139981000 10.0.100.133 -> 10.0.100.9 SMB2 Create Response File: 6.139981000 0.002548000 microsoft-ds 52523 84 6.140144000 10.0.100.9 -> 10.0.100.133 SMB2 GetInfo Request FILE_INFO/SMB2_FILE_NETWORK_OPEN_INFO File: 6.140144000 0.000163000 52523 microsoft-ds 85 6.140734000 10.0.100.133 -> 10.0.100.9 SMB2 GetInfo Response 6.140734000 0.000590000 microsoft-ds 52523 86 6.140823000 10.0.100.9 -> 10.0.100.133 SMB2 Close Request File: 6.140823000 0.000089000 52523 microsoft-ds 87 6.141326000 10.0.100.133 -> 10.0.100.9 SMB2 Close Response 6.141326000 0.000503000 microsoft-ds 52523 88 6.141929000 10.0.100.9 -> 10.0.100.133 SMB2 Create Request File: 6.141929000 0.000603000 52523 microsoft-ds 89 6.143024000 10.0.100.133 -> 10.0.100.9 SMB2 Create Response File: 6.143024000 0.001095000 microsoft-ds 52523 90 6.146329000 10.0.100.9 -> 10.0.100.133 SMB2 Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 6.146329000 0.003305000 52523 microsoft-ds 178 6.952212000 10.0.100.133 -> 10.0.100.9 SMB2 Find Response SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *;Find Response SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: * 6.952212000 0.805883000 microsoft-ds 52523 180 6.953016000 10.0.100.9 -> 10.0.100.133 SMB2 Find Request File: SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: @GMT-2013.08.28-19.28.26 6.953016000 0.000804000 52523 microsoft-ds 182 6.954676000 10.0.100.133 -> 10.0.100.9 SMB2 Find Response SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: @GMT-2013.08.28-19.28.26 6.954676000 0.001660000 microsoft-ds 52523 The best way to fix this seems to be in smb2_find.c. The shadow_copy2 module only sees a stat call, and cannot decide if the stat legitimate or if it should be rejected.
Fix applied to master may be cherry-picked for 4.1.0 and 4.0.next by: git cherry-pick -x c8c0632c871e838fc4465b2a69b4e059e9a126c0 Jeremy.
Created attachment 9204 [details] git-am fix that went into master. Applies cleanly to 4.0.next and 4.1.0. Jeremy.
Re-assigning to Karolin for inclusion in 4.1.0, 4.0.next. Jeremy.
Pushed to autobuildv-4-1-test and autobuild-v4-0-test.
Pushed to v4-1-test and v4-0-test. Closing out bug report. Thanks!