Arch Linux User Repository

Hi @tarball, I'm from the NetBird team.

This socket path mismatch has been fixed upstream. The CLI, UI, and SSH client now auto-discover the daemon socket when the default /var/run/netbird.sock doesn't exist - they scan /var/run/netbird/*.sock and use it if exactly one is found. So netbird@main.service will work out of the box without needing --daemon-addr or NB_DAEMON_ADDR.

The fix is in https://github.com/netbirdio/netbird/commit/ef82905526a5944e9aac96e04b8b7ee67d27c9b9. It's included as of v0.66.

.. to upstream systemd units instead of those that came with the package previously.

The package itself is still in the AUR. There was some interest in adopting it into extra a couple of years ago, but nothing came of it.

If/when it gets merged into official repositories, this AUR package will quickly disappear.

@tarball You said the package has been moved to upstream but pacman -Ss is not returning a result and the arch wiki netbird page is pointing to this aur for the install.

It seams the temp. Go 1.26 patch is not needed anymore.

Great, thank you. There's nothing really for me to do since this package has been moved to upstream configs months ago. I'll pin your comment for visibility.

Hi @tarball, I'm from the NetBird team.

This socket path mismatch has been fixed upstream. The CLI, UI, and SSH client now auto-discover the daemon socket when the default /var/run/netbird.sock doesn't exist - they scan /var/run/netbird/*.sock and use it if exactly one is found. So netbird@main.service will work out of the box without needing --daemon-addr or NB_DAEMON_ADDR.

The fix is in https://github.com/netbirdio/netbird/commit/ef82905526a5944e9aac96e04b8b7ee67d27c9b9. It's included as of v0.66.

There's no such socket because the daemon is started with a templated unit and the path is unpredictable (it depends on how you named the unit); you should set it yourself:

netbird status --daemon-addr unix:///var/run/netbird/main.sock

or with an env var:

export NB_DAEMON_ADDR=unix:///var/run/netbird/main.sock

netbird status

Or you can rewrite the unit with an override; here's an example.

I really wish they'd fix this mismatch already. It causes similar issues with netbird-ui.

I cannot use netbird CLI command:

❯ netbird status 2026-01-25T09:49:23+01:00 INFO ./caller_not_available:0: 2026/01/25 09:49:23 WARNING: [core] [Channel #1 SubChannel #2] grpc: addrConn.createTransport failed to connect to {Addr: "/var/run/netbird.sock", ServerName: "localhost", Attributes: {"<%!p(networktype.keyType=grpc.internal.transport.networktype)>": "unix" }, }. Err: connection error: desc = "transport: Error while dialing: dial unix /var/run/netbird.sock: connect: no such file or directory" 2026-01-25T09:49:24+01:00 INFO ./caller_not_available:0: 2026/01/25 09:49:24 WARNING: [core] [Channel #1 SubChannel #2] grpc: addrConn.createTransport failed to connect to {Addr: "/var/run/netbird.sock", ServerName: "localhost", Attributes: {"<%!p(networktype.keyType=grpc.internal.transport.networktype)>": "unix" }, }. Err: connection error: desc = "transport: Error while dialing: dial unix /var/run/netbird.sock: connect: no such file or directory" ^C

netbird@main.service is running:

❯ sudo systemctl status netbird@main.service ● netbird@main.service - Netbird Client (main) Loaded: loaded (/usr/lib/systemd/system/netbird@.service; enabled; preset: disabled) Active: active (running) since Sun 2026-01-25 09:48:24 CET; 33min ago Invocation: 906f314b113f43cbb2bf6ac0c1435cb2 Docs: https://netbird.io/docs Main PID: 1194 (netbird) Tasks: 15 (limit: 9222) Memory: 77.5M (peak: 79.8M) CPU: 5.943s CGroup: /system.slice/system-netbird.slice/netbird@main.service └─1194 /usr/bin/netbird service run --log-file /var/log/netbird/client-main.log --daemon-addr unix:///var/run/netbird/main.sock

Jan 25 09:48:24 eliza systemd[1]: Started Netbird Client (main).

Why is error message pointing to socket /var/run/netbird.sock? This file does not exist.

Thanks, fixed. Let me know if it breaks again; I'll be testing chroot builds after each “major” release, but doing that for patch releases is too much, considering how frequent they are.