Do I need to enable SMBv1 on Windows for Unraid?

No. Modern Unraid (6.x and newer) supports SMB2/SMB3 natively. SMBv1 is disabled on Windows by default for good security reasons; do not re-enable it for a normal Unraid share.

Why does the share work in browser but not File Explorer?

The Unraid web UI runs on a different port (HTTP/HTTPS) than SMB (port 445). If the UI loads but SMB fails, the problem is port 445 reachability or share permissions, not Unraid being down.

NAS

Unraid SMB share permissions for Windows clients

Most Unraid-to-Windows SMB problems are credential or share-access-mode mismatches, not network failures. Reading both sides in the right order is faster than turning settings off.

Best for: Unraid operators whose Windows PC cannot reach a share that works locally or for other devices.

Confirm the Unraid side first

Open Users and confirm the user has a password set; blank-password users cannot authenticate over SMB by default.
Open Shares > <share> > SMB Security Settings and read the Export and Security Mode fields — Public, Secure, and Private behave very differently for read/write.
Open Settings > SMB and confirm SMB is enabled, the workgroup matches the Windows workgroup if you rely on browsing, and Enhanced macOS Interoperability is off if Windows is your primary client.
Note the exact share name as it appears in the Unraid UI; it is case-sensitive in some paths.

Confirm the Windows side

Open PowerShell on the Windows client and run Test-NetConnection <unraid-ip> -Port 445 — port 445 must reach the Unraid server before permissions are the active layer.
Open Control Panel > Credential Manager > Windows Credentials and remove any stale entry for the Unraid hostname or IP before reconnecting.
Run net use to list current mappings; remove only the affected mapping with net use <letter>: /delete before retrying.
Confirm the active network profile is Private (Settings > Network & Internet > <connection> > Network profile) — SMB discovery is blocked on Public.

Common patterns and the fix path

If Test-NetConnection fails: port 445 is blocked or the Unraid box is unreachable; check the trusted LAN/subnet and any host firewall before changing share settings.
If port 445 works but credentials are rejected: stale Credential Manager entry, wrong username format (try <unraid-hostname>\<user>), or blank-password user on Unraid.
If credentials work but the share opens read-only or denies write: the share Security Mode/Export setting denies that user's group; fix on the Unraid Shares page, not on Windows.
If browsing is empty but \\<ip>\<share> opens: discovery only — set DHCP reservation, use the direct path, and skip the discovery debugging detour.

Evidence from the Unraid admin UI

Reference screenshots from a live Unraid server, captured in 2026-05 with identifying details masked.

Unraid Shares > share > SMB Security Settings section showing Export and Security mode dropdowns. — SMB Security Settings: Export controls visibility; Security mode controls authentication (Public, Secure, Private). Match the mode to your user assignment, not the other way around.

Unraid Shares > share > SMB user access section showing read/write user assignment. — User access: only users in the read/write list can write to a Private/Secure share. Read-only access denied is fixed here, not on the Windows side.

Operator snapshotEvidence first

First proof

Run Test-NetConnection <unraid-ip> -Port 445 from PowerShell on the Windows client.

Screen to open

Test-NetConnection <unraid-hostname-or-ip> -Port 445

Expected signal

TcpTestSucceeded is True.

Stop boundary

Stop for work-managed laptops; escalate to IT instead of disabling security.

Layer path

1Unraid SMB access is a layered path: Windows client > LAN > port 445 on the Unraid server > SMB service > share Export setting > share Security mode > user authentication > read/write user list.

2Windows ties its own state into this chain via Credential Manager, the active network profile (Private vs Public), and any mapped drives in net use.

3Most failures are credentials or share-mode mismatches, not network failures. Reading both sides in the right order is faster than turning settings off.

4Enabling SMBv1 to make a legacy device work is a security regression; resolve the device or isolate it instead.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Confirm port 445 reachability

Check: Run Test-NetConnection <unraid-ip> -Port 445 from PowerShell on the Windows client.

Expected result: TcpTestSucceeded is True.

If not: If False, fix network / firewall / VPN before any share-side change.

Safe stop: Stop for work-managed laptops; escalate to IT instead of disabling security.

Read the Unraid share configuration

Check: Open the "Unraid SMB share settings" command below; record Export, Security mode, and user assignment.

Expected result: Configuration matches the intent for the user trying to connect.

If not: If Security mode is Private but the user is not in the read/write list, that is the failure.

Read the Windows credential state

Check: Open Credential Manager > Windows Credentials; remove any stale Unraid host entry. Run the "Mapped drive review" command below; remove stale mappings only.

Expected result: No stale credentials or mappings remain for the Unraid host.

If not: If stale entries cannot be removed, sign out and back in to clear runtime cache.

Reconnect with the correct username format

Check: Type \\<unraid-ip>\<share>; when prompted, use <unraid-hostname>\<user> as the username.

Expected result: The share opens; create and delete a test file if write is expected.

If not: If still rejected, set or reset the Unraid user password and retry.

Stabilize the path

Check: Create a DHCP reservation for the Unraid server at the router so the IP cannot drift; document the share path for future use.

Expected result: Future reconnects use the same stable path.

If not: If the router cannot pin the IP, set a static IP on the Unraid server (Network Settings).

