how to fix Dear Microsoft Support Team, We are unable to access a shared folder on a non-domain Windows PC from one domain-joined PC. Other computers can access the same folder successfully. Network connectivity and SMB port 445 are working, but we recei

Hardeep Singh (IT) 0 Reputation points
2026-08-22T11:42:14.1+00:00

Dear Microsoft Support Team,

We are unable to access a shared folder on a non-domain Windows PC from one domain-joined PC. Other computers can access the same folder successfully. Network connectivity and SMB port 445 are working, but we receive System Error 53 and System Error 3227320323 during authentication. Please advise the cause and recommended fix.

Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing
0 comments No comments

2 answers

Sort by: Most helpful
  1. Hoang Le 6,355 Reputation points Independent Advisor
    2026-08-23T04:32:48.2666667+00:00

    Hello Hardeep,

    System Error 53 indicates that the network path could not be found, while the large error code you mentioned (3227320323) is a STATUS_LOGON_FAILURE returned by SMB authentication. Since other machines can access the same share, the issue is specific to the domain-joined client. The most common cause is that the domain-joined machine is attempting to use domain credentials against a local account on the non-domain PC, which fails unless explicitly allowed.

    To fix this, ensure that the non-domain Windows PC has matching local user credentials that the domain-joined PC can use. On the domain-joined machine, when mapping the share, specify the local account explicitly in the format \NonDomainPC\Share and authenticate with NonDomainPC\LocalUser instead of the domain account. If you want seamless access, create a local account on the non-domain PC with the same username and password as the domain account, or enable “Password protected sharing” and configure the local account permissions accordingly.

    Additionally, check the following registry and policy settings on the domain-joined PC:

    Confirm that HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters does not have AllowInsecureGuestAuth set to 0 if guest access is required.

    Ensure that SMB1 is not disabled if the non-domain PC is running an older OS. Modern Windows defaults to SMB2/3, but mismatched configurations can cause error 53.

    Verify that the firewall on the non-domain PC allows inbound SMB traffic and that the share permissions include the local account you are using.

    In short, the cause is authentication mismatch: the domain-joined PC is trying domain credentials against a standalone machine. The recommended fix is to use explicit local credentials when connecting, or align the local account with the domain account credentials.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    HL.

    Was this answer helpful?

    0 comments No comments

  2. AI answer

    2026-08-22T11:42:36.46+00:00

    Because other computers can access the same non-domain PC, the share itself, basic network reachability, and port 445 are likely not the primary problem. The failure is most consistent with a client-side authentication or name-resolution configuration issue on the affected domain-joined PC.

    Recommended checks and fixes:

    1. Try the share by UNC path and by net use
         net use * \\<ServerName>\<ShareName>
      
      This helps confirm whether the issue is specific to File Explorer or affects SMB access generally.
    2. Force authentication with a local account on the non-domain PC For a domain-joined client connecting to a workgroup/non-domain server, Windows can send domain credentials that the target PC cannot validate. When prompted for credentials, use the remote computer’s local account instead of domain credentials.
    3. Clear saved credentials on the affected PC If cached credentials exist for the server name or IP address, remove them and reconnect using the local account on the non-domain PC. Incorrect cached credentials can cause authentication failures even when connectivity is fine.
    4. Check the TCP/IP NetBIOS Helper service For System error 53, one documented cause is that TCP/IP NetBIOS Helper is stopped or running as Local System instead of Local Service. Make sure the service is running as Local Service.
    5. Enable NetBIOS over TCP/IP on the affected client If access by name is failing, enable NetBIOS over TCP/IP in the adapter’s WINS settings. This is relevant when the path works by IP but not by hostname.
    6. Verify required network services are running If core Windows networking services are stopped, SMB access can fail. Check that these services are not stopped:
      • Network Connections
      • Network List Service
      • Network Location Awareness
      • Network Store Interface Service
      • DHCP Client
      • TCP/IP NetBIOS Helper
      • Workstation
    7. Confirm sharing visibility settings on the affected client On the affected PC, verify:
      • Network discovery is turned on
      • File and printer sharing is turned on
      • These services are set to Automatic:
        • Function Discovery Provider Host
        • Function Discovery Resource Publication
        • SSDP Discovery
        • UPnP Device Host Then restart the PC.
    8. If the issue is specifically “Access Denied” after connection, verify permissions If connection succeeds for some users but not this one, check both:
      • Share permissions
      • NTFS Security permissions
    9. If the problem persists, collect SMB diagnostics
         Get-SmbClientConfiguration | Out-File C:\SMBdata\client-config.txt
         Get-SmbConnection          | Out-File C:\SMBdata\connections.txt
         netsh trace start capture=yes scenario=NetConnection tracefile=C:\SMBdata\smb.etl
      
      Reproduce the issue, then stop the trace:
         netsh trace stop
      
      Also export the SMBClient event log for the repro window.

    A practical first fix for this exact scenario is:

    • remove cached credentials for the target server,
    • reconnect using the non-domain PC’s local account,
    • ensure TCP/IP NetBIOS Helper is running as Local Service,
    • enable NetBIOS over TCP/IP if hostname access fails.

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.