Windows 10: Windows 10 file share access to Server 2012-2019 fails with Access Violation.

bobmerritt1 · Feb 2, 2021

I have read many of the postings on Win10 and issues with file shares. My issues are as follows:

I have Server 2012/2012R2 and 2019 2019 being evaluated

Non-Domain

Local User account setup: UserTest tested as local user and administrator levels

Shared a test folder on each system

Wins is running on the server and all test systems have Wins pointed correctly.

When I try to access a share from Win10

In File Explorer, I expand Network

Servers are present/listed

When I click on one of the server names, I am prompted to login.

I try login with server1\UserTest and password

I try login with server1\administrator and password

All login test fail with Access Denied

From the 2012R2 server, I can see all of the shares on the 2019 server.

I can click on one of the 2019 test shares and when prompted for username/password, I enter the same information as under the Win10 testing. It works.

From 2019 to 2012R2, the same results as from the 2012 server.

I cannot find any issues with the basic server side accounts or file share definitions. I used the Server Manager-File and Storage Service-Shares to define shares.

Windows Defender/Firewall has Advanced Sharing setting enabled.

Both 2012 and 2019 will not allow enabling Network discovery. I can click the button but upon saving, Discovery is turned off.

The 2012R2/2019 server is replacing an EOL NAS which has worked well for many years. Win10 access file shares on the NAS Qnap just fine. I do intend to install Hyper-V to run a couple of other apps. I did have Hyper-V installed early on in the testing, but with installed with no VMS the server did not appear in the Win10 Network listing. Once I removed Hyper-V, the server appears but cannot be access - Access Denied issue above.

Server 2012R2 is a Standard with GUI. 2019 is Standard with GUI.

You input is appreciated.

Bob

:)

Todd Brown (todd.brown) · Feb 2, 2021

Windows 10 File Shares not accessible from Server 2012

Configuration

Servers:

Location 1

SCCM-Central1-loc1

2012 R2

10.70.4.228/24

Location 2

SCCM-DP1-loc2

Windows 10 Build 1803

172.22.65.4/24

No Symantec Endpoint Protection

FILESERVER-FS1-loc2

2012 R2

172.22.65.231/24

Location 3

SCCM-DP2-loc3

Windows 10 Build 1803

172.22.186.4/24

Symantec Endpoint Protection

Location 4

SCCM-DP3-loc4 (Tega)

Windows 10 Build 1803

172.22.207.4

Symantec Endpoint Protection

Citrix Receiver

Location 5

SCCM-DP4-loc5 (PTZA)

Windows 10 Build 1803

172.22.185.4

Symantec Endpoint Protection

Citrix Receiver

We need to be able to attach to the f$ share on each of the “SCCM-DPx-LOCx” servers from the “SCCM-Central1-loc1”.

Issue Attempting to connect to

\\172.22.65.4\f$

\\ SCCM-DP1-loc2\f$

\\ SCCM-DP1-loc2.DOMAIN.com\f$

\\10.120.186.4\f$

\\ SCCM-DP2-loc3\f$

\\ SCCM-DP2-loc3. DOMAIN.com\f$

Fails from SCCM-Central1-loc1 or any Windows 2012 R2 server outside of the 172.22.65.0/24 subnet.

Error:

Windows cannot access \\ SCCM-DP1-loc2\f$

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.

See Details shows

Error Code: 0x80004005

Unspecified error

Works from any Windows 10 workstation even across the VPN. Also works from a Server 2012 R2 server in the 172.22.65.0/24 subnet

Works Attempting to connect to

\\172.22.65.231\f$

\\ FILESERVER-FS1-loc2\f$

\\ FILESERVER-FS1-loc2.DOMAIN.com\f$

\\ 172.22.207.4\f$

\\ SCCM-DP3-loc4\f$

\\ SCCM-DP3-loc4. DOMAIN.com\f$

\\ 172.22.185.4\f$

\\ SCCM-DP3-loc5\f$

\\ SCCM-DP3-loc5. DOMAIN.com\f$

Works from all locations and all machines

Notes:

