none
Windows 10 1903 - Cannot connect to SMB share RRS feed

  • Question

  • I have been testing feature update 1903 for windows 10 in our environment and I am encountering an issue I cannot find a solution for.

    We currently use SMB shares for drive mapping to user/department shares and in 1903 we cannot connect to the production smb shares. However, we are able to connect to every other SMB share in our environment. When I look into the Event viewer I see the following:

    The server failed the negotiate request.

    Error: An invalid parameter was passed to a service or function.

    Server name: \coloemcnas1

    Guidance:
    The server does not support any dialect that the client is trying to negotiate, such as the client has SMB2/SMB3 disabled and the server has SMB1 disabled.

    This device is using the exact same settings as our developer NAS which 1903 can connect to without issue. Also, every version of windows 10 before 1903 is able to connect to the shares without issue.

    I have ensured that SMBv1 is enabled as well. Any help would be appreciated.

    Here is an output of Get-SmbClientConfiguration:

    PS C:\WINDOWS\system32> Get-SmbClientConfiguration


    ConnectionCountPerRssNetworkInterface : 4
    DirectoryCacheEntriesMax              : 16
    DirectoryCacheEntrySizeMax            : 65536
    DirectoryCacheLifetime                : 10
    DormantFileLimit                      : 1023
    EnableBandwidthThrottling             : True
    EnableByteRangeLockingOnReadOnlyFiles : True
    EnableInsecureGuestLogons             : True
    EnableLargeMtu                        : True
    EnableLoadBalanceScaleOut             : True
    EnableMultiChannel                    : True
    EnableSecuritySignature               : True
    ExtendedSessionTimeout                : 1000
    FileInfoCacheEntriesMax               : 64
    FileInfoCacheLifetime                 : 10
    FileNotFoundCacheEntriesMax           : 128
    FileNotFoundCacheLifetime             : 5
    KeepConn                              : 600
    MaxCmds                               : 50
    MaximumConnectionCountPerServer       : 32
    OplocksDisabled                       : False
    RequireSecuritySignature              : False
    SessionTimeout                        : 60
    UseOpportunisticLocking               : True
    WindowSizeThreshold                   : 8


    • Edited by Josh Catt Friday, June 7, 2019 3:40 PM
    Friday, June 7, 2019 3:33 PM

Answers

  • Turns out the issue was with our EMC Unity 300 device(The NAS).

    FROM EMC SUPPORT:

    It looks like you've been affected by the DTA.

    Please take a look at this KB articles for the details and let me know if you are using SMB 3.1.1

    Dell EMC Unity: Windows users may be unable to access Common Internet File System (CIFS) shares when Server Message Block (SMB) 3.1.1 is running which may result in potential data unavailability KB534173




    • Marked as answer by Josh Catt Thursday, June 13, 2019 8:32 PM
    • Edited by Josh Catt Thursday, June 13, 2019 9:31 PM
    Thursday, June 13, 2019 8:32 PM

