What Is netbiosd on Mac? I Sent It 570,000 Queries

netbiosd is the macOS daemon that speaks NetBIOS, the old Windows naming protocol. It registers a NetBIOS name for your Mac, answers when another machine on the network asks for that name, and collects the names of Windows PCs and NAS boxes it hears so Finder can show them. It does this on UDP ports 137 and 138, and it runs whether or not you have File Sharing turned on.

On my Mac mini it had been running for 12 days and used 26.65 seconds of CPU in that time. That is about 2.2 seconds a day, 0.0025% of one core, rank 222 of 685 processes. Then I sent it 570,000 name queries over about six minutes. It answered every query I waited for in about 0.05 ms, it logged nothing, and its memory went from 5.7 MB to 40.7 MB, above the 30 MB limit launchd sets for it. Eight minutes later it was still at 40.0 MB.

The rig is a Mac16,10 (M4, 16 GB) on macOS 26.4.1 (25E253), headless, on Wi-Fi, with File Sharing off and the macOS firewall off. Everything below was measured on 2026-10-24 as an admin user without sudo.

What netbiosd is

$ ps -axo pid,user,etime,time,rss,comm | grep netbios
45391 _netbios  12-04:21:55   0:26.65   5712 /usr/sbin/netbiosd

It runs as its own user, _netbios, not as root and not as you. It is a system LaunchDaemon (/System/Library/LaunchDaemons/com.apple.netbiosd.plist), and if the agent and daemon split is new, LaunchAgent vs LaunchDaemon covers it. The binary is 888 KB and its version string says PROJECT:smbx-666.100.1, so it ships as part of Apple's SMB stack. The plist explains most of its behavior:

• launchd owns the sockets. The plist declares two UDP sockets on 0.0.0.0, netbios-ns (137) and netbios-dgm (138), IPv4 only. netstat -an -p udp shows both listening.
• It lives as long as you have a default route. A com.apple.reachability event keeps it alive while 0.0.0.0 is reachable. The binary contains the message "network is not reachable, netbiosd is shutting down". launchctl print says runs = 4 in 26 days of uptime, and this copy started 12 days ago, so it has been stopped and started three times, which fits the Wi-Fi dropping.
• It is kept small and quiet. Nice 20, LowPriorityIO, a jetsam memory limit of 30 MB (marked "soft") and a thread limit of 32.

The netbiosd(8) man page says it "registers and defends one or more NetBIOS name, depending on the set of configured services" and "browses and scavenges names from the NetBIOS network, making them available to the system through mDNSResponder". That second part is the link to mDNSResponder: NetBIOS names found on the LAN are handed to the same resolver that handles Bonjour.

The name it uses is not your computer name

My Mac's local hostname is Mindfului-Macmini. Its NetBIOS name is MAC-D39169, from /Library/Preferences/SystemConfiguration/com.apple.smb.server.plist:

$ defaults read /Library/Preferences/SystemConfiguration/com.apple.smb.server
{
    DOSCodePage = 949;
    NetBIOSName = "MAC-D39169";
    ServerDescription = "Mindful\\Uc758 Mac\\U00a0mini";
}

NetBIOS names are limited to 15 characters plus a one-byte type suffix. I asked netbiosd for 28 combinations: four names (the NetBIOS name, the hostname, WORKGROUP and __MSBROWSE__) with seven suffixes each. It answered exactly one, MAC-D39169<00>, the plain workstation name. There was no <20> file server name because File Sharing is off. Turn it on and that is the name a Windows PC would look up. For every other name it sent nothing back, not even a negative reply.

What 570,000 queries cost it

My LAN tests failed. This shell is not allowed to talk to the local network, so smbutil lookup MAC-D39169 returned "No route to host" and a broadcast query got nothing. Loopback is not blocked, so I wrote a 30-line Python script that builds a NetBIOS name query packet and sends it to 127.0.0.1:137. Before and after each run I read netbiosd's CPU time and memory with ps, which works for other users' processes without sudo. One detail: a query sent to 127.0.0.1 came back from 192.168.20.34, the Wi-Fi address, with that address in the answer and a TTL of 0x7fffffff seconds.

Run	Queries	Answered	netbiosd CPU	Per query	Memory (RSS) after
12 days of normal use (before the test)			26.65 s		5.7 MB
Correct name, one at a time	50,000	50,000	+2.03 s	41 µs	5.7 MB
Unknown name, as fast as possible	50,000	0	+0.73 s	15 µs	5.8 MB
Correct name, as fast as possible	50,000	29,412	+1.29 s	26 µs	15.1 MB
Correct name, as fast as possible	200,000	92,540	+4.78 s	24 µs	40.3 MB
Correct name, as fast as possible	200,000	92,993	+4.75 s	24 µs	40.7 MB
Correct name, one at a time	20,000	20,000	+0.85 s	43 µs	40.7 MB

Four things stood out.

It is fast when queries are paced. Waiting for each answer before sending the next, I got 17,600 answers a second. The median round trip was 0.051 ms and the 99th percentile 0.098 ms, and every query was answered.

Flooding lost answers, but mostly on my side. At 130,000 queries a second my script received 46% to 59% of the answers. netbiosd's own counters say it sent more. nettop, which reads per-process network counters without sudo, showed netbiosd with 0.86 MB sent in its first 11 days and 500,450 packets sent after the test. Its first 11 days account for at most about 14,000 of those, so the 520,000 queries for my name got roughly 486,000 to 500,000 replies. My script received 285,000. netbiosd answered at least 93% of them, and my script's receive buffer overflowed. Unknown names cost it 15 µs each to read and ignore, about a third of an answered query.

Memory went up and stayed up. The first flood took it from 5.8 MB to 15.1 MB, the second to 40.3 MB. The third added only 0.4 MB, so it is a high-water mark, not a leak that grows with every packet. But it did not come back down. Eight minutes after the last run it was still at 40.0 MB. That is a third over the 30 MB jetsam limit, and nothing happened: same PID, runs = 4, no crash report. "Soft" seems to mean the limit is not enforced while the Mac has free memory.

It logged nothing. log show --process netbiosd returned 0 lines for the 24 hours before the test and 0 lines during it. The binary has counters like "%llu packets netbiosd discarded in the last %u secs", but none of them reached the log. If netbiosd misbehaves on your Mac, the unified log will not tell you why unless you turn on debug logging (the man page says SIGUSR1 toggles it, which needs root).

In total the test cost netbiosd 14.54 CPU seconds, about 6.6 days of its normal use, spent in under 8 seconds of actual sending. Afterwards it still answered every paced query.

When netbiosd uses high CPU

The reports are rarer than for most daemons I have looked at. I found two Apple Developer Forums threads and a Jamf Nation thread worth reading:

• In a 2017 thread, an admin at a university with "thousands of users" said netbiosd was "chewing up 1-50% CPU usage all day, everyday" on most of their Macs, which they blamed on NetBIOS broadcasts. The only reply, from Apple DTS, pointed them to Apple Support Communities.
• In a 2022 thread, a developer reported netbiosd going above 100% CPU after restarting a network system extension that filtered UDP traffic. A second developer saw the same on Monterey 12.4. Apple DTS called it a bug (FB9915482) and said "We're not aware of any reasonable workaround."
• In a 2015 to 2016 Jamf Nation thread, admins tried to turn NetBIOS off and kept getting "Could not find specified service", including one running as root. More on that error below.

My numbers put the first report in context. On my LAN, which has about 50 entries in the ARP table, netbiosd received 15 packets (1,170 bytes) in a two-minute sample with no test running, and sent none. Over its first 11 days it received 32.9 MB. At 24 to 41 µs per packet, using 50% of a core would take roughly 12,000 to 20,000 NetBIOS packets a second, every second, about 100,000 times what my network sends it. That is my estimate from loopback queries, and broadcast browse traffic may cost more per packet than a name query. Still, even a large campus network rarely sends that much NetBIOS. When netbiosd sits at tens of percent for hours, a loop like the one in FB9915482 is the more likely cause than plain traffic volume.

How to disable netbiosd