Connecting from any Windows 10 machine to the failing systems works every time (see above).

Connecting to a Windows 2012 R2 server in the same subnet as one of the failing systems works every time.

Auditing of ports from any location to the systems in this subnet renders the same result:

Test-NetConnection -port 138 -ComputerName "FILESERVER-FS1-loc2" -InformationLevel "Detailed"

WARNING: TCP connect to FILESERVER-FS1-loc2:138 failed

ComputerName : FILESERVER-FS1-loc2

RemoteAddress : 172.22.65.231

RemotePort : 138

AllNameResolutionResults : 172.22.65.231

MatchingIPsecRules :

NetworkIsolationContext : Private Network

IsAdmin : False

InterfaceAlias : Ethernet

SourceAddress : 10.70.4.228

NetRoute (NextHop) : 10.70.4.1

PingSucceeded : True

PingReplyDetails (RTT) : 39 ms

TcpTestSucceeded : False

Test-NetConnection -port 137 -ComputerName "FILESERVER-FS1-loc2" -InformationLevel "Detailed"

WARNING: TCP connect to FILESERVER-FS1-loc2:137 failed

ComputerName : FILESERVER-FS1-loc2

RemoteAddress : 172.22.65.231

RemotePort : 137

AllNameResolutionResults : 172.22.65.231

MatchingIPsecRules :

NetworkIsolationContext : Private Network

IsAdmin : False

InterfaceAlias : Ethernet

SourceAddress : 10.70.4.228

NetRoute (NextHop) : 10.70.4.1

PingSucceeded : True

PingReplyDetails (RTT) : 39 ms

TcpTestSucceeded : False

Test-NetConnection -port 139 -ComputerName "FILESERVER-FS1-loc2" -InformationLevel "Detailed"

ComputerName : FILESERVER-FS1-loc2

RemoteAddress : 172.22.65.231

RemotePort : 139

AllNameResolutionResults : 172.22.65.231

MatchingIPsecRules :

NetworkIsolationContext : Private Network

IsAdmin : False

InterfaceAlias : Ethernet

SourceAddress : 10.70.4.228

NetRoute (NextHop) : 10.70.4.1

PingSucceeded : True

PingReplyDetails (RTT) : 39 ms

TcpTestSucceeded : True

Test-NetConnection -port 445 -ComputerName "FILESERVER-FS1-loc2" -InformationLevel "Detailed"

ComputerName : FILESERVER-FS1-loc2

RemoteAddress : 172.22.65.231

RemotePort : 445

AllNameResolutionResults : 172.22.65.231

MatchingIPsecRules :

NetworkIsolationContext : Private Network

IsAdmin : False

InterfaceAlias : Ethernet

SourceAddress : 10.70.4.228

NetRoute (NextHop) : 10.70.4.1

PingSucceeded : True

PingReplyDetails (RTT) : 39 ms

TcpTestSucceeded : True

Attempted Fixes

NSLOOKUP does find the systems

Creating a non-Admin share was no different

Turning off IPv6 was no help

Turning on SMB file sharing did not help

Checked and the OS firewall for Domain, Private, Guest or Public, all are off

Removing the SCCM-DP1-loc2 from the domain then will respond with a prompting for username and password, but still does not allow login and eventually fails with the same error.

Error:

Windows cannot access \\ SCCM-DP1-loc2\f$

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.

See Details shows

Error Code: 0x80004005

Unspecified error

Disabled SMB2/3 and this still fails

Verified that SMB1 is present

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

FeatureName : SMB1Protocol

DisplayName : SMB 1.0/CIFS File Sharing Support

Description : Support for the SMB 1.0/CIFS file sharing protocol, and the Computer Browser protocol.

RestartRequired : Possible

State : Enabled

Brink · Feb 2, 2021

New File Share Witness Feature in Windows Server 2019

This blog discusses a new feature in the upcoming release of Windows Server 2019. Currently, Windows Insiders receive current builds of Server 2019. We urge you to become an Insider and play a part in making Windows Server 2019 the best that it can be. To do so, go to this link and sign up.

