SMB: File and printer sharing ports should be open

Updated: February 2, 2011

Applies To: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and Windows Server 2012, Windows Server 2008 R2

This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the File Services Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer.

Operating System

Product/Feature

Severity

Category

Issue

The firewall ports necessary for file and printer sharing are not open (ports 445 and 139).

Impact

Computers will not be able to access shared folders and other Server Message Block (SMB)-based network services on this server.

Resolution

Enable File and Printer Sharing to communicate through the computer’s firewall.

Membership in the Administrators group, or equivalent, is the minimum required to complete this procedure.

To open the firewall ports to enable file and printer sharing

Open Control Panel, click System and Security, and then click Windows Firewall.

In the left pane, click Advanced settings, and in the console tree, click Inbound Rules.

Under Inbound Rules, locate the rules File and Printer Sharing (NB-Session-In) and File and Printer Sharing (SMB-In).

For each rule, right-click the rule, and then click Enable Rule.

FIX: Windows 10 Firewall is blocking File Sharing

• Having your Windows 10 Firewall block your PCs File Sharing capabilities can get very annoying.
• To resolve this issue, you should start by making sure that File and Printer Sharing is enabled.
• Don’t hesitate to explore our thorough Troubleshooting Hub for more easy-to-follow guides on this topic.
• Our detailed Windows 10 section can offer you quick access to some other useful guides, so make sure to explore it further.

File Sharing is an essential feature for users who have multiple PCs in a Homegroup (Workgroup). Once it’s configured, the file exchange should work seamlessly.

After enabling File Sharing, your Windows Defender Firewall should allow the feature to communicate freely.

However, some users reported issues with Windows 10 Firewall blocking File Sharing.

We have a few solutions to suggest below, so make sure to check them out.

How can I unblock File Sharing on Windows 10?

1. Enable File and Printer Sharing

1. In the Windows Search bar, type Sharing and open Manage advanced sharing settings.
2. Under the Network discovery, toggle the Turn on network discovery on.
3. Under the File and printer sharing, toggle the Turn on file and printer sharing on.
4. Save changes and reboot your PC.

2. Allow File and Printer Sharing to communicate through Firewall

1. In the Windows Search bar, type Firewall and open Windows Defender Firewall.
2. Open the Allow an app or feature through Windows Defender Firewall.
3. Click Change settings.
4. Navigate to File and Printer Sharing and File and Printer Sharing over SMBDirect.
5. Make sure to check both Private and Public boxes next to these entries.
6. Save changes and try sharing files on the local network again.

We hope that this guide has managed to solve your problem once and for all.

If you want to share your experience with us or have any suggestions, feel free to contact us by using the comment section found below this article.

Windows firewall blocks file sharing

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Asked by:

Question

I have a Win 7 desktop with network shares that I want my Win 10 pc to access. If I turn the Win 7 Firewall off, no problems with access. What program(s) do I need to allow to communicate through the firewall to make this work? Win 7 pc network profile is Home or Work with a Homegroup set up (which is why I am setting up these shares since Homegroups are going away). Win 10 pc network profile is private.

All replies

TCP port 445 (used by SMB) became famous last year, because security hole was found in that port. So Microsoft and many antivirus vendors made efforts to block that port from something malicious .

Hope that I haven’t misunderstand you:

You windows 10 can’t access the shared folder on windows 7 unless you disable the firewall, which both are in homegroup.

To allow programs through firewall by clicking Allow an App or feature through Windows Firewall.

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

Ashidacchi — I understand that MS and other vendors changed the firewall to block all TCP 445 traffic as a response to the huge ransom ware/wannacrypt attacks. However this is the port used for SMB which is what File and Print Sharing uses. It would seem to me that the side effect of blocking all access to this port would be to disable access to File and Print Sharing on this pc which is exactly what I experienced even though as I mentioned above that all the File and Print Services rules were enabled in the firewall. This would be very difficult for the average person to troubleshoot. I would suspect that this will get worse as MS moves to remove Homegroups and rely more on the use of traditional shares and the cloud.

