Why Does SMB File Sharing Work on Windows but Fail on macOS?

When SMB file sharing works on Windows but fails on macOS, the server is probably not completely offline. Windows has already shown that the share exists and that at least one client can reach it. The difference is more likely in the address being used, saved credentials, account identity, SMB negotiation, signing requirements, share permissions, or the way Finder handles network folders.

The safest troubleshooting method is to make both computers test the same target. Start with the exact server IP and share name, then move through hostname resolution, authentication, security negotiation, permissions, Samba compatibility, and Finder performance. Do not begin by enabling legacy SMB or disabling signing across the Mac.

First Confirm That Windows and macOS Are Opening the Same Share

Windows may already have a mapped drive such as \\192.168.1.50\Documents, while the Mac user is clicking a server icon in Finder or trying only smb://server-name. Those tests may point to different addresses, accounts, or share paths.

On the Windows computer, record the working server address, share name, username, and whether the connection uses an IP address or hostname. Then press Command + K in Finder and enter the equivalent path, such as smb://192.168.1.50/Documents.

If the Mac can open the precise IP-and-share path, the SMB service and share are fundamentally reachable. The remaining problem is more likely discovery, DNS, stored credentials, or the original path format.

Use the Server IP Before Relying on Finder Discovery

Windows and macOS do not always discover network devices in the same way. A server can appear automatically in Windows File Explorer while remaining absent from the Finder Network view.

This does not necessarily mean macOS cannot use SMB. Automatic discovery depends on DNS, mDNS, NetBIOS-compatible behavior, router name resolution, and the announcements made by the file server. Direct access through smb://IP/share bypasses most of that discovery layer.

If the IP works, keep SMB configuration unchanged and investigate the name instead. Check whether the hostname resolves to the correct address, whether the server advertises itself through mDNS, and whether the Mac has cached an old address.

Clear Saved Credentials Before Resetting the Server Password

macOS can reuse SMB credentials stored in Keychain. This becomes confusing when a password changes, the same server is accessed through both an IP and hostname, or the user previously selected guest access.

Disconnect the mounted share, open Keychain Access, and search for the server hostname, IP address, and share name. Remove stale entries, then reconnect and enter the account that actually exists on the SMB server.

Apple’s troubleshooting steps begin with verifying the correct username, password, hostname, and share access. Although that page addresses macOS-hosted SMB environments, the same separation is useful here: successful authentication and permission to use a particular share are different checks.

Make Sure the Mac Is Sending the Correct Account Identity

A Windows computer may connect automatically with its signed-in account. On macOS, the login dialog may default to the Mac username, which may not exist on the Windows, NAS, or Samba server.

The server may expect a local server account, Samba user, Microsoft account, Active Directory identity, or an account qualified with a machine, workgroup, or domain name. Depending on the environment, valid formats may include username, SERVER\username, or DOMAIN\username.

Do not use a Windows Hello PIN as the SMB password. A PIN normally unlocks the Windows device locally; the file server still needs the underlying account password or another supported authentication method.

Check Whether Port 445 Is Reachable From the Mac

If the exact SMB path fails before a login prompt appears, verify that the Mac can reach the server on TCP port 445. Windows may be using a different network interface, VLAN, firewall profile, or saved route.

On macOS, a simple test such as nc -vz 192.168.1.50 445 can show whether the port accepts a connection. A timeout points toward routing, VLAN isolation, firewall rules, or a server that is not listening on the expected interface.

If port 445 is reachable but authentication fails, the physical network path is no longer the main suspect. Move to credentials, SMB dialects, signing, and share permissions.

SMB Dialect Negotiation Can Differ Between the Two Clients

Older routers, legacy NAS devices, and outdated Samba installations may offer protocol combinations that one Windows computer accepts but a current Mac does not negotiate successfully.

