Samba 3.6.6 and above return NT_STATUS_FILE_CLOSED rather than STATUS_INVALID_DEVICE_REQUEST

[Richard Sharpe]

On Tue, Dec 4, 2012 at 2:55 PM, Richard Sharpe
<realrichardsharpe at gmail.com> wrote:
> On Tue, Dec 4, 2012 at 2:39 PM, Jeremy Allison <jra at samba.org> wrote:
>> On Tue, Dec 04, 2012 at 02:32:49PM -0800, Richard Sharpe wrote:
>>> Hi folks,
>>>
>>> I am seeing NT_STATUS_FILE_CLOSED in response to an IOCTL/FSCTL we do
>>> not understand. I believe this is an error, and use the following in
>>> support of my contention (someone looked at what W2K08 does, but it is
>>> an error.)
>>>
>>> The protocol documents that a non-SMB3-capable (2.002 or 2.1) should
>>> respond to VALIDATE_NEGOTIATE_INFO request with a status error of
>>> STATUS_INVALID_DEVICE_REQUEST, the same error as for any unsupported
>>> FSCTL. Windows Server 2008 (SMB 2.002) and Windows Server 2008 R2 (SMB
>>> 2.1) return STATUS_FILE_CLOSED, instead.
>>>
>>> >From here: http://blogs.msdn.com/b/openspecification/archive/2012/06/28/smb3-secure-dialect-negotiation.aspx
>>>
>>> The downside is that the Windows client thinks the file is closed and
>>> does not explicitly close it leaving an entry in our locking.tdb and
>>> causing havoc with MS Office apps.
>>
>> Hmmm. Hang on a minute. Note here in the document you linked to above:
>>
>> "The protocol documents that a non-SMB3-capable (2.002 or 2.1) should
>> respond to VALIDATE_NEGOTIATE_INFO request with a status error of
>> STATUS_INVALID_DEVICE_REQUEST, the same error as for any unsupported
>> FSCTL. Windows Server 2008 (SMB 2.002) and Windows Server 2008 R2
>> (SMB 2.1) return STATUS_FILE_CLOSED, instead."
>>
>> So there are some versions of Windows that do return STATUS_FILE_CLOSED.
>
> Yes, it seems so. However, upon re-reading that, I am confused as to
> whether they mean that W2K08 returns STATUS_FILE_CLOSED when they get
> an unsupported device request or what.
>
> I imagine that very few (perhaps zero) Windows clients ever send an
> unsupported IOCTL/FSCTL to W2K08 and it is not license for us to do
> the wrong thing :-)

Hmmm, regardless of whether we are doing the correct thing or the
wrong thing in general, it looks like the problem is that this
occurred in a compound operation consisting of a CREATE followed by an
IOCTL for an FSCTL and that the FSP from the create was not forwarded
to the IOCTL handling code.

[2012/12/04 14:59:00.227924, 10] smbd/smb2_server.c:2572(smbd_smb2_request_incom
ing)
  smbd_smb2_request_incoming: idx[1] of 4 vectors
[2012/12/04 14:59:00.228000, 10] smbd/smb2_server.c:354(smb2_validate_message_id
)
  smb2_validate_message_id: clearing id 32 (position 32) from bitmap
[2012/12/04 14:59:00.228045, 10] smbd/smb2_server.c:1222(smbd_smb2_request_dispa
tch)
  smbd_smb2_request_dispatch: opcode[SMB2_IOCTL] mid = 32
[2012/12/04 14:59:00.228089,  4] smbd/uid.c:351(change_to_user)
  Skipping user change - already user
[2012/12/04 14:59:00.228269, 10] smbd/smb2_ioctl.c:253(smbd_smb2_ioctl_send)
  smbd_smb2_ioctl: ctl_code[0x00110018] <no handle> fnum[-1]
[2012/12/04 14:59:00.228413, 10] smbd/smb2_ioctl.c:376(smbd_smb2_ioctl_send)
  Returning FILE_CLOSED (THIS IS MY DEBUGGING LINE TO SEE WHERE the
ERROR is coming from.)
[2012/12/04 14:59:00.228491, 10] smbd/smb2_ioctl.c:141(smbd_smb2_request_ioctl_d
one)
  smbd_smb2_request_ioctl_done: smbd_smb2_ioctl_recv returned 0 status NT_STATUS
_FILE_CLOSED


-- 
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)