vivian_zhou — as I mentioned above and in my response to Ashidacchi, all the File and Print Sharing inbound rules were enabled.

Windows Firewall Blocking Drive Mapping / File Sharing on VPN Subnets

I recently set up a site-to-site VPN via IPSEC using two Zyxel USG40 firewalls/routers. The connection works fine and I’m able to easily ping devices from two different subnets.

The issue comes up when I try to map a network drive and view shared folders/files on one of the systems on a different subnet. I’ve isolated the issue to being caused by the Windows Firewall on the Windows 10 workstation I’m working FROM. If disable the Domain firewall, it works without issue.

I don’t have any block rules in the firewall, and I created both inbound and outbound rules to allow all with the subnet (custom rule with remote IP scope set to 192.168.2.0/24). This doesn’t work however.

It’s like there’s some hard baked rule that’s overriding things but I’m at a loss.

Ok, so I ended up figuring this issue out after a spending a lot of time testing things out. I wanted to share what I found in case anyone else runs into this issue. To add a bit more information, I tested this out on two workstations with the latest version of Windows 10 (Build 1909). Both systems are part of a domain.

1) The suggestion above about changing the scope on the SMB-In rule ended up not mattering. The default behavior for a domain connection for most of the File & Printer Sharing rules is «Any» for Remote IPs. For Private it’s Local Subnet, so if you’re having this issue not on a domain you may need to add any additional subnets to the scope for SMB-In, NB-Datagram-In, NB-Name-In, and NB-Session-In.

2) What was most befuddling was that the firewall seemed to inconsistently block the connection to the mapped drive. I would change some things, get it working, and it would work for a bit. Then without touching the firewall it would stop working. This lag made it very hard to narrow things down, but I believe I narrowed down what was happening.

3) I created an inbound rule for all ports, all programs, etc. For the scope under Remote IPs, I added the IPs of the two servers that had the folder I was trying to map: 192.168.2.5 and 192.168.3.5 respectively. The two different subnets are because I have to different site-to-site VPN connections set up.

4) I found that this would sometime work, but then it would stop working. I ended up adding another entry to the Remote IPs in the rule I created for the local subnet: 192.168.1.0/24. This wouldn’t fix the problem right away, but eventually, things would start working again so I knew that it was something on the local subnet that was being dropped and causing the mapped drives to stop working. I wasn’t sure what the lag was from though.

5) Because I didn’t want to open up access that generally to anything on the local subnet, I wanted to find out what device specifically was causing the problem. I removed the 192.168.1.0/24 from the scope on my rule and waited for the mapped drives to stop working (took about 10 minutes). I turned on Firewall logging, tried to access the drives, and saw in the log that there were ICMP packets from my primary gateway (also a Zyxel USG40 at 192.168.1.1) that were being dropped by the firewall. Sure enough, when I added 192.168.1.1 to the scope and waited a bit, things started working again and it’s been that way ever since. I don’t know why this traffic from the primary gateway was required for the mapped drives (especially since the VPN connections are handled by a separate router at 192.168.1.11), but apparently it is. My guess is that the gateway is periodically sending out these requests and this is why the lag was occurring. If I made a change to the firewall that should break it, things would work fine until the request was sent out and when it was dropped it would stop working. In the reverse, when I made a change that should make things work, it wouldn’t start working right away. It wasn’t until the gateway sent out that request again that things would start working.

Anyway, hopefully this is helpful to anyone else that might run into this issue.

Error: A firewall is blocking file Sharing between Windows and the containers #355

Comments

medhatelmasry commented Dec 25, 2016

Expected behavior

I am using Docker for windows 10 with a Linux container. I am unable to share a drive. I get a firewall error when I do so similar to case #345. This was working OK until I reset my credentials and it stopped working.

Actual behavior

When I try to share any drive I get error:
A firewall is blocking file Sharing between Windows and the containers. See documentation for more info.

