Tailscale Snap loses network access after snapd 2.77.1 refresh (AppArmor send denials)

This report concerns the Canonical-maintained Tailscale Snap and snapd. It is shared here so the Tailscale team is aware of the outage; the root cause appears to be in snapd/AppArmor rather than the Tailscale client.

Environment

• Ubuntu 24.04.4 LTS, arm64, NVIDIA DGX Spark
• Kernel 6.17.0-1021-nvidia
• Tailscale snap 1.102.3, revision 168 (not refreshed during this incident)
• snapd 2.77.1, revision 28255, installed by automatic refresh on 2026-09-29 at 22:11 CEST
• Reverted to snapd 2.76.3, revision 27740, on 2026-09-30 at 10:46 CEST

Observed behavior

The first AppArmor denial found was at 2026-09-29 22:51:38 CEST. The kernel rejected outbound send operations by snap.tailscale.tailscaled for UDP DNS and TCP HTTPS traffic. A representative redacted entry:

apparmor="DENIED" operation="file_perm" class="net"
profile="snap.tailscale.tailscaled" comm="tailscaled"
family="inet" requested="send" denied="send"

The generated Tailscale profile contained network inet, and network inet6,. Its network, network-bind, network-control, and firewall-control interfaces were connected. Host-level DNS and HTTPS still worked. Tailscale could not reach the control plane; tailscale status eventually showed logged out / NoState. Restarting the Tailscale snap on 2026-09-30 at 09:20 did not resolve the problem. The new daemon process continued to receive denials.

At 10:46 CEST, sudo snap revert snapd restored snapd 2.76.3. The snapd log stated that existing Snap AppArmor profiles were discarded. Without reinstalling Tailscale or signing in again, tailscaled reported loggedIn=true at 10:46:44 and Running at 10:46:45. No further Tailscale send denials were found after 10:47.

Expected behavior

A snapd refresh preserves the connected Tailscale snap's outbound network access.

Actual behavior

AppArmor rejected outbound sends from tailscaled, disconnecting the node from its tailnet.

Workaround

sudo snap revert snapd
tailscale status

Question for maintainers

Could a change in snapd 2.77.1's AppArmor profile generation, loading, or replacement explain send denials despite network inet and network inet6 in the generated profile? The successful rollback strongly implicates this path; the precise defect has not been isolated.

This is one observed incident with a successful rollback. We have not deliberately reinstalled snapd 2.77.1 to reproduce it. The refresh log shows revision 27709 being made unavailable, while the later revert activated revision 27740; we have preserved that unusual sequence rather than inferring an exact revision-to-revision transition.

Before attaching further logs, remove hostnames, usernames, tailnet domains, private/public IP addresses, and authentication data.