All replies

  • Hello Josh,

    Whenever I see a question like this, where something seemingly odd is happening, I think that one approach is to examine what is happening at a deeper level. One could use Event Tracing for Windows to get a bit more insight into which dialects are being offered and general progress of an SMB connection by using the Microsoft-Windows-SMBClient provider on the client.

    One can start such a trace with a command like "logman start -ets SMB-Diag -p Microsoft-Windows-SMBClient -o SMB-Diag.etl"; then reproduce the problem and stop the trace with "logman stop -ets SMB-Diag".

    The (binary) trace data can be viewed in Microsoft's Message Analyzer. You can make the data available via OneDrive, Google Drive, etc. if you need help with the interpretation.

    It would probably be helpful to make a similar trace from an older Windows version where the connection works so see which SMB dialect was successfully negotiated.

    Your post is only about 20 minutes old as I write this, so it also might be worth waiting to see if any other ideas turn up...

    Gary


    Friday, June 7, 2019 4:02 PM
  • Thanks for the help so far. I have been digging through the Detailed diagnostic data and am not sure exactly where to go with it. I have uploaded the data to the following location.

    https://drive.google.com/drive/folders/1WS9Am2-MEkWtOdYm8k-jF99CCPWq4cxa?usp=sharing

    Seems like it is SMB2 related. I can see a lot of STATUS_INVALID_PARAMETER in the logs but I don't quite have the technical prowess to figure out what my next steps should be.


    • Edited by Josh Catt Friday, June 7, 2019 4:52 PM
    Friday, June 7, 2019 4:37 PM
  • Hello Josh,

    Thanks for that quick feedback - this looks very interesting for a "protocol freak" like me :-)

    In the fail case, I see this:

    The client offers 3 dialects ("NT LM 0.12", "SMB 2.002", "SMB 2.???"), one of which indicates that even newer dialects are available. The server responds:

    This indicates server interest in the newest protocols. The client then offers the following newer dialects (2.00, 2.10, 3.0, 3.02, 3.11):

    The server responds with an error message:

    Not much information there apart from the "STATUS_INVALID_PARAMETER" error code (not visible in the screen snapshot).

    The trace of a good connection now becomes important. Unfortunately, in the trace of the "good" behaviour that you made, the connection had already been established. Could you please try the "good" trace again, this time taking efforts to ensure that any existing SMB connections to the server have been deleted?

    For example, first issue the command "net use":

    C:\Users\Gary\Home\2019>net use
    New connections will be remembered.

    Status       Local     Remote                    Network
    -------------------------------------------------------------------------------
    OK                     \\chbsgrn02081961\IPC$    Microsoft Windows Network
    The command completed successfully.

    Then issue a command like "net use /d \\chbsgrn02081961" until all connections to the target server have been removed. Then restart the trace and perform the SMB connect again.

    Gary



    Friday, June 7, 2019 6:18 PM
  • Wow. This is great! net use shows "There are no entries on this list" on the good box. I made a point to disconnect the mapped network drives as well.

    I then performed a new trace and uploaded it to the share as SMB-Good2.etl https://drive.google.com/drive/folders/1WS9Am2-MEkWtOdYm8k-jF99CCPWq4cxa?usp=sharing

    Hopefully that provides the information you need. Thanks so much for all your help.


    • Edited by Josh Catt Friday, June 7, 2019 8:28 PM
    Friday, June 7, 2019 8:07 PM
  • Hello Josh,

    Thanks for that. The requests where the "good" and "bad" paths begin to diverge is here:

    Good

    Here there are two items in the Negotiate Context list: integrity and encryption capabilities.

    Bad

    Here there are four items in the Negotiate Context list: integrity and encryption capabilities and two that Message Analyzer does not know how to decode (ContextTypes 3 and 5).

    This is rather odd because the newest version of the SMB specification from Microsoft from 13th March 2019 documents ContextTypes 1, 2, 4 and 5:

    It may be this difference that causes the NAS to fail the negotiation. I am also curious to find out what ContextType 3 is used for.

    It's getting late here now, but you seem to have a genuinely interesting interoperability problem. It is not yet clear to me what we can reasonably do to work around this problem (without trying to force an older version of the protocol to be negotiated).

    Gary

    Friday, June 7, 2019 8:52 PM
  • That has been super informative. Thanks again for all your help. This isn't super urgent, since I can defer 1903 updates, but I really do appreciate your assistance in this issue.
    Friday, June 7, 2019 9:21 PM
  • Hello Josh,

    Just a minor update: Microsoft published an errata list for that document which explains the odd ContextType number:

    I will check if anything can be done to suppress these new ContextTypes.

    Are any logging or error reports available from your NAS? If so, it would be reassuring to try to reconcile them with the hypothesis that the Negotiate Context list is the cause of the problem.

    Gary

    Friday, June 7, 2019 9:45 PM
  • Hello Josh,

    It was rather premature of me to say that I would check to see if anything can be done to suppress the new context types - I later remembered that I don't have 1903 yet (Microsoft has not yet deigned to offer the update to my PC). However, having read the SMB specification more closely, I very much doubt that it will be possible to do this.

    Although it is an update to Windows that triggers this problem, the "blame/fault" probably lies with the NAS device - it should probably ignore syntactically correct negotiate context types that it does not recognize. This is not explicitly stated in the relevant section of [MS-SMB2] (3.3.5.4 Receiving an SMB2 NEGOTIATE Request), but I think that it is implied.

    Can you check if there are any version differences (even minor) between your production and developer NAS devices?

    It was my mistake to say that there was no connect attempt in your first "good" trace - it was there, but just not at the start of the trace. However, some key events were missing from that trace - 32 events were lost because the events were generated too quickly and not enough buffering was used. The second "good" trace lost just one event (not at a critical moment). I don't think that we need to do any further tracing, but as a FYI, the amount of trace buffering can be controlled with additional arguments to logman:

      -bs <value>                   Event Trace Session buffer size in kb.
      -nb <min max>                 Number of Event Trace Session buffers.

    Gary

    Saturday, June 8, 2019 8:29 AM
  • Hi Gary,

    I have our storage guy looking into the NAS side of things currently. I have a feeling it is an issue with the NAS more than windows.

    Monday, June 10, 2019 4:08 PM
  • Hi Josh

    We had the same issue after upgrading to 1903. To solve it, we set the following registry-key:

    Registry Hive HKEY_LOCAL_MACHINE
    Registry Path Software\Policies\Microsoft\Windows\LanmanWorkstation
    Value Name AllowInsecureGuestAuth
    Value Type REG_DWORD
    Enabled Value 1

    We had the problem also earlier with other windows-versions and found the solution here (in german!):

    https://winxperts4all.at/index.php/betriebssysteme/windows-10/1808-unsichere-gastanmeldungen-aktivieren-in-windows-10

    Hope, it works also for you.

    Regards

    Stephan

    Thursday, June 13, 2019 10:14 AM
  • We have the same issue at a customer. But I think allowing secure guest access should not be the solution. Perhaps a workaround until we get a patch for Windows or the NAS manufacturer. 

    Cheers,

    Thomas Kurth
    baseVISION AG
    Twitter: | LinkedIn: | Xing:
    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.


    Thursday, June 13, 2019 12:48 PM
  • Turns out the issue was with our EMC Unity 300 device(The NAS).

    FROM EMC SUPPORT:

    It looks like you've been affected by the DTA.

    Please take a look at this KB articles for the details and let me know if you are using SMB 3.1.1

    Dell EMC Unity: Windows users may be unable to access Common Internet File System (CIFS) shares when Server Message Block (SMB) 3.1.1 is running which may result in potential data unavailability KB534173




    • Marked as answer by Josh Catt Thursday, June 13, 2019 8:32 PM
    • Edited by Josh Catt Thursday, June 13, 2019 9:31 PM
    Thursday, June 13, 2019 8:32 PM
  • Perfect also in my case it's an EMC NAS. Will check that with the storage team.

    Cheers,

    Thomas Kurth

    Thursday, June 13, 2019 8:36 PM
  • We're seeing this as well with our Compellent filers. It looks like this is a general issue with Dell/EMC SMB implementations. It also appears to have been a known issue for some time. More details here:

    https://techcommunity.microsoft.com/t5/Windows-Insider-Program/W10-1903-UNC-path-failing-0x80070043/td-p/382540

    In short, the workaround is to turn SMB3 off at the filer, and force it to use SMB2.

    Friday, June 14, 2019 8:53 AM
  • We are having what appears to be a variant of this exact problem - except all (okay, most of) our Dell machines are running Window 10.

    Short version:  Had a power failure two weeks back, which caused some problems getting everything back up and all the shares seeing each other.  Finally, EVERYTHING is working on the LAN *except* one single Windows 10 machine.  [Call it machine XXX.]  It can see and access all other machines and shares but one.  [Call that one YYY.]  All other machines can see and access ALL other machines, including the one with a problem.  

    Machine YYY shows up in the Network list for XXX, but access produces our classic "Windows cannot access \\YYY" and 0x80070035.

    Now, here's the interesting part:  Every other machine (including YYY) is running Windows 10 Pro 1803.  XXX alone is running Windows 10 Pro 1903 (18362.175).  [All Dell machines, FWIW.]  I don't see how this could be ascribed to Dell.  

    Next up, try to limit to SMB 3.0.2 and see if that has a benefit.  

    Wednesday, June 19, 2019 3:35 PM
  • Hmmm. My test machine did not have the problem, but in production, an actual user's (identical) workstation did.   So I was stuck with some users having upgraded and unable to connect to the Unity, and other users who hadn't upgraded yet but with open files. 

    YMMV but I found a less intrusive workaround to the problem, based on DTA 534173.   After issuing the svc_nas -param command it is not necessary to issue a svc_nas -restart. (I confirmed this with Dell EMC).  Simply reseat the network cable of the workstation experiencing the problem. 

    The only point of svc_nas -restart is to force connections closed and make the endpoints renegotiate an SMB connection.  But it also restarts the NAS server, which might disrupt already-connected users.   Reseating one workstation's cable forces that workstation to renegotiate new SMB connections to the Unity anyway. Dell EMC also told me that sometimes Windows can renegotiate the SMB dialect automatically (but I haven't experienced that).


    Tuesday, June 25, 2019 3:58 PM
  • Hi,

    Just to post, in case others find this thread.  Whilst my experience isn't identical, it's very similar.

    My trace from the client side showed an SMB rather than SMB2 block - which ends in failure, as my server only offers SMB3.1.1.

    I couldn't see why the one client PC out of all those here would have this issue.  Of course, none of the suggested "fixes" to similar issues applied.  What made it so much more frustrating is that prior to 1803 things had been fine.  With 1803 and subsequent upgrades, the likelihood of connection slowly decreased.  1809 was a non-starter and, unsurprisingly, so was 1903.  So the machine had been on 1803 and I was needing to get a resolution soon.

    Now, this should have been one of the first things I tried.  I don't know why it wasn't - possibly because none of the articles I've read have mentioned it, which is why I'm posting.

    I delete all the device share mappings on the client, checking that they were not visible at user or administrator level.  Once done, I remapped them, ensuring /requireintegrity was on (that might be a clue but I'm not sure).  Rebooting 1803 showed the drives connect instantly (which they generally didn't do).  That was hopeful.  They worked again on another reboot - which was almost unheard of in the last few weeks.  So I decided to go for it and upgrade to 1903.

    So far, not a problem.  (Apart from I'm kicking myself for not trying it earlier.)

    -- Peter

    Sunday, September 1, 2019 1:05 PM