Safe stop: Stop before enabling SMBv1 to support a legacy device; isolate the device instead.

Decision tree

If: Test-NetConnection on port 445 returns False.

Then: SMB is blocked at the network layer.

Action: Check Windows network profile (must be Private on trusted LAN), Windows Defender Firewall outbound rules, any VPN routing rule, and Unraid server reachability via ping.

If: Port 445 works but Windows keeps prompting for credentials.

Then: Credential Manager has a stale entry, the username format is wrong, or the Unraid user has no password.

Action: Remove the Unraid credential from Credential Manager, then reconnect using <unraid-hostname>\<user> as the username.

If: Credentials accepted but the share opens read-only.

Then: Share permission denies write to that user.

Action: Open Unraid > Shares > <share> > SMB Security Settings and confirm the user is in the read/write list, not the read-only list.

If: Browsing under Network is empty but \\<ip>\<share> opens.

Then: Discovery is broken but SMB itself is fine.

Action: Use the direct UNC path; create a DHCP reservation for the Unraid server; do not chase discovery services.

If: Failure only on a work-managed laptop.

Then: Corporate policy (firewall, VPN, conditional access) may be blocking SMB or LAN access.

Action: Capture exact errors and escalate to IT; do not weaken security policy at home to compensate.

Safe stop: Stop before changing managed-device security settings.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Test-NetConnection on port 445 fails.	PowerShell shows TcpTestSucceeded : False.	Network / firewall / VPN.	Confirm subnet, switch to Private profile, check VPN routing, verify Unraid server is up.
Persistent credential prompt despite correct password.	Credential Manager has an old entry; Unraid user has no password.	Stored credential or blank-password user.	Remove the stale Windows credential; set a password on the Unraid user.
Read works but write fails with access denied.	User is in the read-only list under SMB Security Settings.	Share-level user permission.	Move the user from read-only to read/write in the Unraid share settings.
Share opens for some users and not others.	Security mode is Secure (mixed) and some users are not assigned.	Per-user share permission.	Assign each intended user in Unraid > Shares > <share> > SMB Security Settings.

Reference

Commands and settings paths

SMB reachability

Test-NetConnection <unraid-hostname-or-ip> -Port 445

Where: PowerShell on the Windows client PC.

Expected: TcpTestSucceeded : True.

Failure means: False means port 445 is blocked by network, firewall, or VPN before share permissions matter.

Safe next step: Confirm Private network profile, check VPN routes, verify the Unraid server is up.

Mapped drive review

net use

Where: cmd or PowerShell on the Windows client.

Expected: Listed mappings point at the current Unraid server and share; no stale or wrong entries.

Failure means: A stale mapping silently sends the wrong path or user.

Safe next step: Remove only the stale entry: net use <letter>: /delete; reconnect to the correct path.

Saved credential review

Control Panel > User Accounts > Credential Manager > Windows Credentials

Where: On the Windows client PC.

Expected: No stale entry for the Unraid hostname or IP.

Failure means: A stale credential overrides typed passwords silently.

Safe next step: Remove only the Unraid host credential and reconnect once with <hostname>\<user>.

Unraid SMB share settings

Shares > <share> > SMB Security Settings

Where: In the Unraid web UI.

Expected: Export is Yes/Hidden; Security mode matches intent; user assignment matches read/write expectations.

Failure means: A 'Private' share with no users assigned blocks everyone.

Safe next step: Match Security mode to user assignment and confirm with one test from a known account.

Hardware boundary

Hardware and platform boundary

Change only when

Upgrade the Windows client to a current build (Windows 10 22H2 or Windows 11) before troubleshooting odd SMB dialect issues on Unraid.

Evidence that matters

Network reliability, DHCP reservation, current Windows version, and matched SMB dialect on both sides matter.

Evidence that does not matter

Buying a faster switch does not fix a credential or share-permission failure.

Avoid

Avoid enabling SMBv1, disabling Windows Defender Firewall as a whole, or exporting shares as Public to 'just make it work'.

Last reviewed

2026-05-07 · Reviewed by HomeTechOps. Reviewed for Unraid <-> Windows SMB triage using Test-NetConnection, Credential Manager, net use, Unraid SMB Security Settings, and the SMBv1/Public-share safety boundary.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Unraid Docs: SharesUsed for Unraid user-share planning, network share access, and user-share vs disk-share safety warnings.Unraid Docs: Security fundamentalsUsed for Unraid account, update, password, and remote-exposure safety guidance.Microsoft Support: File sharing over a network in WindowsUsed for share-path format, mapped-drive checks, and the reminder that the host may be off or permissions may be wrong.Microsoft Support: Credential Manager in WindowsUsed for removing stale Windows Credentials when a share keeps prompting or rejects a known-good account.Microsoft Learn: Test-NetConnectionUsed for PowerShell-based TCP port reachability tests (e.g., port 445 for SMB) before troubleshooting permissions.Microsoft Learn: net use command referenceUsed for mapping, listing, and removing SMB drive mappings from Windows command line.Microsoft Learn: Troubleshoot SMBUsed for SMB connection failure triage, common error codes, and dialect-mismatch assumptions.Microsoft Support: Essential network settings in WindowsUsed for the Public vs Private network-profile decision before enabling sharing on a trusted home LAN.