You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
OrbStack crashes when internet connection drops briefly #2322
After that the VM stayed in Stopped state until I manually ran orb start — several hours of downtime for every container on the host.
A few things that might help narrow it down:
At the time this started, the host had ~70 network interfaces total (46 veth, 13 br-*) — nowhere near any real kernel limit, consistent with the other report here of it happening at just 14 interfaces. So tooManyInterfaces looks like a bug in the agent's own interface accounting, not an actual resource exhaustion.
I checked macOS's configd logs (via log show) around both error timestamps and found no interface/connectivity state change — no Wi-Fi drop, no DHCP renewal, nothing. So at least in this case it doesn't look like it needs an actual "internet connection drop" to trigger; it may be firing on its own periodic reconciliation.
No crash-looping containers, no VPN/gluetun container running here, restart counts were all 0 except one unrelated container with 1 restart — so it's not caused by container churn on my end either.
Activity
paunadeu commentedon Mar 18, 2026
Happening here too.
Disconnected mount popup is also appeaing
ericmeadows commentedon Mar 31, 2026
Same!
kdrag0n commentedon May 23, 2026
Fixed for the next version.
kdrag0n commentedon Jun 4, 2026
Released in v2.2.0.
kaloona commentedon Aug 30, 2026
I hit this on OrbStack v2.2.3 (Docker 29.4.0), so whatever landed for the v2.2.0 milestone doesn't fully fix it.
Sequence from
~/.orbstack/log/vmgr.loglast night:(repeats identically every few seconds for ~30 min, across every network on the host, not just one)
It escalated into a full VM crash:
After that the VM stayed in
Stoppedstate until I manually ranorb start— several hours of downtime for every container on the host.A few things that might help narrow it down:
tooManyInterfaceslooks like a bug in the agent's own interface accounting, not an actual resource exhaustion.configdlogs (vialog show) around both error timestamps and found no interface/connectivity state change — no Wi-Fi drop, no DHCP renewal, nothing. So at least in this case it doesn't look like it needs an actual "internet connection drop" to trigger; it may be firing on its own periodic reconciliation.Happy to share the full vmgr.log if useful.
JackCA commentedon Sep 11, 2026
Happening here as well