Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, December 16, 2019 8:07 PM
Just as the title states, we cannot access network shares in Windows 10 1909 after updating from 1803/1809. The issue seems to persist over a range of troubleshooting techniques. What I have tried:
- Allowed sharing to everyone on network
- Changed adapter settings to force IPv4
- Changed Host files to point them at the file sharing servers
- Removing from Domain and adding back
- Deleting Regedit (we use Group Policy logon scripts) entry for mount points
I know this was an issue that was resolved in 1809 but it seems to be reoccurring in 1909. Any help would be appreciated.
Edit: Some additional information that might be important. The file share is hosted in a Windows 2012 R2 environment. I can get to the root of the file share e.g. \fileshare.corp\Files\ITFiles but cannot get into a folder in that file share.
All replies (8)
Tuesday, December 17, 2019 1:12 AM
Plenty of suggestions sited here:
S.Sengupta,Microsoft MVP Windows and Devices for IT, Windows Insider MVP
Tuesday, December 17, 2019 6:24 AM
Hi ,
Is there any error message when you cannot access network share? Please post the error message for us to troubleshooting.
In addition,please temporarily re-enable the SMBv1 protocol on Windows 10 to do a test.
1.Open Control Panel > Programs & Features > Turn Windows features on or off.
2.Expand the SMB 1.0/CIFS File Sharing Support option.
3.Check the SMB 1.0/CIFS Client option.
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Tuesday, December 17, 2019 2:45 PM
Thank you for your help, sadly none of those worked.
Troubleshooting 1:
Open Start > Settings > Network & Internet > Status
Scroll to the bottom
Click Network and Sharing Center
Click Change advanced sharing settings
Expand All Networks
Under Password protected sharing
Switch between 'Turn on password protected sharing and Turn off password protected sharing'
Then choose 'Turn off password protected sharing'
Then click 'Save changes'
No noticeable change
Troubleshooting 2:
Press Windows key + R
Type: optionalfeatures.exe
Hit Enter
Scroll down to SMB 1.0/CIFS File Sharing Support
Tick the SMB 1.0/CIFS Client
Untick SMB 1.0/CIFS Automatic Removal and
Untick SMB 1.0/CIFS Server
No noticeable change
Troubleshooting 3:
Additional troubleshooting steps you can attempt:
- shut all computer and network gear down.
- Turn off IPv6
- Try browsing to some of the computers manually, press Windows key + R, type: \computername, hit Enter
- Press Windows key + R
Type: services.msc
Hit Enter
Other things you can do:
Press the Windows Key and R at the same time to bring up the Run dialog.
Type services.msc in the Run dialog and press Enter.
For each of the following services, locate the service in list, right-click the service and select Properties. Then set the Startup type to Automatic (Delayed Start) and select Apply.
Computer Browser (Browser)
Function Discovery Provider Host (FDPHost)
Function Discovery Resource Publication (FDResPub)
Network Connections (NetMan)
UPnP Device Host (UPnPHost)
Peer Name Resolution Protocol (PNRPSvc)
Peer Networking Grouping (P2PSvc)
Peer Networking Identity Manager (P2PIMSvc)
Restart Windows.
No noticeable change
Troubleshooting 4:
Press Windows key + X > computer management-->shared folders--> choose the shared folder, right click it then click Properties > Share Permissions -->protection that everyone can read and execute, see folder contents and read permissions.
Add the machine to your Windows HOSTS file.
No noticeable change
Tuesday, December 17, 2019 2:49 PM
Candy,
I have a new account to so I can't post images. Also, I tried your troubleshooting above and that was not successful.
Error I am getting in text format:
"An error occured while reconnecting to T: to \domainname.com\FileShare\FileShare2\FileFolder
Microsoft Windows Network: The network location cannot be reached. For information about network troubleshooting, see Windows help.
The connection has not been restored."
However, I can access everything just fine from an older version of Windows 10.
Thanks for your help.
Tuesday, December 17, 2019 3:59 PM
Hello coopitsp,
One could create an ETW trace of the Microsoft-Windows-SMBClient on the client and share the trace data here (putting the data on OneDrive, Google Drive, etc. and posting a link). This would help understand what is going wrong and perhaps suggest a remedy.
The trace data would include information that you might wish to keep confidential (perhaps such as the real value of "domainname.com"), so this might rule out this course of action.
The command to start a trace is "logman start X -ets -p Microsoft-Windows-SMBClient -o X.etl" and "logman stop X -ets" stops the trace (after the problem has been reproduced). "X" is a placeholder for a name (session name and file name).
Gary
Wednesday, December 18, 2019 2:52 PM
Gary,
I sterilized the info pertaining to the company and here is the file:
https://1drv.ms/u/s!ArD5RvTc5urI6n-pxPpi2DywaGan?e=PjkszJ
Please let me know if you need anything else and thank you for your help. The link expires in a few days.
Wednesday, December 18, 2019 5:42 PM
Hello coopitsp,
That sterilization process really butchered the trace data, making it unusable for tools like Microsoft Message Analyzer to process the data. There is no need to perform that sterilization process again - better to make no data available.
I made a few simplifying assumptions to help me understand what is happening:
- This is a DFS set-up.
- The problem folder is located on a non-Windows SMB server.
You can perhaps let us know whether that is correct.
What seems to be happening is that the Windows 10 clients are sending newly defined items (compression capabilities and netname negotiate context id) in the "negotiate context list" to the SMB server and, rather than ignoring the unknown items as it should, the server fails the request with error code 0xC000000D (STATUS_INVALID_PARAMETER); old Windows SMB server implementations correctly ignore unknown items (that is why I think that we are dealing with a non-Windows SMB server).
If this is a non-Windows SMB server, the manufacture will probably already be well aware of this problem and have a fix available.
As an interim workaround, there are ways of exerting fine control over the SMB dialect so that one can continue to use SMB2/3, but just not the very newest version.
Gary
Tuesday, December 24, 2019 2:09 AM
Hi ,
Just want to confirm the current situations.
Please feel free to let us know if you need further assistance.
Best Regards,
Candy
Please remember to mark the replies as an answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected]