TCP Port 139: NetBIOS, SMB, and How to Check Exposure

A scan reports TCP port 139 as open. What does that actually tell you—and should you close it?

Port 139 is used by the NetBIOS Session Service. It can carry SMB file- and printer-sharing traffic over NetBIOS over TCP/IP. That is different from TCP port 445, which carries SMB directly over TCP without NetBIOS.

The distinction matters when troubleshooting legacy file-sharing setups, reviewing firewall rules, or figuring out whether an open port is expected. A port number alone does not identify exactly what is running or whether a host is exposed to the internet.

Port 139 and port 445 are not interchangeable

Both ports can be associated with SMB, but they carry it differently:

Port	Transport	Typical role
TCP 139	NetBIOS session	SMB over NetBIOS, often for legacy compatibility
TCP 445	Direct-hosted SMB	SMB over TCP without NetBIOS

Modern Windows networks commonly use port 445, so not every file share needs port 139. Whether NetBIOS is still required depends on the devices and applications in your environment. Blocking 139 does not automatically block 445, and allowing one does not allow the other.

For context on how these assignments fit alongside other common services, see this overview of well-known network ports.

NetBIOS-related services also use UDP ports 137 and 138, for name and datagram services respectively. Those are separate from TCP 139, which handles session-oriented connections.

Check the listener and the network path separately

There are two different questions to answer:

1. Is anything listening on port 139 on the destination host?
2. Can a client reach that port from the network location that matters?

A local listener check answers the first question. It does not prove that a firewall or network path allows remote connections. A remote connection test answers the second question from one specific location, but it does not identify every service setting on the host.

Check on Windows

On the destination Windows computer, open PowerShell and run:

Get-NetTCPConnection -LocalPort 139 -State Listen

If the command returns a matching entry, a TCP listener is present. No output means it found no matching listener in the current network stack; it does not test remote reachability.

To test connectivity from another Windows machine, run:

Test-NetConnection -ComputerName server.example.com -Port 139

Replace the example hostname with the address you are authorized to test. Look at TcpTestSucceeded: True means the TCP connection succeeded from that machine at that time. False means it did not; possible causes include no listener, filtering, or a routing problem. It does not tell you which cause applies by itself.

Check on Linux

On the Linux destination host, inspect for a TCP listener with:

sudo ss -ltnp 'sport = :139'

This is a local check. If you need a broader walkthrough of interpreting listeners and checking ports on a Linux system, see how to check open ports on Linux.

Interpret scan results carefully

A result describes what a probe observed between one source and destination at a particular time. It is not a complete inventory of the target.

• Open: A TCP connection was accepted. This does not, by itself, prove which application responded or that a file share is usable.
• Closed: The destination was reachable but did not accept a connection on that port, often because no service is listening.
• Filtered or timed out: No response arrived. A firewall or another network condition may be dropping the probe; the result does not identify the exact cause.

If a scan shows port 139 open, first confirm that the address belongs to the system you meant to check. Then identify the local listener and review the host firewall and any network, router, or cloud rules along the route.

Keep NetBIOS exposure limited

An open port 139 is not proof that a machine is compromised. But exposing NetBIOS or SMB services broadly can increase the system’s attack surface. Do not make TCP 139 reachable from the public internet.

If a legacy device or application requires it, allow access only from the trusted networks or systems that need it. Before disabling NetBIOS or blocking the port, check for dependencies such as older file-sharing clients, printers, or applications. Verify that those still work after any change.

It also helps to identify where the rule is managed. A listener on the host, an operating-system firewall rule, and a router or cloud firewall rule are separate parts of the picture. Opening a port to fix a general connectivity problem is not a good substitute for finding out which service needs access and from where.

A practical way to investigate

When port 139 appears in a scan, work through these checks in order:

1. Confirm the target address and the network location used for the scan.
2. Check for a local listener on the destination host.
3. Test TCP connectivity from the client’s relevant network.
4. Review host and perimeter firewall rules independently.
5. Confirm whether a legacy NetBIOS requirement exists before disabling or blocking the service.

The key distinction is simple: TCP 139 can carry SMB over NetBIOS, while TCP 445 carries SMB directly over TCP. Check the listener and the network path separately, and keep port 139 restricted to trusted networks whenever a compatibility need requires it.

I originally published a more detailed version of this guide on the SSHFlow blog.

I'm also building SSHFlow — an SSH client where every server gets its own workspace for terminals, SFTP, code, and databases.