The long-term fix is to configure the server for SMB2 and SMB3 rather than relying on SMB1 or a collection of client-side compatibility exceptions. A modern Samba configuration can explicitly use SMB2 as the minimum and SMB3 as the maximum protocol, which gives Windows and macOS a clearer negotiation range.

Do not assume that Windows compatibility proves the server configuration is modern. SMB1 or legacy authentication may have been manually enabled on that Windows machine, while the Mac is using a different security baseline.

Signing and Authentication Requirements Must Match

SMB signing verifies that messages have not been modified in transit. A connection can fail when the client and server disagree about SMB security capabilities, authentication, signing, or validate-negotiate behavior.

Apple notes that SMB 3 is the default connection method on macOS, that authenticated SMB 3 sessions use signing, and that certain directory-bound environments can fail during SMB 3 validate-negotiate and session-signing checks. That is a specific Open Directory case, but it illustrates why a generic “connection failed” message can originate during security negotiation rather than basic networking.

Do not set signing_required=no or validate_neg_off=yes as the first response. Disabling validation or signing can reduce protection against interception. First confirm the server supports a current SMB version and has a consistent signing policy.

Guest Access May Not Be What Windows Is Actually Using

A Windows share may open without displaying a password prompt, leading the user to assume it is a guest share. Windows may actually be reusing cached credentials from Credential Manager or the signed-in account.

On the Windows client, inspect the active SMB session or disconnect the mapped share and reconnect explicitly. Then use the same server-side account on the Mac.

If the share is intentionally anonymous, confirm that the server permits guest access and maps guest users to an account with appropriate filesystem permissions. Avoid enabling broad guest access simply to bypass an unresolved credential problem.

Share Permissions and Filesystem Permissions Are Separate

A Mac may authenticate successfully but still see an empty share, receive “permission denied,” or mount the folder as read-only. In that case, the SMB connection worked; file authorization did not.

Most file servers evaluate at least two layers. The share configuration decides which users can enter the share, while NTFS permissions, POSIX ownership, or filesystem ACLs decide what those users can read, create, modify, and delete.

Test Windows and macOS with the same server account. If one client uses a different user or group, their results are not directly comparable. Also check whether the Mac accidentally connected as guest while Windows used an authenticated account.

Samba May Need Better macOS Metadata Support

If the server uses Samba, basic Windows compatibility does not guarantee ideal macOS behavior. Finder and Mac applications use extended attributes, Finder metadata, alternate data streams, and resource forks that Windows clients may never request.

A Samba setup intended for mixed Windows and macOS use can enable macOS metadata through fruit and streams_xattr. A typical configuration may include vfs objects = catia fruit streams_xattr so Apple-specific metadata can be represented without breaking normal Windows access.

These modules are most relevant when the share mounts but file names, extended attributes, resource forks, Time Machine behavior, or Finder metadata are inconsistent. They are not a substitute for fixing an incorrect password or unreachable server.

Finder Performance Problems Can Look Like Connection Failures

Sometimes the share is connected, but Finder shows a blank directory, spins for several seconds, or becomes unresponsive while opening a large folder. The user experiences this as “SMB is broken,” even though the mount itself succeeded.

Finder may request file metadata, permissions, previews, resource information, and directory updates. These operations affect a Mac differently from a basic Windows directory listing, especially on large folders or servers without Apple-oriented metadata handling.

Test the same mounted share in Terminal with commands such as ls, or copy one large file without browsing a large directory first. If Terminal access works while Finder remains slow, troubleshoot metadata and directory enumeration rather than authentication.

A Slow Share Is Not the Same as a Failed Share

Do not combine authentication failures and transfer-speed problems into one diagnosis. A Mac that cannot mount a share has a different issue from a Mac that mounts successfully but writes slowly.

In one Unraid community case, reads reached about 180 MB/s while writes fell to roughly 2 MB/s, even though local disk and network tests were much faster. That is useful as a symptom pattern, but it does not prove signing is the universal cause; storage layout, cache behavior, small files, client interfaces, and Samba settings can produce similar asymmetry.