Information

Diagnostic ID is
1ED2444F-86D2-400A-A2AC-165C6FA6599A/2016-12-24_21-28-25

Steps to reproduce the behavior

1. Right-click on the docker icon in the Windows 10 tray and select Settings
2. Click on Shared Drives tab
3. Enable C, D, and E drives then click on Apply button
4. Following error is displayed: A firewall is blocking file Sharing between Windows and the containers. See documentation for more info.

The text was updated successfully, but these errors were encountered:

sugun999 commented Dec 28, 2016

Do you have any 3rd party security software(example, f-secure) installed on your system? If so, you need to open firewall with security software

johnrb2 commented Dec 28, 2016

I got this issue and it was coming from my cisco vpn. Once I disabled the VPN I could share just fine but now I don’t have access to the databases I need.

friism commented Jan 4, 2017

@simonferquel do you have time to look at @medhatelmasry dump?

simonferquel commented Jan 5, 2017

@medhatelmasry I see that you are using an insider preview of Windows. Unfortunately in latest build there seem to have a bug with Samba sharing preventing drive sharing with the linux VM to work.

We don’t have any workaround for now (except reverting to Windows 14393)

denisvmedia commented Jan 11, 2017 •

@simonferquel, I don’t think there is a bug in Windows. It used to work for me (and still works on another PC with the most recent insider release), but then I had to reset the settings of Docker, after that it stopped working.

simonferquel commented Jan 11, 2017

@denisvmedia there was a bug before 15002 with remote access in general (not only Samba File sharing, but also with RDP). I don’t know if it did hit everyone though and I suppose Microsoft fixed that in 15002.

denisvmedia commented Jan 11, 2017 •

@simonferquel unfortunately, I don’t know, but what really surprises me that this stopped working only after I did the reset in Docker. So even if there is a bug in Windows, there must be a workaround — otherwise how could it work before? (and still works on another PC) I’d be happy to find it. If I can help anyhow, I’m open for that, because currently my work is completely stopped due to this issue 🙁

Update: As of RDP — it works for me right now — I’m writing this from an external network on my Desktop through RDP.

denisvmedia commented Jan 11, 2017

I solved it! Now it works again. I found a comment of @gorbunovav in #114, it worked for me:

Try to share the drive manually in Windows and check, that you can access

If it doesn’t work — check, that file sharing is enabled for the docker interface location (Public network by default) and try to remove, then add back ‘File and Printer Sharing for MS Networks’ in ‘vEthernet (DockerNAT)’ network adapter’s properties.