You only need netbiosd if something finds your Mac, or you find a Windows PC or NAS, by NetBIOS name. Bonjour and DNS do not depend on it, and most current NAS boxes advertise over Bonjour as well (for a NAS, the SMB and Samba versions matter far more than NetBIOS, as I found in which NAS works best with Mac). Turning it off means Windows machines that rely on NetBIOS name lookup may not find your Mac by name, and NetBIOS-only devices can disappear from Finder's sidebar, as one Jamf poster noted.

Apple's support article How to disable SMB 1 or NetBIOS in macOS gives this command:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist
# check: no output means it is not running
sudo ps aux | grep -i netbiosd | grep -v grep
# undo
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist

I did not run it. This session has no sudo, and I would rather not take a network service off a remote machine to prove a point. Three things I could check without root:

1. The label is com.apple.netbiosd, not netbiosd. The Jamf thread's fix for 10.10 and later was sudo launchctl disable system/netbiosd. On my Mac, launchctl print system/netbiosd says Could not find service "netbiosd" in domain for system, while system/com.apple.netbiosd prints the running service. If you use launchctl disable, the target is system/com.apple.netbiosd.
2. The plist itself cannot be edited. It sits on the sealed, read-only system volume, flagged restricted, with SIP enabled. That is why the 2017 admin got "Operation not permitted while System Integrity Protection is engaged". Any disable has to go through launchd's own override list, not through the file.
3. port445=no_netbios is a different switch. The same Apple article adds that line to /etc/nsmb.conf. It controls whether your Mac's SMB client falls back to NetBIOS when it connects out. It does not stop netbiosd. My Mac has no /etc/nsmb.conf at all, which is the default.

If netbiosd is using CPU and you can't or don't want to disable it, look for what sits in front of UDP 137 and 138. A network filter, VPN or firewall that restarts is the one cause with an Apple bug number.

FAQ

What is netbiosd on Mac?

netbiosd is the macOS NetBIOS daemon. It registers a NetBIOS name for the Mac (such as MAC-D39169), answers NetBIOS name queries from other machines on UDP port 137, and collects the names of Windows PCs and NAS devices it hears so they can be resolved through mDNSResponder and shown in Finder. It is a system LaunchDaemon that runs as the _netbios user. On a Mac mini that had been up 12 days it used about 2.2 seconds of CPU a day and 5.7 MB of memory.

Is it safe to disable netbiosd?

Yes, if nothing on your network relies on NetBIOS names. Apple documents disabling it with sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.netbiosd.plist and re-enabling it with the matching load -w command. After that, Windows machines that use NetBIOS name lookup may not find the Mac by name, and NetBIOS-only devices may disappear from Finder's sidebar. Bonjour and DNS keep working.

Why is netbiosd using so much CPU?

Normal NetBIOS traffic costs very little. In a test it used 24 to 41 microseconds of CPU per query, so reaching 50% of a core would take more than 10,000 packets a second. Reported cases of netbiosd at 50% to over 100% CPU point to a loop instead, including an Apple-acknowledged bug (FB9915482) triggered by restarting a network extension that filters UDP traffic. Restarting the filter, VPN or firewall, or disabling netbiosd, are the options.

Measurements come from one Mac16,10 on macOS 26.4.1, read without sudo on 2026-10-24: the launchd plist and launchctl print, the SMB server preferences, strings on /usr/sbin/netbiosd, the man page, ps CPU and memory for netbiosd and 684 other processes, nettop packet and byte counters (including a reading from 2026-10-23 taken for my mDNSResponder post and a two-minute idle sample), and 570,000 NetBIOS name queries I sent to it over loopback with my own script. LAN queries were blocked for this shell, so nothing here was measured on the network, and the per-packet cost of real broadcast traffic may differ from loopback queries. The CPU-per-second estimate in the high-CPU section is my arithmetic from those numbers. The CPU reports and disable attempts are from two Apple Developer Forums threads and one Jamf Nation thread, not my measurements, and I did not run the sudo commands. netbiosd kept the roughly 40 MB it reached during the test; it will reset the next time the network drops and launchd restarts it.