One of the quorum models for Failover Clustering is the ability to use a file share as a witness resource. As a recap, the File Share Witness is designated a vote in the Cluster when needed and can act as a tie breaker in case there is ever a split between nodes (mainly seen in multi-site scenarios).

I don’t want to go through the list of all the requirements but do want to focus on one in particular.

The Windows Server holding the file share must be domain joined and a part of the same forest.

The reason for this is that Failover Cluster utilizes Kerberos for the Cluster Name Object (CNO) to connect and authenticate the share. Therefore, the share must reside on a domain member that is in the same active directory forest.

There are scenarios where this is not possible. These scenarios are:

No or extremely poor Internet access because of a remote location, so cannot use a Cloud Witness

No shared drives for a disk witness. This could be a Storage Spaces Direct hyper-converged configuration, SQL Server Always On Availability Groups (AG), Exchange Database Availability Group (DAG), etc. All of which do not utilize shared disks.

A domain controller connection is not available as the cluster has been dropped behind a DMZ

A workgroup or cross-domain cluster where there in no active directory CNO object

We have had a lot of requests over the years for how to get around these scenarios and there wasn’t a good story for it. Well, I am here to tell you we listened, and we produced something better than a workaround.
In comes Windows Server 2019 and the new File Share Witness feature to the rescue.

We can now create a File Share Witness that does not utilize the CNO, but in fact, simply uses a local user account on the server the FSW is connected to.

This means NO kerberos, NO domain controller, NO certificates, and NO Cluster Name Object needed. While we are at it, NO account needed on the nodes. Oh my!!

The way it works is that on the Windows Server you wish to place the FSW, create a local (not administrative) user account, give that local account full rights to the share, connect the cluster to the share.

Let’s take for example, I have a server called SERVER and a share called SHARE I want to utilize as the File Share Witness. For creating this type of File Share Witness can only be done through PowerShell. The steps for setting this up are:

Log on to SERVER and create a local user account (i.e. FSW-ACCT)

Create a folder on SERVER and share it out

Give the local user account (FSW-ACCT) full rights to the share

Log in to one of your cluster nodes and run the PowerShell command:

Set-ClusterQuorum -FileShareWitness \\SERVER\SHARE -Credential $(Get-Credential)

You will be prompted for the account and password for which you should enter SERVER\FSW-ACCT and the password.

Viola!! You are done as we just took care of all the above scenarios. The cluster will keep the name and password encrypted and not accessible by anyone.

Just as an FYI, the original demo of this feature was using a USB thumb drive holding the share plugged into a router. Not that we would recommend doing it, but does show how far you could take this.

Please try out this new feature and provide feedback through the Feedback Hub app.

Thanks,
John Marlin
Senior Program Manager
High Availability and Storage
Click to expand...

Source: New File Share Witness Feature in Windows Server 2019 | Clustering and High-Availability

dondre1992 · Feb 2, 2021

MCHBAR read access failed

Hi everyone,

Trying to install TechPowerUp GPU-Z v0.3.8 but i keep getting...MCHBAR read access failed, any suggestions???

Windows 10: Windows 10 file share access to Server 2012-2019 fails with Access Violation.

Windows 10 file share access to Server 2012-2019 fails with Access Violation.

Windows 10 file share access to Server 2012-2019 fails with Access Violation.

Windows 10 file share access to Server 2012-2019 fails with Access Violation.

Windows 10 file share access to Server 2012-2019 fails with Access Violation. - Similar Threads - file share access

Windows 10 + access MDB file shared in windows 2012R2 server access to slow

Windows 10 + access MDB file shared in windows 2012R2 server access to slow

Windows 10 + access MDB file shared in windows 2012R2 server access to slow

Windows Server 2019 Shares no longer accessible from windows 10 clients

Windows Server 2019 Shares no longer accessible from windows 10 clients

Windows Server 2019 Shares no longer accessible from windows 10 clients

Windows 10 can see server 2012 shares but refuses access

can't access Shared folders on windows server 2012

Windows 10 File Shares not accessible from Server 2012