Repository navigation
Host outbound ENOBUFS during NNTP downloads; OrbStack involvement unconfirmed (2.2.5 / macOS 27.0.1) #2776
Description
Observed failure
On 2026-10-30 around 20:02–20:12 (UTC+1), starting high-concurrency SABnzbd downloads coincided with host outbound networking failures. Native cloudflared repeatedly logged sendmsg: no buffer space available while creating QUIC connections, all tunnels disconnected, and SSH/Tailscale became unreliable. Other devices on the LAN kept working. OrbStack vmgr also logged failures creating outbound TCP forwarding endpoints.
OrbStack ownership and global mbuf exhaustion are unconfirmed. We did not capture pool/queue statistics during the original outage. In particular, UDP ENOBUFS alone cannot distinguish global allocation pressure from an interface/output-queue problem.
The machine subsequently suffered an Apple NFS recovery kernel panic and rebooted. Matching installed kernel/NFS UUIDs identify nfs_recover -> vnode_mount(NULL). That crash was reported privately to Apple; it does not establish who caused the preceding network failure.
Environment
- OrbStack 2.2.5 (2020500), release commit
bf842321f95fc3ca7cda3227bf0cd41cb188c471 - macOS 27.0.1 (26A434), Mac16,10 / M4 Mac mini, 16 GiB RAM
- Ubuntu noble arm64 OrbStack machine, Docker inside it
- SABnzbd 5.1.3, linuxserver image
- 26 enabled NNTP server entries, 273 configured TLS connections; later native/VM socket captures both confirmed 273 established IPv4 connections
- About 240 MiB/s download throughput; no configured speed limit
- Linux-local incomplete directory; completed data on a NAS over Linux NFSv4.1. Native Plex also uses a separate macOS NFSv4.1 mount to that NAS
- OrbStack memory limit 8192 MiB,
network_bridge=true,network_proxy=auto - USB Realtek 0bda:8157 Ethernet adapter, 2500Base-T, MTU1500; Wi-Fi also connected, default route on Ethernet
kern.ipc.nmbclusters=131072; hundreds of sockets and only 73 TIME_WAIT sockets before the panic, so this does not resemble macOS tcp_now overflow after 49.7 days causes TIME_WAIT exhaustion #2665- Before the failure the Mac had about 26 days uptime and the VM about 4 days; no uptime-related defect has been established
Reproduction status and controlled tests
No reliable outage reproducer remains after the kernel panic/reboot. All tests below use official SAB test NZBs and the same providers. Temporary native/fresh VM processes use separate private configurations and test directories; the normal downloader is paused/disconnected during controls.
| Control | Result | Peak active mbufs / cluster bytes |
|---|---|---|
| Original VM SAB, local disk, 10 GB, no unpacking | Download progressed essentially to completion; bounded test stopped at 60s; no outage | 43,825 / 90,378,240 |
| Native SAB, local disk, 10 GB, OrbStack fully stopped | Completed, about 243 MiB/s; no outage | 15,366 / 31,494,144 |
| Native SAB, five 1 GB jobs, NAS direct unpack, OrbStack stopped | All five completed; no outage | 7,517 / 16,478,208 |
| Fresh SAB process in existing VM/container, same NAS batch | All five completed, 117 direct-unpacked volumes; no outage | 6,749 / 9,228,288 |
Fresh VM NAS batch with original pre_check=1 |
All five completed; no outage | 7,499 / 15,325,184 |
| Fresh VM, two 10 GB jobs, NAS, precheck enabled, 180s limit | Both downloaded; one NAS copy completed, second still moving at timeout; no outage | 7,076 / 9,076,736 |
| Native receiver intentionally SIGSTOPed for 3s during download, OrbStack stopped | Resumed and drained normally; no loopback/gateway UDP send errors | 65,607 / 147,804,160 |
During the longer VM NAS test, interface-bound HTTPS and UDP-send probes on Ethernet and Wi-Fi remained healthy. The finite recorder captured 90 samples with no UDP send errors and no HTTPS failures.
The earlier guarded local-disk observation at 37–40k active mbufs was not an outage reproduction. Native receiver stalling exceeded those counts without failure, so buffer growth alone is not evidence of an OrbStack bug or persistent leak. One later telemetry sample also contained an impossible wrapped cluster counter (4294967293 active against 7632 allocated); that run was rejected and repeated, not treated as exhaustion.
Negative fresh-state controls do not reconstruct the old host/driver/VM state. The original outage remains real, but its owner is unresolved. The older I/O deadlock #2474 was fixed in 2.2.0 and has not been assumed to be this defect. A temporary 40 MiB/s cap briefly restored responsiveness before the panic, but is not a verified workaround.
Requested investigation
Is there a supported forwarding/backpressure or interface-flow-control capture that would distinguish an OrbStack contribution from a macOS/driver failure on recurrence? I cannot justify a forwarding patch from the present evidence. Please treat this as an unconfirmed incident report rather than a proven forwarding-buffer defect.
Private diagnostic report
Generated after restoration of the original configuration; includes persistent OrbStack logs from the outage:
https://orbstack.dev/_admin/diag/orbstack-diagreport_2026-10-30T19-37-08.057597Z.zip
All disposable test processes, copied credential files and test NAS data have been removed. The normal 273-connection configuration, queue state and startup agent are restored; SABnzbd and Radarr respond with HTTP200.
Activity
[-]High-concurrency NNTP downloads exhaust host network mbufs and break connectivity (2.2.5 / macOS 27.0.1)[/-][+]Host outbound ENOBUFS during NNTP downloads; OrbStack involvement unconfirmed (2.2.5 / macOS 27.0.1)[/+]olipayne commentedon Oct 30, 2026
Investigation update: I have rewritten the report around the completed native/VM controls and corrected the title. The original host ENOBUFS outage is confirmed, but the 37–40k-mbuf guarded observation was not a failure reproducer. Native receiver stalling with OrbStack completely stopped reached 65k mbufs without an outage, and both native and VM NAS pipelines passed after the reboot. A further 180-second VM test downloaded two 10 GB jobs without network errors; the second NAS copy was still moving at the timer limit.
I am leaving this open as an unconfirmed incident, not claiming an OrbStack fix or exoneration. The reboot changed the failing state. UDP ENOBUFS can also arise from interface flow control (see Apple's
FADV_FLOW_CONTROLLED/FADV_SUSPENDEDhandling in https://github.com/apple-oss-distributions/xnu/blob/f6217f891ac0bb64f3d375211650a4c1ff8ca1ea/bsd/netinet/udp_usrreq.c), so a full-pool claim is not supported by the available capture. Any maintainer guidance for collecting the relevant forwarding/interface state on recurrence would be useful.