Measure separately: network throughput, one large-file read, one large-file write, and a many-small-files workload. Only adjust SMB performance settings after identifying which test is actually slow.

Docker-Based Samba Adds User and Volume Mapping Problems

A Samba container can accept Windows connections while rejecting macOS because the two clients are not presenting the same identity. The container may also publish port 445 correctly while its mounted volume has incompatible ownership or ACLs.

Check the Samba account inside the container, the host UID and GID used for mounted storage, the volume’s read/write permissions, the published port, and the effective smb.conf. Review container logs while the Mac attempts to connect.

If the request reaches the container and authentication succeeds, stop changing Docker networking. Focus on user mapping, share configuration, filesystem ownership, and Apple metadata support.

Treat Client-Side SMB Tweaks as the Last Layer

Online fixes often provide a long /etc/nsmb.conf file that disables signing, changes directory caching, forces a protocol, or modifies multichannel behavior. Copying all of those settings at once makes it impossible to know which change mattered.

Community-tested changes involving directory caching and wired multichannel behavior may help specific macOS, network, and Unraid combinations. The same discussion also includes security-reducing options and conflicting results, so it should be treated as experimental troubleshooting rather than a universal configuration.

Before editing nsmb.conf, save the current state and change one parameter at a time. Retest the same folder and file transfer after each change. Avoid disabling signing solely for speed unless the security trade-off is understood and the share is limited to a trusted network.

Follow a Layered Troubleshooting Order

The most effective process begins with the exact target and moves toward increasingly specific client behavior. Do not edit Samba, Keychain, DNS, signing, and Finder settings simultaneously.

Start with the working Windows path, test smb://IP/share on macOS, and confirm port 445. Then clear saved credentials, verify the account identity, and check SMB2/3 support. After that, examine signing, share permissions, filesystem ACLs, Samba Apple extensions, and Finder performance.

This sequence preserves the evidence from each test. An IP-versus-hostname result identifies discovery problems; a login prompt identifies a reachable SMB service; a mounted but read-only share identifies permissions; and a working Terminal session with a slow Finder window identifies client-side browsing behavior.

Final Takeaway

When SMB works on Windows but fails on macOS, use the Windows connection as a reference rather than proof that every server setting is correct. The two clients may be using different addresses, usernames, cached credentials, protocol capabilities, or permissions.

Begin with the exact smb://IP/share path. If the IP works but the hostname fails, troubleshoot discovery. If the login fails, clear Keychain credentials and verify the server account. If authentication works but file access does not, inspect share permissions and filesystem ACLs. If the share mounts but Finder is slow, move to metadata, Samba Apple extensions, and measured performance tests.

Client-side options that disable signing or negotiation checks should remain a last resort. A current SMB2/3 server, clear account mapping, correct permissions, and deliberate macOS metadata support provide a more reliable fix than weakening security to accommodate an unexplained configuration mismatch.

FAQ

Why can Windows see my SMB server but Finder cannot?

Windows and macOS may use different discovery methods. Try the exact server IP and share path with smb://192.168.x.x/share. If that works, the problem is hostname resolution or discovery rather than SMB itself.

Why does my Mac keep rejecting a password that works on Windows?

The Mac may be reusing an old password from Keychain or sending its local macOS username instead of the server account. Remove the stored SMB credential and reconnect with the account defined on the file server.

Should I disable SMB signing on macOS?

Not as a first fix. Disabling signing reduces message-integrity protection and may hide an outdated or inconsistent server configuration. Verify SMB2/3 support, credentials, permissions, and server signing policy first.

Why can the Mac mount the share but not create or edit files?

The connection and authentication succeeded, but the user may lack write access in the SMB share configuration or the underlying NTFS/POSIX filesystem permissions.

Why is Finder slow when Windows File Explorer is fast?

Finder requests additional metadata and may spend more time enumerating large directories. Test a direct large-file transfer and compare Finder with Terminal before changing security settings.