(I’ve also moved interface to the ‘Private network’ segment:

Set-NetConnectionProfile -InterfaceAlias «vEthernet (DockerNAT)» -NetworkCategory Private

hindsight20-20 commented Jan 20, 2017

I see this issue in Win10 Insider build 15007. Just submitted feedback to MS about this since it had been fixed in a prev. (way older, might have been 14393) Insider build. Currently updating to 15014.

hindsight20-20 commented Jan 20, 2017

Volume mapping is working again in Win10 Insider build 15014.

phillipsharring commented Jan 26, 2017

@johnrb2 — did you ever figure this out with Cisco VPN? My team are all using a docker container for development and it’s made WFH really annoying. Thoughts? Thanks, Phillip

phillipsharring commented Jan 26, 2017 •

Markdown seems to have eaten the solution @denisvmedia posted. In a file explorer, go to: \\10.0.75.1\C

johnrb2 commented Jan 26, 2017

@philsown yeah I just had to change the address in network settings to 192.168.x.x since the VPN was already using the 10.0 ones.

johnrb2 commented Jan 26, 2017

@philsown there is another thread regarding the Cisco VPN that my solution didn’t work for @sugun999 he or she could use some help.

johnrb2 commented Jan 26, 2017

absalan commented Feb 18, 2017

I had same issue and I just solved it.
My internet security software was blocking file and printer sharing. If you do too, Just right click on the drive that you want to share with docker in file explorer and click on Sharing tap. Than click on advanced sharing. On that popup check the «Share this folder» checkbox and click ok. If your security software warned you just click on it and enable file sharing on it and click ok. Now if you go to docker settings and share the drive, it will work.

sthuber90 commented Feb 18, 2017

@absalan When I share my C: drive manually thorugh the advanced sharing settings and then try to activate in the docker settings, I get the notification that firewall is blocking, which it is not (#466) and after that the C: drive is not shared anymore.

rn commented Feb 18, 2017

@sthuber90 that’s interesting. If you don’t enable sharing in the Advanced Settings does it work? Also, how do you enable it? There are several options in the menu. Could you maybe share a screenshot?
thanks

absalan commented Feb 19, 2017

@sthuber90 Try to share another drive. windows does have some policy for windows drive and that’s why it’s preventing you from sharing drive C.

sthuber90 commented Feb 20, 2017

@absalan The computer is work on is a corporate one and only has a C drive, otherwise I would have tested sharing an other drive.

Even though it says that the firwall is blocking this cannot be the case, as mentioned here.

hindsight20-20 commented Feb 20, 2017

This has got nothing to do with suspected policies for the C drive. I just tried to share D and got the same results:
[10:54:49.631][NamedPipeClient][Info ] Sending GetDefaultVhdxPath(). [10:54:50.636][NamedPipeServer][Info ] GetDefaultVhdxPath() [10:54:51.643][NamedPipeClient][Info ] Received response for GetDefaultVhdxPath [10:54:51.642][NamedPipeServer][Info ] GetDefaultVhdxPath done in 00:00:01.0057637. [10:54:53.485][SharedDrivesSettings][Info ] Apply shared drive settings [10:54:53.486][NamedPipeClient][Info ] Sending Unmount(C, Docker.Core.Settings). [10:54:53.487][NamedPipeServer][Info ] Unmount(C, Docker.Core.Settings) [10:54:53.487][SambaShare ][Info ] Unmount C [10:54:53.652][ApiProxy ][Info ] proxy >> GET /_ping [10:54:53.652][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:53.656][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:53.660][ApiProxy ][Info ] proxy > POST /v1.26/images/load?quiet=1 [10:54:53.663][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:53.666][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:53.924][ApiProxy ][Info ] proxy > GET /_ping [10:54:54.104][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.111][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.126][ApiProxy ][Info ] proxy > POST /v1.26/containers/create [rewriteBinds] [10:54:54.172][ApiProxy ][Info ] Failed to Walk to [snapshots f483c5cc239a2903863cbc3ee314daa95d60a1ee ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory [10:54:54.176][ApiProxy ][Info ] Failed to read proxies/http from snaphshot p9p.MessageRerror [10:54:54.176][ApiProxy ][Info ] proxy >> POST /v1.26/containers/create [10:54:54.176][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.180][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.353][ApiProxy ][Info ] proxy > POST /v1.26/containers/d18518d66c7d9c0bc61af40b892fe13b1768d34201d8310da310becd806d213b/attach?stderr=1&stdout=1&stream=1 [10:54:54.368][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.370][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.372][ApiProxy ][Info ] Upgrading to raw stream [10:54:54.375][ApiProxy ][Info ] proxy >> GET /v1.26/events?filters=%7B%22container%22%3A%7B%22d18518d66c7d9c0bc61af40b892fe13b1768d34201d8310da310becd806d213b%22%3Atrue%7D%2C%22type%22%3A%7B%22container%22%3Atrue%7D%7D [10:54:54.375][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.376][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.380][ApiProxy ][Info ] proxy >> POST /v1.26/containers/d18518d66c7d9c0bc61af40b892fe13b1768d34201d8310da310becd806d213b/start [start] [10:54:54.380][ApiProxy ][Info ] proxy >> POST /v1.26/containers/d18518d66c7d9c0bc61af40b892fe13b1768d34201d8310da310becd806d213b/start [10:54:54.380][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.381][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:54.772][ApiProxy ][Info ] proxy > GET /_ping [10:54:56.526][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.527][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.532][ApiProxy ][Info ] proxy > POST /v1.26/images/load?quiet=1 [10:54:56.535][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.536][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.703][ApiProxy ][Info ] proxy > GET /_ping [10:54:56.847][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.848][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.851][ApiProxy ][Info ] proxy > POST /v1.26/containers/create [rewriteBinds] [10:54:56.876][ApiProxy ][Info ] Failed to Walk to [snapshots f483c5cc239a2903863cbc3ee314daa95d60a1ee ro com.docker.driver.amd64-linux proxy http] 9p: No such file or directory [10:54:56.879][ApiProxy ][Info ] Failed to read proxies/http from snaphshot p9p.MessageRerror [10:54:56.879][ApiProxy ][Info ] proxy >> POST /v1.26/containers/create [10:54:56.879][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:56.882][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.063][ApiProxy ][Info ] proxy > POST /v1.26/containers/a58989958bb9d51572e93a2617c7eb56c45faf14ae9e38495af5d37f265f6803/attach?stderr=1&stdin=1&stdout=1&stream=1 [10:54:57.080][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.081][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.083][ApiProxy ][Info ] Upgrading to raw stream [10:54:57.085][ApiProxy ][Info ] proxy >> GET /v1.26/events?filters=%7B%22container%22%3A%7B%22a58989958bb9d51572e93a2617c7eb56c45faf14ae9e38495af5d37f265f6803%22%3Atrue%7D%2C%22type%22%3A%7B%22container%22%3Atrue%7D%7D [10:54:57.085][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.086][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.088][ApiProxy ][Info ] proxy >> POST /v1.26/containers/a58989958bb9d51572e93a2617c7eb56c45faf14ae9e38495af5d37f265f6803/start [start] [10:54:57.088][ApiProxy ][Info ] proxy >> POST /v1.26/containers/a58989958bb9d51572e93a2617c7eb56c45faf14ae9e38495af5d37f265f6803/start [10:54:57.088][ApiProxy ][Info ] Dial Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.089][ApiProxy ][Info ] Successfully dialed Hyper-V socket 00c5797d-99af-4ba5-abbf-702f0b4c71e7:23a432c2-537a-4291-bcb5-d62504644739 [10:54:57.598][ApiProxy ][Info ] proxy

mickext commented Sep 6, 2017

This problem can be happen If you are using Windows 10 Enterprise.

The Group Policy in System Center / Active Directory can blocking the port 445. The System Administrator needs permit this port to your user/ip.

Releasing the door in Windows Firewall Local does not make effect.

Kounavi commented Sep 20, 2017

@simonferquel What can I say? 🙂 Back then I was using Divio’s app but days have come and gone by and I’m using docker compose now when I have to resort to docker which I find much better and much more flexible for my workflow and usage cases (at least for me). Also, without that workaround I couldn’t use docker in any way so it was a necessary evil (but can’t recall the details since it’s been a long time).

apodznoev commented Sep 27, 2017 •

I’ve read all this and a couple of other topics and tried everything written there. The only thing that finally worked for me was switch to Docker Edge version:

Client:
Version: 17.09.0-ce-rc3
API version: 1.32
Go version: go1.8.3
Git commit: 2357fb2
Built: Thu Sep 21 02:31:16 2017
OS/Arch: windows/amd64

Server:
Version: 17.09.0-ce-rc3
API version: 1.32 (minimum version 1.12)
Go version: go1.8.3
Git commit: 2357fb2
Built: Thu Sep 21 02:36:52 2017
OS/Arch: linux/amd64
Experimental: true

command0r commented Oct 9, 2017 •

Sounds weird, but the solution offered by @juhap worked for me. Seems more like a Windows 10 glitch that has nothing to do with Docker.