What Is netbiosd on Mac? Why macOS Asks to Allow It

netbiosd is a background process that ships with macOS and is code-signed by Apple. Its job is to implement NetBIOS, an old network naming layer that Windows machines have used for decades to announce themselves and find each other on a local network.

NetBIOS predates most of what you think of as modern networking. It was designed for an era when computers on the same office network needed a simple way to claim a short, human-readable name and broadcast it so others could find the right box behind an address. Windows adopted it, tied it closely to file and printer sharing, and it became the substrate under classic Network Neighborhood browsing.

Apple included support for it because Macs have long needed to coexist with Windows networks. When your Mac can see a Windows PC in the Finder sidebar, or when a Windows PC can see your Mac while file sharing is on, netbiosd may be part of what made that introduction happen. The same applies to older network-attached storage devices and network printers, many of which were built around SMB and Windows-style browsing.

The boundary is worth being precise about. netbiosd handles discovery and naming on your local network — deciding which machine answers to which short name, and letting devices on the same subnet learn about each other. The actual file transfer once you connect to a share is handled by other parts of the system.

The macOS application firewall works on a simple principle: when a program wants to accept incoming connections, macOS asks you once and then remembers your answer. Outgoing traffic is not what triggers the dialog. Something listening is.

netbiosd listens by design. Name announcement is a two-way conversation — your Mac broadcasts its name and also has to be reachable when another machine asks who holds a particular name. That means opening a listening socket on the local network, which is exactly the behaviour the firewall is built to surface. NetBIOS name service traditionally uses UDP port 137 and the datagram service UDP port 138; those numbers are standard, though what is actually in use depends on your macOS version and which sharing services you have enabled.

This is why netbiosd shows up in that dialog far more often than most system processes. It is not misbehaving and it has not changed. It is one of the few Apple daemons whose normal function is to be reachable from other machines on the same network, and the firewall treats every such process alike regardless of who signed it.

The prompt also tends to reappear after system updates. When a binary is replaced during an upgrade, the firewall may not recognise it as the program it saw before and asks again. That is expected, not a sign that something is wrong.

netbiosd is not malware. It is a first-party Apple component, distributed as part of macOS, and on a healthy system it carries an Apple code signature. Nothing about seeing it in Activity Monitor or in a firewall prompt indicates a compromise.

You do not have to take that on faith. In Activity Monitor, select the process and open its inspector to see the full path of the executable it launched from — a genuine system daemon lives under the system directories, not in your Downloads folder. If you are comfortable in Terminal, the codesign tool with the verbose verify option, pointed at that path, reports the signing authority; for a legitimate copy that authority is Apple. Anything claiming the name from an unexpected location, or failing verification, is worth investigating further.

The other half of the reassurance matters just as much. netbiosd is a local-network process, not an internet one. NetBIOS name service is broadcast-based and confined to your local subnet — it does not route across the internet, and routers do not forward that traffic out to the wider world in normal operation. The fear that usually sits underneath this search, that some unknown daemon is quietly sending your data somewhere, does not apply. Whatever netbiosd is saying, it is saying to devices in your own home or office.

That distinction is worth carrying into any process investigation on macOS: a process listening on your local network and one maintaining a persistent connection to a remote server are doing very different things, and deserve different levels of scrutiny.

For most system daemons the honest advice is to allow and move on, because denying breaks something you rely on. netbiosd is one of the genuine exceptions, and it is worth a moment of thought rather than clicking through.

Ask yourself one question: do you ever connect to a Windows PC's shared folder, an older NAS box, or a network printer that relies on Windows-style browsing? If the answer is no — and for a lot of people with an all-Apple household it is no — then denying netbiosd costs you nothing you will notice. NetBIOS is legacy. Modern SMB discovery on Apple platforms leans on other mechanisms, and a network with no NetBIOS-dependent devices has nothing for netbiosd to talk to.

If the answer is yes, be more careful. Denying incoming connections can break discovery — the part where devices appear automatically in the Finder sidebar, or where a Windows machine spots your Mac. You can often still reach a share by connecting to it explicitly by name or address rather than waiting for it to be listed, so the failure mode is usually inconvenience rather than a hard block. If a printer or NAS suddenly stops showing up, this is a plausible cause, and reversing the decision in the firewall settings is straightforward.

There is also a cleaner option than fighting the prompt. Much of what netbiosd does is tied to Windows-compatible file sharing being switched on. If you enabled that once for a single transfer and never used it again, turning it back off in the sharing settings addresses the situation at the source.

Whatever you choose, choose it deliberately. The worst outcome is clicking Allow on a dialog you did not read, which is how most people end up with a firewall configuration nobody understands.

netbiosd is not unusual. A typical Mac runs dozens of background processes that touch the network — some talking to Apple, some announcing services locally, some maintaining connections on behalf of apps you installed and forgot about. The firewall prompt surfaces only the narrow subset that wants to accept incoming connections. Everything reaching outward stays invisible unless you go looking.

That asymmetry is the real problem. You get interrupted about a legacy naming daemon confined to your own subnet, while a process quietly maintaining a connection to a remote server never generates a dialog at all. Activity Monitor tells you a process exists and roughly how many bytes it moved, but not which domains it reached, and it offers no way to stop it short of killing it.

That visibility gap is what NetMute was built to close. It shows real-time per-app and per-process network traffic with domain-level logging, so instead of a process name and a byte count you see where each app is actually connecting. Its per-app firewall blocks anything with one click, and temporary rules expire on their own so a quick test does not silently become permanent. Network profiles apply different rules depending on which Wi-Fi network you are joined to, which helps when a trusted home network and an airport hotspot warrant different levels of caution.

The point is not to block more things. It is to answer the question that brought you here — what is this process and who is it talking to — without searching for the answer every time a new name appears.