Cannot check incus info but able to connect VM

Incus
1

Hi all,

I’ve suddenly lost access to the IncusOS management API on a single-NIC homelab host and would appreciate a sanity check on the diagnosis before I crack the case open and plug in a monitor.

Setup

  • IncusOS host on a single physical NIC enp6s0, configured with the instances role only (host has a LAN IP, call it <HOST_IP>/24).
  • One VM balina on the LAN bridge at <VM_IP>, plus other clients on the same physical LAN.
  • This was working previously; I don’t know what changed (possible auto-update / reboot in between).

Symptom

From any client (the VM, or a MacBook on the same physical LAN):

$ incus config show | grep https_address
Error: Get "https://<HOST_IP>:8443/1.0": Unable to connect to: <HOST_IP>:8443 ([dial tcp <HOST_IP>:8443: connect: no route to host])

Same error for incus admin os ... — which makes sense, since those also go through the API.

What I’ve ruled out

L2/L3 reachability is fine from both sources:

From balina (VM, on the bridge):

$ ping -c2 <HOST_IP>
2 packets transmitted, 2 received, 0% packet loss
rtt avg 0.110 ms

$ ip neigh | grep <HOST_IP>
<HOST_IP> dev enp5s0 lladdr <HOST_MAC> REACHABLE

From MacBook (en0, same physical LAN):

$ ping -c2 <HOST_IP>
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip avg 9.002 ms

$ route -n get <HOST_IP>
interface: en0

So ARP resolves, ICMP echo works fine, both ends are clearly on the same L2 segment. The connect: no route to host from a TCP SYN therefore points to EHOSTUNREACH — meaning the host is sending back an ICMP destination-unreachable in response to the SYN, not silently dropping and not RST-ing.

Hypotheses

I’ve narrowed this to two:

  1. incusd isn’t actually bound to <HOST_IP>:8443 (after a reboot/upgrade), and the system is responding to traffic on unbound ports with ICMP reject rather than TCP RST. Vaguely similar to this report on regular Incus where toggling core.https_address post-reboot is needed to force a re-bind.
  2. An nftables rule is rejecting tcp dport 8443 with icmp host-prohibited / host-unreachable. I know IncusOS doesn’t ship user-facing firewalling yet (issue #528), but maybe Incus’ own bridge-management rules are catching this.

Questions

  • Is there any known issue where the API listener fails to come up after a reboot or auto-update on IncusOS? Anything I should look at first when I get to the console?
  • Is there a recovery path that doesn’t require physical console access? Any management interface on a different port that bypasses the broken :8443?
  • Does enp6s0 having only the instances role (no management) materially change anything about how/where the API is exposed? My understanding is the host’s IP still ends up on the bridge IncusOS auto-creates, and ICMP confirms that’s the case, but I want to rule out a misconfiguration here.

Thanks!

2

No route to host is definitely unexpected… If it was just a case of Incus not running or not listening on the port, I would expect to see Connection refused.

1 Like
3

I found the issue, i think apple started to block local network access without putting sudo in front of all commands. I found this command useful to completely remove sudo requirement

`tccutil reset All com.googlecode.iterm2` after this, restarting iterm2 and allowing local network access from terminal fixes the issue.

4

Just had a similar issue here (not with incus, but being unable to ping other hosts on local network).

Solution in this thread worked: System Settings::Privacy & Security::Local Network and turn on local network access for iterm2 (there’s one slider button per app)