[cifs-protocol] [REG:116022313745563] Windows 10 backup failing against Samba
bburgin at microsoft.com
Wed Feb 24 17:36:36 UTC 2016
[dochelp to bcc]
We created Sr 116022313745563 to track this issue, which I will work on.
Reviewing your trace, let me focus on frames 540/541, the Create command/response for the file:
WindowsImageBackup\DESKTOP-610P64R\Backup 2016-02-23 183014\1948156d-0000-0000-0000-100000000000.vhdx
The request includes the [MS-RSVD] 188.8.131.52 184.108.40.206 SVHDX_OPEN_DEVICE_CONTEXT_V2 Structure per the [MS-SMB2] 220.127.116.11 SMB2_CREATE_CONTEXT using the name SVHDX_OPEN_DEVICE_CONTEXT " 0x9CCBCF9E04C1E643980E158DA1F6EC83".
The Samba server is returning STATUS_INVALID_DEVICE_REQUEST (0xC0000010).
This was the documented-correct behavior in an earlier build of [MS-SMB2] (albeit, [MS-SMB2] specified the error STATUS_INVALID_PARAMETER, not STATUS_INVALID_DEVICE_REQUEST):
[MS-SMB2] 18.104.22.168 "Receiving an SMB2 CREATE Request" contained "Create Context Validation: The server SHOULD<247> fail any request having a create context not specified in section 22.214.171.124 with a STATUS_INVALID_PARAMETER error", where <247> contained "<247> Section 126.96.36.199: Windows Vista SP1, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, and Windows Server 2012 ignore create contexts having a NameLength greater than 4 and ignore create contexts with a length of 4 that are not specified in section 188.8.131.52."
Thus unknown contexts, according to [MS-SMB2] at the time, were ignored in Windows Vista, Windows 7, Windows 8, Server 2008, Server 2008 R2 and Server 2012 and failed unknown contexts in Windows 8.1, Windows 10, Server 2012 R2 and Server 2016.
This was incorrect.
[MS-SMB2] now says that "Create Context Validation: The server MUST fail create contexts having a NameLength less than 4 with a STATUS_INVALID_PARAMETER error." Otherwise, it should just ignore contexts that it doesn't recognize. This includes the 16-byte context name SVHDX_OPEN_DEVICE_CONTEXT "0x9CCBCF9E04C1E643980E158DA1F6EC83", if indeed the server doesn't support [MS-RSVD], and other non-Microsoft context names, like "AAPL" (a context name that Apple SMB2 clients emit).
The correct Samba server behavior would be to succeed the create response. I believe that if Samba did so, backup and other features will begin to work.
From: Uri Simchoni [mailto:uri at samba.org]
Sent: Tuesday, February 23, 2016 12:05 PM
To: Bryan Burgin <bburgin at microsoft.com>; Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: Windows 10 backup failing against Samba
Continuing the discussion from samba-technical.
We have a Windows 10 VM (details attached) failing to create a system image on a Samba 4.3.4 server share. We would like to understand the root cause so that a fix can be supplied.
1. Setup a stand-alone Samba-based file server as per https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwiki.samba.org%2findex.php%2fStandalone_server&data=01%7c01%7cbburgin%40microsoft.com%7cc347632a6b6e45e776d508d33c8c9418%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=dwkBNHkJMudMGeWVlAwEG7r7qTkW8Jga%2fFnqxgXjbb0%3d
(I basically used the Fedore FC23 build, with a minimal smb.conf as listed in the wiki, and an ext4 file system. had do disable selinux to avoid frustration. But it should behave the same on other builds)
2. On a Win10 machine, create a system image using wbadmin command line, as listed in attached cmd.txt session
After snapshot creation phase, the operation fails with "incorrect function" error message.
info.txt - basic details on the client OS cmd.txt - capture of the wbadmin command and output backup.pcap - packet capture of the SMB3 session
The packet capture shows an attempt to open the .vhdx with SVHDX_OPEN_DEVICE_CONTEXT, which returns this error.
If my reading of [MS-SMB2] is correct, then Samba is in compliance here, since it does not support shared VHDX.
It's not entirely clear how/whether the client is supposed to test for support of SVHDX - I'm waiting to get my hands on a Server
2012R2/2016TP4 to compare. In an SDC presentation from 2013 it says the existence of an alternate data stream is the test, I see no such test in the packet capture.
More information about the cifs-protocol