locked
Windows 10 version 1809 update network error 0x80070035 RRS feed

  • Question

  • Hello,
    My Windows 10 laptop was updated to version 1809.  After the update, I noticed I am unable to connect to my QNAP 219P NAS fileshares.
    I have another Windows 10 machine running version 1803 on the same network, which connects to the old network shares without error.
    In attempts to fix the connection, I have read various posts and tried:

    1. Enabling NetBIOS over TCP/IP
    2. Enabling network discovery
    3. Enabling the SMB v1 client
    4. Enabling SMB v3 on the QNAP via telnet
    5. Enabling insecure guest logons
    6. A complete reset of Windows 10 wiping all local data and settings

    All have made zero difference.

    Can you please help me identify what is required so I can access the NAS fileshares to backup my machine from Windows 10 version 1809? Given the NAS is now running SMB v3, ideally I don't want to make my client less secure to connect to the fileshares.

    Thank you

    Tuesday, May 7, 2019 8:15 PM

Answers

  • Hello goldendel,

    Yes, there is a very good chance that that is the problem. Just removing that dependency and starting the LanmanWorkstation could/should resolve the problem (no reboot needed):

    sc config LanmanWorkstation depend= Bowser/MRxSmb20/NSI
    sc start LanmanWorkstation

    Gary

    • Marked as answer by goldendel Tuesday, June 18, 2019 8:27 PM
    Tuesday, June 18, 2019 7:20 AM

All replies

  • Hello goldendel,

    Thank you for posting in this forum.

    I have encountered situations where the SMB protocol is only installed but not enabled. Please refer to the information in this link: How to detect, enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server to ensure that the SMB protocol is enabled.

    If the SMB protocol is indeed enabled, please reproduce your problem first, then go to this place (Event Viewer->Applications and Services Logs->Microsoft->Windows->SMBClient) to view the logs, which will give more detailed reasons for the access failure.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, May 8, 2019 3:23 AM
  • Hello,

    Please refer additional suggestions mentioned here:

    https://www.kapilarya.com/the-network-path-was-not-found-0x80070035-windows-10

    Let us know if this helps!

    Note: Included link in this reply refers to blog post by a trusted Microsoft MVP.


    Microsoft MVP (Windows and Devices for IT)

    Windows Insider MVP

    Windows Help & Support [www.kapilarya.com]

    Wednesday, May 8, 2019 4:35 AM
  • Hi HK.Leon,

    You were correct.  I ran sc.exe qc lanmanworkstation and SMB 1.0 was not enabled.  

    C:\WINDOWS\system32>sc.exe qc lanmanworkstation
    [SC] QueryServiceConfig SUCCESS

    SERVICE_NAME: lanmanworkstation
            TYPE               : 20  WIN32_SHARE_PROCESS
            START_TYPE         : 2   AUTO_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k NetworkService -p
            LOAD_ORDER_GROUP   : NetworkProvider
            TAG                : 0
            DISPLAY_NAME       : Workstation
            DEPENDENCIES       : Bowser
                               : MRxSmb20
                               : NSI
            SERVICE_START_NAME : NT AUTHORITY\NetworkService

    I have enabled it

    C:\WINDOWS\system32>sc.exe config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
    [SC] ChangeServiceConfig SUCCESS
    C:\WINDOWS\system32>sc.exe config mrxsmb10 start= auto
    [SC] ChangeServiceConfig SUCCESS
    C:\WINDOWS\system32>sc.exe qc lanmanworkstation
    [SC] QueryServiceConfig SUCCESS
    SERVICE_NAME: lanmanworkstation
            TYPE               : 20  WIN32_SHARE_PROCESS
            START_TYPE         : 2   AUTO_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k NetworkService -p
            LOAD_ORDER_GROUP   : NetworkProvider
            TAG                : 0
            DISPLAY_NAME       : Workstation
            DEPENDENCIES       : bowser
                               : mrxsmb10
                               : mrxsmb20
                               : nsi
            SERVICE_START_NAME : NT AUTHORITY\NetworkService
    C:\WINDOWS\system32>

    and rebooted.  I can see this has made a difference, as I'm now seeing devices under network, I could not see before.  However, I'm still unable to get to the NAS.

    This is the error I see in the worklog now (the error has changed from 0x80070035 to 0x80004005)

    Failed to establish a network connection.
    Error: {Device Timeout}
    The specified I/O operation on %hs was not completed before the time-out period expired.
    Server name: 192.168.0.2
    Server address: 192.168.0.2:445
    Instance name: \Device\LanmanRedirector
    Connection type: Wsk
    Guidance:
    This indicates a problem with the underlying network or transport, such as with TCP/IP, and not with SMB. A firewall that blocks TCP port 445, or TCP port 5445 when using an iWARP RDMA adapter, can also cause this issue.

    I have confirmed the QNAP is listening on TCP 445:

    [~] # netstat -an | grep 445
    tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN

    The other node on the network running WIndows 10 1803 which can access the QNAP is only enabled for SMB 2.0:

    C:\WINDOWS\system32>sc.exe qc lanmanworkstation
    [SC] QueryServiceConfig SUCCESS
    SERVICE_NAME: lanmanworkstation
            TYPE               : 20  WIN32_SHARE_PROCESS
            START_TYPE         : 2   AUTO_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : C:\WINDOWS\System32\svchost.exe -k NetworkService -p
            LOAD_ORDER_GROUP   : NetworkProvider
            TAG                : 0
            DISPLAY_NAME       : Workstation
            DEPENDENCIES       : Bowser
                               : MRxSmb20
                               : NSI
            SERVICE_START_NAME : NT AUTHORITY\NetworkService

    C:\WINDOWS\system32>

    There is a standard windows firewall rule on the affected machine allowing SMB out on 445. There is no other firewall installed.

    Thanks for your help,

    goldendel


    Wednesday, May 8, 2019 8:09 PM
  • Hi Kapil,

    I've followed the steps in your link including making the following changes to service status:

    DHCP Client Running, Automatic
    Homegroup Listener, Missing
    Homegroup Provider, Missing
    Net.Tcp Port Sharing Service Stopped & disabled.  Set to automatic and started
    Network Connections, stopped and manual.  Set to automatic and started
    Network List Service running and manual.  Set to automatic and started
    Network Location Awareness running and automatic
    TCP/IP NetBIOS Helper running and manual.  Set to automatic and started

    Followed by a reboot.  I have also temporarily disabled windows firewall. 

    I've refreshed the credentials under credential manager.  Network discovery is already enabled.  I think Homegroups are deprecated so there is no option for "Use user accounts and passwords to connect to other computers".  I have not removed the network adaptor on the assumption the entire Windows reset should have resolved any adaptor specific configuration.

    Unfortunately this has made no difference.  I still get the error posted above (The specified I/O operation on %hs was not completed before the time-out period expired.)

    I'm thinking it's time to upgrade my QNAP to one with more recent support for SMB  v3.

    Thanks for your help.

    goldendel

    Wednesday, May 8, 2019 8:40 PM
  • Hello goldendel,

    The operating system of the client that accesses the shared file is Windows 10, right?

    If so, I recommend using the corresponding method in the article.

    Of course, this is not very important.

    Use the Windows+R keyboard combination and enter "gpedit.msc" to enter Local Group Policy Editor. Go to Computer Configuration->Windows Settings->Security Settings->IP Security Policies on Local Computer, then check if there are any policies to limit the use of port 445.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, May 9, 2019 2:14 AM
  • Hi Leon,

    Yes, you're correct I should have used powershell. I think it's tried it previously and the command failed so I used SC.  I tried it again and it was successful via powerhsell but returned the same results.

    I've checked Computer Configuration->Windows Settings->Security Settings->IP Security Policies on Local Computer.  There is nothing defined at all.  I've also checked the user security settings and windows firewall.  The windows full reset was done on Monday, so any config would be default as part of the windows build.

    Thanks for our help,

    goldendel

    Thursday, May 9, 2019 7:41 PM
  • Hello goldendel,

    Can you disable SMB2/3 on your NAS?

    I have encountered such an error, it may be that the ISP blocked the 445 port of your computer. Try disabling SMB2/3 and you should be able to use SMB1 to get your computer to access the NAS.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, May 10, 2019 6:25 AM
  • Hi,

    Just checking the current situation of your problem.
    Please let us know if you would like further help.

    Best regards,
    Leon

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, May 14, 2019 7:35 AM
  • Hi Leon,

    Thanks for checking in.  The ISP is not in line between the laptop and the QNAP, so it could not be blocking access.  The QNAP is listening on 445 and another machine could get to it.

    The TS219P support for SMB3 was experimental and enabled via CLI.  I ordered a new QNAP to get something with clearer support for SMB3.  It arrived last night.  I followed the QNAP procedure and moved my disks from the old NAS into the new one. All of my data was intact but the problem persisted. I even downloaded the windows app "QFinder Pro" and that also could not find the QNAP (but the other Win 10 machine on the network was still fine).

    I tried the web console from the "broken" machine and this was also blocked. This got me thinking..The QNAP has the ability to auto block IPs based upon network access protection rules.  I had only ever seen external addresses be blocked.  However, I checked it and something had triggered two internal network addressed to be blocked including the "broken" PC.

    Removing those IPs immediately allowed access to the web console and to Qfinder Pro.  However, I could still not access fileshares.  I checked the SMB settings via PowerShell and SMBv1 was disabled, with SMB 2/3 enabled. SMB 2 and higher is enabled on the NAS.  I enabled SMB v1 on the "broken" machine, rebooted and it worked!

    SO, it seems that even with a NAS which only supports SMB 2 and higher, SMBv1 is still required on Windows 10 in order to be able to connect.  I checked the SMB v1 machine of the 1803 machine (which has always worked) and it is also enabled for V1.

    goldendel

    Tuesday, May 14, 2019 8:01 PM
  • The error I get accessing the NAS with SMB v1 disabled is:

    "NAS is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

    The network is not present or not started."

    There are no firewall rules blocking access to the NAS certainly not since disabling SMB v1.  I have removed the locally stored windows credentials and it makes no difference.  Re-enabling SMBv1 and rebooting fixes the problem.

    Given SMBv1 is disabled by default due to its insecurity, I would like to access the NAS with only SMB 2.1 and higher.

    Thanks for your help,

    goldendel

    Tuesday, May 14, 2019 8:24 PM
  • Hello goldendel,

    Thank you for your update.

    In fact, there are a lot of issues in this forum that are similar to yours. In the end, they all use SMBv1 to enable the client to successfully communicate with the NAS.

    Yes, using SMBv1 is not safe, but we have not found a better solution. So it is recommended that you use this as the current workaround.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    • Proposed as answer by HK.Leon Friday, June 7, 2019 8:07 AM
    Wednesday, May 15, 2019 2:42 AM
  • Thanks Leon. I agree enabling SMBv1 is the only way to make it work for the moment. 

    However, this is recent laptop running the latest Windows client OS.  The OS is a recent install and it's pretty much base image with only 1 app (VMware Workstation.  I am connecting to a brand new NAS which fully supports SMB v1,2,2.1 and 3.  Considering the well published vulnerabilities in SMBv1 and the fact that Microsoft are actively disabling SMB v1, Microsoft need to do more to ensure their customers can safely and securely connect using open standards to non Microsoft hosted file shares using their software.

    I understand you are not a Microsoft employee.  However, I hope Microsoft will read and respond to this feedback accordingly.

    Thanks very much for helping me identify that enabling the tick box in the windows feature list is insufficient to actually enable SMB v1!

    goldendel

    • Proposed as answer by HK.Leon Friday, June 7, 2019 8:07 AM
    Wednesday, May 15, 2019 7:15 PM
  • You're welcome, goldendel.

    I am pleased to know that the information is helpful to you.

    I will submit this issue to Microsoft. At the same time, you can also feedback this issue to Microsoft through the Feedback Hub.

    Send feedback to Microsoft with Feedback Hub

    And if there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, May 16, 2019 2:50 AM
  • Thanks Leon.  I've left feedback with Feedback Hub as you suggested. Thanks for the recommendation.

    Kind regards,

    goldendel

    Friday, May 17, 2019 6:23 PM
  • You are welcome, golddel.

    If there is anything else we can do for you, please feel free to post in the forum.

    Best Regards,

    Leon


    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, May 20, 2019 1:42 AM
  • Hi Momominta

    This is not a name resolution problem. I was attempting to access the share via IP address.

    The QNAP was pingable via name from the problem PC before editing the hosts file.  However, I have put it in there for kicks :)

    goldendel

    Saturday, May 25, 2019 11:48 AM
  • Hello goldendel,

    You could try tracing what is happening at a protocol level and inferring from the captured data what is actually causing the problem. A network trace with a tool like Microsoft Message Analyzer, Microsoft Network Monitor or Wireshark would be one way of doing this. Alternatively one could just capture data from the Microsoft Microsoft-Windows-SMBClient Event Tracing for Windows provider.

    The commands for the last option are:

    • logman start qnap -ets -p Microsoft-Windows-SMBClient -o qnap.etl
    • [reproduce the problem]
    • logman stop qnap -ets

    The output file (qnap.etl) can be viewed in Microsoft Message Analyzer. If necessary, you can share the qnap.etl file (via OneDrive or similar, with link posted here) so that people with some knowledge of the SMB protocol can analyse it.

    Gary

    Saturday, May 25, 2019 12:18 PM
  • Hi Gary, Thank you. That’s a useful suggestion. I’m away for a couple of weeks. I’ll take a trace when I’m back and share the results. goldendel
    Sunday, May 26, 2019 9:55 AM
  • Hi Momominta, Yes. This has been configured on the new QNAP (It’s actually the default). Cheers, Goldendel
    Sunday, May 26, 2019 9:58 AM
  • Hello goldendel,

    I wasn't sure who Momominta was addressing in the last message ("Hi Gary") - it could have been me since that link refers to SMB encryption (amongst other things). If encryption is enabled then straightforward network traces (Wireshark et al) are not so useful. The Microsoft-Windows-SMBClient trace provider is probably the best bet.

    Gary

    Sunday, May 26, 2019 10:05 AM
  • Hi Gary,

    I have disabled SMB 1 with Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol after running the command and prior to the required reboot, I could connect to the QNAP.

    I ran "qnap -ets -p Microsoft-Windows-SMBClient -o qnap.etl" as an admin tried to access the QNAP (which failed as expected) and stopped the trace with "logman stop qnap -ets"

    The resultant trace file is listed here.  I've had a look with Microsoft Message Analyzer.  The file can be read, so it's not encrypted.  I'm not familiar enough with tool or the protocol to diagnose the issue.  Hopefully someone on here can help.

    The error I get at the time is:

    [Window Title]
    Network Error
    [Main Instruction]
    Windows cannot access \\qnap\qdownload
    [Content]
    Check the spelling of the name. Otherwise, there might be a problem with your network. To try to identify and resolve network problems, click Diagnose.
    [^] Hide details  [Diagnose] [Cancel]

    [Expanded Information]
    Error code: 0x80004005
    Unspecified error

    There are no errors listed in Winevt\Logs\Microsoft-Windows-SmbClient for today.  However, there are a number of security errors in Winevt\Logs\Microsoft-Windows-SmbClient%4Security.evtx as recently as two days ago with the following details:

    Log Name:      Microsoft-Windows-SmbClient/Security
    Source:        Microsoft-Windows-SMBClient
    Date:          07/06/2019 23:10:23
    Event ID:      31017
    Task Category: None
    Level:         Error
    Keywords:      (128)
    User:          SYSTEM
    Computer:      DESKTOP-BVQIVHO
    Description:
    Rejected an insecure guest logon.

    User name:
    Server name: \192.168.0.2

    Guidance:
    This event indicates that the server attempted to log the user on as an unauthenticated guest and was denied by the client. Guest logons do not support standard security features such as signing and encryption. As a result, guest logons are vulnerable to man-in-the-middle attacks that can expose sensitive data on the network. Windows disables insecure guest logons by default. Microsoft does not recommend enabling insecure guest logons.
    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-SMBClient" Guid="{988c59c5-0a1c-45b6-a555-0c62276e327d}" />
        <EventID>31017</EventID>
        <Version>0</Version>
        <Level>2</Level>
        <Task>0</Task>
        <Opcode>0</Opcode>
        <Keywords>0x200000000000080</Keywords>
        <TimeCreated SystemTime="2019-06-07T22:10:23.725641600Z" />
        <EventRecordID>63</EventRecordID>
        <Correlation />
        <Execution ProcessID="4" ThreadID="14280" />
        <Channel>Microsoft-Windows-SmbClient/Security</Channel>
        <Computer>DESKTOP-BVQIVHO</Computer>
        <Security UserID="S-1-5-18" />
      </System>
      <EventData>
        <Data Name="UserNameLength">0</Data>
        <Data Name="UserName">
        </Data>
        <Data Name="ServerNameLength">12</Data>
        <Data Name="ServerName">\192.168.0.2</Data>
      </EventData>
    </Event>

    I also noticed before I went away the QNAP Network Access Protection was blocking this client IP as it was making more than 5 attempts to connect per minute.  I have adjusted the settings for SAMBA and the client IP has not been blocked since, so the windows client must have been making multiple successive attempts (I was not).

    If I re-enable SMB v1, I can access the QNAP, but given SMB 2, 2.1 and 3 are enabled, IMHO, I should not need to reduce the client security.

    Thanks to everyone for looking at this.

    goldendel

    Sunday, June 9, 2019 5:39 PM
  • Hello goldendel,

    I just made a trace from my PC when connecting to a file share on Mac OS X. This is what it looks like in Message Analyzer:

    It starts out recording some configurable values and then (after 5 seconds - the time between starting the trace and issuing the command to connect the share), the events that occur during a connection are reported.

    In the trace that you made available, the configurable values can be seen but no activity occurs after that. I can see that the trace recording ran for 35 seconds, and it is difficult to understand how a connection attempt (or indeed any other type of SMB activity) could have taken place within this time frame without being protocoled in the .etl file.

    Can I just please confirm that something like this happened:

    • The trace was started on a client PC.
    • On that same PC, an attempt was made to access a file share that failed.
    • The trace was stopped.

    Gary

    Sunday, June 9, 2019 8:37 PM
  • Hello goldendel,

    At this stage, I would suggest going back to my first suggestion of just capturing all network traffic, possibly using tools like Microsoft Message Analyzer, Microsoft Network Monitor or Wireshark if they are installed. If they are not installed then a command like "netsh trace start scenario=lan capture=yes tracefile=qnap.etl" can capture the data too (the trace can be stopped with the command "netsh trace stop").

    The advantage of the Microsoft-Windows-SMBClient approach is that it focuses on just SMB, but something else seems to be contributing to your problem, so we need to "widen the net" to catch the problem.

    Gary

    Monday, June 10, 2019 7:36 AM
  • Hi Gary,

    That is exactly what I reproduced in the trace. 

    I performed a full network trace as admin with netsh trace start scenario=lan capture=yes tracefile=qnap.etl".  It has errored with the following:

    Microsoft Windows [Version 10.0.17763.504]
    (c) 2018 Microsoft Corporation. All rights reserved.

    C:\>netsh trace start scenario=lan capture=yes tracefile=qnap.etl
    Trace configuration:
    -------------------------------------------------------------------
    Status:             Running
    Trace File:         qnap.etl
    Append:             Off
    Circular:           On
    Max Size:           250 MB
    Report:             Off

    C:\>netsh trace stop
    Merging traces ... done
    Generating data collection ... failed (error=0x80004005)
    File location = C:\qnap.etl
    Tracing session was successfully stopped.

    Here is the trace file.  I re-tried and got the same error.  The 2nd trace is here.

    It sits at "Generating data collection" for approx. 10 minutes before failing.  It think it is hitting a network timeout. 

    It's getting late here I'll try again soon with MMA if the trace is unreadable.

    Thanks for your help,

    goldendel



    • Edited by goldendel Tuesday, June 11, 2019 10:33 PM
    Tuesday, June 11, 2019 10:30 PM
  • Hello goldendel,

    The resulting trace was essentially empty. The behaviour of "netsh trace stop" always irritates me but normally works and unfortunately can't be externally controlled.

    If the user of "netsh trace" is an administrator, when "stop" is requested it runs the script %SystemRoot%\System32\gatherNetworkInfo.vbs, merges some additional data into the .etl file and bundles everything together in a cabinet (.cab) file. On my PC, this takes about 90 seconds.

    If the user of "netsh trace" is not an administrator, a network capture trace cannot be started (starting a network capture trace involves rebinding network adapters, requiring administrator rights).

    The same type of network capture (using the same kernel components) can be achieved using PowerShell. These three command start the trace:

    New-NetEventSession -LocalFilePath C:\qnap.etl -Name qnap
    Add-NetEventPacketCaptureProvider -TruncationLength 65535 -SessionName qnap
    Start-NetEventSession -Name qnap

    These two command stop the trace:

    Stop-NetEventSession -Name qnap
    Remove-NetEventSession

    Gary

    Wednesday, June 12, 2019 7:24 AM
  • Hi Gary,

    I've followed your steps.  No error in the trace this time.  It's not particularly big but I kept the actions to a minimum as before:

    1. Disable SMBv1 via powershell

    2. Restart

    3. Start trace

    4. Open window to SMB share

    5. Stop trace

    to minimise confusion from irrelevant events.

    Here is the new trace.

    Thanks for your help,

    Tim

    Wednesday, June 12, 2019 10:18 PM
  • Hello Tim,

    Thanks for your perseverance - we are slowly making progress.

    There are no SMB packets in the trace - not even an initial TCP connect request. There are however interactions between your client and the QNAP using SSDP (Simple Service Discovery Protocol), DLNA (Digital Living Network Alliance) and (most importantly) WebDAV.

    00:12:17.316064 192.168.0.21.49815 > 192.168.0.2.80: S win 64240 <MAXSEG 05-B4,NOP,WSCALE 08,NOP,NOP,SACKOK>
    00:12:17.317745 192.168.0.2.80 > 192.168.0.21.49815: S ack 1 win 29200 <MAXSEG 05-B4,NOP,NOP,SACKOK,NOP,WSCALE 07>
    00:12:17.317931 192.168.0.21.49815 > 192.168.0.2.80: . ack 1 win 513
    00:12:17.318171 192.168.0.21.49815 > 192.168.0.2.80: P 1:94(93) ack 1 win 513
    OPTIONS / HTTP/1.1
    Connection: Keep-Alive
    User-Agent: DavClnt
    translate: f
    Host: qnap
    
    00:12:17.319775 192.168.0.2.80 > 192.168.0.21.49815: . ack 94 win 229
    00:12:17.383149 192.168.0.2.80 > 192.168.0.21.49815: P 1:590(589) ack 94 win 229
    HTTP/1.1 200 OK
    Date: Wed, 12 Jun 2019 22:12:15 GMT
    Server: Apache
    X-Frame-Options: SAMEORIGIN
    Upgrade: h2
    Connection: Upgrade, Keep-Alive
    Vary: Accept-Encoding
    Keep-Alive: timeout=15, max=800
    Transfer-Encoding: chunked
    Content-Type: text/html; charset=UTF-8
    
    137
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml">
            <head>
    <meta http-equiv="expires" content="0">
    <script type='text/javascript'>
            location.href = 'http://qnap:8080/';
    </script>
            </head>
    </html>
    
    
    
    00:12:17.383152 192.168.0.2.80 > 192.168.0.21.49815: P 590:595(5) ack 94 win 229
    00:12:17.383303 192.168.0.21.49815 > 192.168.0.2.80: . ack 595 win 510
    00:12:17.383626 192.168.0.21.49815 > 192.168.0.2.80: R ack 595 win 0
    00:12:20.937545 192.168.0.21.49818 > 192.168.0.2.80: S win 64240 <MAXSEG 05-B4,NOP,WSCALE 08,NOP,NOP,SACKOK>
    00:12:20.939958 192.168.0.2.80 > 192.168.0.21.49818: S ack 1 win 29200 <MAXSEG 05-B4,NOP,NOP,SACKOK,NOP,WSCALE 07>
    00:12:20.940076 192.168.0.21.49818 > 192.168.0.2.80: . ack 1 win 513
    00:12:20.940239 192.168.0.21.49818 > 192.168.0.2.80: P 1:133(132) ack 1 win 513
    OPTIONS /qdownload HTTP/1.1
    Connection: Keep-Alive
    User-Agent: Microsoft-WebDAV-MiniRedir/10.0.17763
    translate: f
    Host: qnap
    
    00:12:20.942984 192.168.0.2.80 > 192.168.0.21.49818: . ack 133 win 237
    00:12:20.942985 192.168.0.2.80 > 192.168.0.21.49818: P 1:230(229) ack 133 win 237
    HTTP/1.1 200 OK
    Date: Wed, 12 Jun 2019 22:12:19 GMT
    Server: Apache
    X-Frame-Options: SAMEORIGIN
    Upgrade: h2
    Connection: Upgrade, Keep-Alive
    Allow: POST,OPTIONS,HEAD,GET
    Content-Length: 0
    Keep-Alive: timeout=15, max=800
    
    00:12:20.983347 192.168.0.21.49818 > 192.168.0.2.80: . ack 230 win 512
    00:12:21.001886 192.168.0.21.49819 > 192.168.0.2.80: S win 64240 <MAXSEG 05-B4,NOP,WSCALE 08,NOP,NOP,SACKOK>
    00:12:21.003736 192.168.0.2.80 > 192.168.0.21.49819: S ack 1 win 29200 <MAXSEG 05-B4,NOP,NOP,SACKOK,NOP,WSCALE 07>
    00:12:21.003801 192.168.0.21.49819 > 192.168.0.2.80: . ack 1 win 513
    00:12:21.003865 192.168.0.21.49819 > 192.168.0.2.80: P 1:163(162) ack 1 win 513
    PROPFIND /qdownload HTTP/1.1
    Connection: Keep-Alive
    User-Agent: Microsoft-WebDAV-MiniRedir/10.0.17763
    Depth: 0
    translate: f
    Content-Length: 0
    Host: qnap
    
    00:12:21.006953 192.168.0.2.80 > 192.168.0.21.49819: . ack 163 win 237
    00:12:21.006954 192.168.0.2.80 > 192.168.0.21.49819: P 1:506(505) ack 163 win 237
    HTTP/1.1 405 Method Not Allowed
    Date: Wed, 12 Jun 2019 22:12:19 GMT
    Server: Apache
    X-Frame-Options: SAMEORIGIN
    Allow: POST,OPTIONS,HEAD,GET
    Content-Length: 235
    Keep-Alive: timeout=15, max=800
    Connection: Keep-Alive
    Content-Type: text/html; charset=iso-8859-1
    
    <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
    <html><head>
    <title>405 Method Not Allowed</title>
    </head><body>
    <h1>Method Not Allowed</h1>
    <p>The requested method PROPFIND is not allowed for the URL /qdownload.</p>
    </body></html>
    

    This explains the error message that your are seeing.

    It seems as though when you disable SMB1, you are disabling the only SMB version that your client is willing to use (although I am now a bit confused about what exactly we can be certain about - I have scrolled backwards and forwards over the text of this thread several times, but it has not helped).

    My immediate idea is to verify whether you PC is currently in a position to use SMB 2/3 to communicate with any device - however now that we know WebDAV is being used, you might have your own ideas on how best to proceed.

    I would try this:

    logman start qnap -ets -p Microsoft-Windows-SMBClient -o qnap.etl

    net view /all \\somewindowssystem

    logman stop qnap -ets

    This is what I tried:

    C:\Users\Gary\Home\2019>logman start gary -ets -p Microsoft-Windows-SMBClient -o z6.etl
    The command completed successfully.
    
    C:\Users\Gary\Home\2019>net view /all \\grn
    System error 5 has occurred.

    Because "grn" is a standalone PC, my credentials were not valid - but that is OK for this test. Looking in the captured data, we should see something like this:

    Even though the Session Setup failed with invalid credentials, we can see the result of the SMB dialect negotiation. If no data is captured, we will know that SMB was not even attempted.

    In summary, do your best to make sure that SMB 2/3 is/are working, prove this as above and then try a similar test using the QNAP rather than a Windows PC.

    Gary

    Thursday, June 13, 2019 8:32 AM
  • Hello Gary,

    As requested I disabled SMBv1 via the normal powershell method and rebooted.  I then ran "Get-SmbServerConfiguration | Select EnableSMB2Protocol" as admin and got a true result.

    I then ran (as admin in Powershell):

    logman start qnap -ets -p Microsoft-Windows-SMBClient -o qnap.etl

    net view /all \\DESKTOP-MGEK8R\SMBTest

    At this point I received Error 53 "network path not found"

    I then ran:

    logman stop qnap -ets

    The resultant trace file is attached here. I then enabled SMBv1 via Powershell, rebooted and re-ran net view /all \\DESKTOP-MGEK8R\SMBTest At this point I got 

    System error 5 has occurred.

    Access is denied.

    The folder is shared out to "Everyone" including write access NTFS permissions.  I don't normally connect to these machines via P2P shares, so I can't say I've had this working previously. Disabling the windows firewall on the target and using IP address made no difference.

    Other than Get-SmbServerConfiguration | Select EnableSMB2Protocol how can I validate if SMB 2/3 is working on the client?

    I hope the trace helps shed more light!

    goldendel

    Thursday, June 13, 2019 8:18 PM
  • Hello goldendel,

    Sorry, I did not request that you disabled SMBv1 (again) - in fact I assumed (without stating it) that it would be enabled so that we could at least see some SMB dialect negotiation in the trace. The new trace is effectively "empty", just containing a report of some parameters of the SMB client.

    Each Windows PC can act as an SMB client and server. You are having a problem with the SMB client on your PC - the systems that we have been using as SMB servers are the QNAP and the other PC.

    There is a client counterpart to Get-SmbServerConfiguration, namely Get-SmbClientConfiguration.

    The second half of this long web page is titled "How to detect status, enable, and disable SMB protocols on the SMB Client": https://support.microsoft.com/en-us/help/2696547/detect-enable-disable-smbv1-smbv2-smbv3-in-windows-and-windows-server

    Please try to ensure that the documented methods of disabling SMB 2/3 have not been applied (verify by running "sc qc lanmanworkstation" and "sc queryex lanmanworkstation"), leave SMB 1 enabled and retry the trace of "net view /all \\DESKTOP-MGEK8R" (don't add a share name to the path).

    Gary



    Thursday, June 13, 2019 9:07 PM
  • Hello Gary,

    I'm sorry, that was my mistake. 

    I've re-run the trace.  The output is here.  I've also created this file showing the output of the powershell commands I ran (as admin) to validate SMBv1 is enabled, as is SMB2/3.  As you can see, when I tried to run Get-SmbClientConfiguration | Select EnableSMB2Protocol, I didn't get either a true or false response.  Running Get-SmbServerConfiguration | Select EnableSMB2Protocol returned true.

    I hope this helps.  Thanks for your guidance.

    goldendel

    Saturday, June 15, 2019 3:45 PM
  • Hello goldendel,

    I know that "name resolution" as a potential cause has already been discussed, but that was in relation to the QNAP. The latest test with the Windows PC looks like this:

    Error code 3221225662 is STATUS_BAD_NETWORK_PATH. Can you ping DESKTOP-MGEK8R?

    Get-SmbClientConfiguration | Select EnableSMB2Protocol produces no output because the information display by Get-SmbClientConfiguration is different from that produced by Get-SmbServerConfiguration and does not contain EnableSMB2Protocol.

    Since the test with DESKTOP-MGEK8R (or whatever it is called) failed early (before and SMB dialect negotiations took place), I still don't know if your PC is currently capable of using SMB 2/3.

    Gary

    Saturday, June 15, 2019 4:08 PM
  • Hi Gary,

    Thanks for responding so quickly.

    You're correct. Schoolboy error on my part.  I didn't have DESKTOP-MGEK8R in my hosts file as I generally don't access shares on that PC, it's mainly the QNAP.  I've added it to the hosts file and I can ping it now.  I re-ran the trace here.  Powershell output is here.

    The netview failed again with Access is denied.  Fingers crossed SMB negotiation took part this time.

    Thanks for your help.

    goldendel

    Saturday, June 15, 2019 5:42 PM
  • maybe the NAS Storage simply just stop working can you get it running on another computer could be you need to open the ip and ports through your firewall 
    Saturday, June 15, 2019 9:36 PM
  • Hello goldendel,

    Great!

    For the first time, we have proof that your client is capable of negotiating (in two stages) up to SMB 3.1.1.

    In the first round of negotiation, it offered a wide range of old SMB dialects:

    Can you now make the same type of trace with the QNAP? That is a trace of a command like "net view /all \\qnap" or "net view /all "\\ipaddressofqnap".

    If the command succeeds or fails with an error like "access denied", then the trace will show which SMB dialect can be negotiated between the PC and the QNAP.

    Gary

    Saturday, June 15, 2019 10:36 PM
  • Hi Gary,

    I'm glad we proved it's working. Here is the trace with the QNAP and here is the Powershell output.  As you can see the netview succeeds with the name but failed with the IP address?

    goldendel


    • Edited by goldendel Sunday, June 16, 2019 10:28 AM typo
    Sunday, June 16, 2019 9:14 AM
  • Hello RunningWindows10,

    The NAS is on the same network as the client.  There is no firewall in between (other than the windows firewall and I've previously ruled this out disabling it)  The NAS is available from another Windows 10 machine on the same network (which also had SMBv1 enabled but was running 1803 until last night, it's now 1903 and still working with only SMB v2 running)

    goldendel

    Sunday, June 16, 2019 9:23 AM
  • Hello goldendel,

    Now things start to get interesting. The QNAP supports the latest version of SMB (SMB 3.1.1), so we should be able to disable SMB 1, but let's take small steps to get there.

    The first connection attempt with \\QNAP succeeds because the credentials for qnap\admin are sent/used. Since you did not enter any credential information in the commands, then I would guess that you have used "Stored  Credentials" to simplify access to the QNAP.

    The second connection attempt is what is probably misleading you. A TCP connection to the QNAP is established and indeed an SMB connection is established too - but with different credentials this time (your Microsoft account). The QNAP is probably not able to verify these credentials, but rather than denying access it grants "guest" access:

    Due to the default settings in Windows 10 (https://support.microsoft.com/en-hk/help/4046019/guest-access-in-smb2-disabled-by-default-in-windows-10-and-windows-ser), your PC rejects this proposition.

    The really misleading part is that Windows reports this to the user as "System error 53 has occurred.", "The network path was not found."

    You should be able to verify this by using commands like:

    net use \\192.168.0.2 /user:qnap\admin *

    [enter password]

    net view /all \\192.168.0.2

    net use \\192.168.0.2 /delete

    Assuming that works, the next step to your desired destination would be to disable SMB 1. I would suggest first removing the feature (via PowerShell or the Control Panel "Programs and Features", and then retesting (before rebooting). If that works, one could then try rebooting and testing yet again.

    There appears to be no obstacle to achieving the set-up that you want, be we have to be on the look-out for small errors that might re-introduce confusion. The Stored Credentials is one possible source and the use of WebDAV as a fallback (I don't actually know how that could have happened) is another.

    Gary






    Sunday, June 16, 2019 2:41 PM
  • Hello Gary,

    You should be able to verify this by using commands like:

     net use \\192.168.0.2 /user:qnap\admin *
     [enter password]
     net view /all \\192.168.0.2
     net use \\192.168.0.2 /delete

    That all worked as you described. 

    I disabled SMB v1 via "Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol" and did not reboot. I checked it with "Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol" and it showed as disabled.  Access to the QNAP was still fine.  I rebooted and again we're back to error 0x80004005.

    net use \\192.168.0.2 /user:qnap\admin password is now failing with:

    System error 67 has occurred.
    The network name cannot be found.

    I do have stored credentials in place with the correct password.  How do I stop it using the microsoft account?  Should I delete stored credentials?

    Thanks for your help,

    goldendel

    Sunday, June 16, 2019 7:14 PM
  • Hello goldendel,

    Stored Credentials are just a time saving mechanism (rather than explicitly entering credentials) - if there is no shared "authentication service" between the client PC and QNAP (so that your local PC credentials are valid on the QNAP) then they are a good solution.

    I think that we will have to resort to the broad tracing of all traffic again:

    New-NetEventSession -LocalFilePath C:\qnap.etl -Name qnap
    Add-NetEventPacketCaptureProvider -TruncationLength 65535 -SessionName qnap
    Start-NetEventSession -Name qnap

    net use \\192.168.0.2 /user:qnap\admin <password>

    Stop-NetEventSession -Name qnap
    Remove-NetEventSession

    Looking back through the discussion, incorrect credentials and the QNAP acceptance of these as a guest login plus the possible use of WebDAV-like share path at some stage in your troubleshooting explains many things, but I currently have no hypothesis as to why removing SMB 1 should have any impact.

    Gary

    Sunday, June 16, 2019 7:46 PM
  • Hello Gary,

    The trace is here and the powershell output here.

    I hope this helps.

    Thanks very much for your help,

    goldendel

    Sunday, June 16, 2019 9:47 PM
  • Hello goldendel,

    That is disappointing; I guess however that you would not have been able to connect to the Windows 10 PC (DESKTOP-MGEK8R) because this problem does not seem to be related to the QNAP but rather to the health of the configuration of your PC.

    One Microsoft description of ERROR_BAD_NET_NAME (the error 67 that you are now seeing) is (with my bold emphasis):

    The network name cannot be found. This value is returned if the lpRemoteName member of the NETRESOURCE structure pointed to by the lpNetResource parameter specifies a resource that is not acceptable to any network resource provider, either because the resource name is empty, not valid, or because the named resource cannot be located.

    There was no SMB traffic (or indeed any other traffic to the QNAP) in the trace.

    Can you show us the output produced by this "reg query" command:

    >reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
        LanmanWorkstation    REG_DWORD    0x7d0
        RDPNP    REG_DWORD    0x3e8
        webclient    REG_DWORD    0xbb8

    The numeric values control the order in which the network providers are offered the chance to claim responsibility for a network path (RDP, SMB and WebDAV in the case above). If a provider does not recognize a network path, it returns ERROR_BAD_NET_NAME and the next provider is then given the chance.

    One way that I can get an ERROR_BAD_NET_NAME on my PC is to just use an unknown network path format. For example:

    >net use gary://nebbett
    System error 67 has occurred.

    The network name cannot be found.

    In addition to verifying that the SMB provider is registered, it would also be useful to verify that the LanmanWorkstation service is running.

    >sc queryex LanmanWorkstation
    SERVICE_NAME: LanmanWorkstation
            TYPE               : 30  WIN32
            STATE              : 4  RUNNING
                                    (STOPPABLE, PAUSABLE, IGNORES_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 3040
            FLAGS              :

    Gary

    Monday, June 17, 2019 12:40 PM
  • Hi Gary,

    Interesting.

    PS C:\> reg query HKLM\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NetworkProvider\ProviderOrder
        LanmanWorkstation    REG_DWORD    0x7d0
        RDPNP    REG_DWORD    0x3e8
        webclient    REG_DWORD    0xbb8

    Which looks exactly like what you posted.  However, I was surprised to see this:

    C:\WINDOWS\system32>sc queryex LanmanWorkstation

    SERVICE_NAME: LanmanWorkstation
            TYPE               : 20  WIN32_SHARE_PROCESS
            STATE              : 1  STOPPED
            WIN32_EXIT_CODE    : 1075  (0x433)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 0
            FLAGS              :

    When I attempt to start the workstation/LanmanWorkstation service via services.msc I get the following error:

    Looking at the dependencies tab, there are 3 dependencies.  I can see the Network Store Interface Service is running but the browser and SMB 2.0 MiniRedirector services are missing.

    I did a quick google on this and ironically, this seems to indicate the missing services relate to disabling SMBv1.

    goldendel

    Monday, June 17, 2019 8:57 PM
  • Hello goldendel,

    The LanmanWorkstation service is essential for the correct operation of Window's SMB client.

    How did you determine that the Browser and SMB 2.0 MiniRedirector "services are missing"? These two "system components" upon which LanmanWorkstation depends are not Windows "services" but rather (pseudo-) device drivers (actually "file system drivers"). That is why their icons in the image above differ from that of "services" like "Network Store Interface Service".

    >sc qc bowser
    [SC] QueryServiceConfig SUCCESS
    SERVICE_NAME: bowser
            TYPE               : 2  FILE_SYSTEM_DRIVER
            START_TYPE         : 3   DEMAND_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : system32\DRIVERS\bowser.sys
            LOAD_ORDER_GROUP   : Network
            TAG                : 5
            DISPLAY_NAME       : Browser
            DEPENDENCIES       :
            SERVICE_START_NAME :
    >sc queryex bowser
    SERVICE_NAME: bowser
            TYPE               : 2  FILE_SYSTEM_DRIVER
            STATE              : 4  RUNNING
                                    (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 0
            FLAGS              :

    >sc qc mrxsmb20
    [SC] QueryServiceConfig SUCCESS

    SERVICE_NAME: mrxsmb20
            TYPE               : 2  FILE_SYSTEM_DRIVER
            START_TYPE         : 3   DEMAND_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : system32\DRIVERS\mrxsmb20.sys
            LOAD_ORDER_GROUP   : Network
            TAG                : 7
            DISPLAY_NAME       : SMB 2.0 MiniRedirector
            DEPENDENCIES       : mrxsmb
            SERVICE_START_NAME :

    >sc queryex mrxsmb20

    SERVICE_NAME: mrxsmb20

            TYPE               : 2  FILE_SYSTEM_DRIVER
            STATE              : 4  RUNNING
                                    (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 0
            FLAGS              :

    Gary




    Monday, June 17, 2019 9:13 PM
  • Hi Gary,

    My mistake.  I meant they were missing from services.msc.  Running the commands you did I get the same output as you:

    C:\>sc qc bowser
    [SC] QueryServiceConfig SUCCESS
    SERVICE_NAME: bowser
            TYPE               : 2  FILE_SYSTEM_DRIVER
            START_TYPE         : 3   DEMAND_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : system32\DRIVERS\bowser.sys
            LOAD_ORDER_GROUP   : Network
            TAG                : 5
            DISPLAY_NAME       : Browser
            DEPENDENCIES       :
            SERVICE_START_NAME :
    C:\>sc queryex bowser
    SERVICE_NAME: bowser
            TYPE               : 2  FILE_SYSTEM_DRIVER
            STATE              : 4  RUNNING
                                    (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 0
            FLAGS              :
    C:\>sc qc mrxsmb20
    [SC] QueryServiceConfig SUCCESS
    SERVICE_NAME: mrxsmb20
            TYPE               : 2  FILE_SYSTEM_DRIVER
            START_TYPE         : 3   DEMAND_START
            ERROR_CONTROL      : 1   NORMAL
            BINARY_PATH_NAME   : system32\DRIVERS\mrxsmb20.sys
            LOAD_ORDER_GROUP   : Network
            TAG                : 7
            DISPLAY_NAME       : SMB 2.0 MiniRedirector
            DEPENDENCIES       : mrxsmb
            SERVICE_START_NAME :
    C:\>sc queryex mrxsmb20
    SERVICE_NAME: mrxsmb20
            TYPE               : 2  FILE_SYSTEM_DRIVER
            STATE              : 4  RUNNING
                                    (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
            WIN32_EXIT_CODE    : 0  (0x0)
            SERVICE_EXIT_CODE  : 0  (0x0)
            CHECKPOINT         : 0x0
            WAIT_HINT          : 0x0
            PID                : 0
            FLAGS              :

    C:\>

    I had a look at this TN article relating to the startup error I am getting and checked the values in Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\

    DependOnService key.  I have the following:

    bowser
    mrxsmb10
    mrxsmb20
    nsi

    Do you think the presence of mrxsmb10 as a dependency is the reason the LanmanWorkstation service is failing to start?

    goldendel

    Monday, June 17, 2019 11:24 PM
  • Hello goldendel,

    Yes, there is a very good chance that that is the problem. Just removing that dependency and starting the LanmanWorkstation could/should resolve the problem (no reboot needed):

    sc config LanmanWorkstation depend= Bowser/MRxSmb20/NSI
    sc start LanmanWorkstation

    Gary

    • Marked as answer by goldendel Tuesday, June 18, 2019 8:27 PM
    Tuesday, June 18, 2019 7:20 AM
  • Hello Gary,

    Success!!!!

    Thank you so much for persisting with the traces.

    I have two remaining questions (more for Microsoft than yourself).

    1. With the numerous times I have disabled SMBv1 via powershell or windows features, why is this dependency not also removed?

    2. Why did flaw persist between windows resets?  Is this feature not really a full windows rebuild?  If it's not, how does Microsoft make this available now licence keys are tied to hardware?

    Thanks again and also to HK.Leon

    goldendel

    Tuesday, June 18, 2019 8:27 PM
  • Hello goldendel,

    I thought that I would take this opportunity to say goodbye and conjecture about your first question, since I had given it some thought when trying to understand the "big picture" (the whole environment/circumstances which led to this problem).

    One hypothesis is that some very early troubleshooting that you performed led to a dependency of LanmanWorkstation on MRxSmb10 (without it being necessarily being installed). When the feature update to add SMB 1.0/CIFS occurred, the update process noted that it did not need to add a dependency on MRxSmb10 and, consequently, would not remove it should the SMB 1.0/CIFS feature be uninstalled. Regardless of how often you went through the add/remove feature cycle, this misapprehension remained.

    Anyway, good night (here anyway - judging from the times of your posts, I guessed that you were in New Zealand!) and good bye.

    Gary

    Tuesday, June 18, 2019 8:53 PM