WireGuard: Unable to Access Interface: Operation Not Permitted

Affiliate disclosure - This post contains Contabo affiliate links. If you grab a VPS through them, we earn a commission at no extra cost to you.

You run wg-quick up wg0 and it stops on one line:

Unable to access interface: Operation not permitted

The first answer you will find is to add sudo. Very often sudo is already there, and the command still fails, which is where most people get stuck.

What the message is reporting

Operation not permitted is EPERM, returned by the kernel when wg tries to configure the interface over netlink. The kernel was asked, and the kernel said no. That is a narrower statement than it looks, and it is worth separating from two errors people confuse it with:

• No such device means the interface is not there. Different problem.
• Command not found or a module error means the tooling or the kernel module is missing. Also different.

Here the tooling ran, the call was made, and permission was denied at the kernel level. So the question is not "am I root", it is "what else is gating this call".

Cause 1: you genuinely are not root

Worth eliminating in one command, because it is free:

id -u

If that is not 0 and you did not use sudo, that is your answer. If it prints 0, move on. Note that sudo wg-quick up wg0 and sudo -E wg-quick up wg0 behave differently with respect to the environment, but neither changes the capability picture below.

Cause 2: a container without CAP_NET_ADMIN

This is the common one, and sudo cannot fix it. Inside a container you can be uid 0 and still lack the capability that authorises network administration. Root in a container is not root on the host.

Check what you actually hold:

capsh --print | grep -i net_admin

No cap_net_admin in the effective set means the kernel will refuse, every time, regardless of sudo. For Docker:

docker run --cap-add NET_ADMIN --device /dev/net/tun ...

For an unprivileged LXC container, the capability alone is usually not sufficient because the tun device is not exposed; the device has to be passed through in the container configuration. If your WireGuard lives in a container by design, the containerised setup is covered separately in running WireGuard in Docker.

Cause 3: the config file the tool will not read

wg-quick reads /etc/wireguard/wg0.conf before it touches the interface. Two file level problems land near this step:

ls -l /etc/wireguard/wg0.conf

The mode should be 600 and the owner root. A world readable config holding a private key is a real problem in its own right, and wg-quick will tell you about it. A file the invoking user cannot read produces a failure earlier in the run, before any netlink call, so read the whole output rather than the last line.

chmod 600 /etc/wireguard/wg0.conf
chown root:root /etc/wireguard/wg0.conf

Cause 4: something above the kernel is saying no

If you are root, hold NET_ADMIN, and the file is clean, look at what else can return EPERM on a netlink call:

• A security module. SELinux or AppArmor in enforcing mode can deny the operation. dmesg | tail right after the failed command is the fastest way to see a denial, because these log where the command does not.
• A read-only or restricted /sys. Some hardened or minimal environments mount it in a way that blocks the interface setup.
• A syscall filter. A seccomp profile that drops the relevant calls produces the same errno with no other clue.

dmesg | tail -20

If nothing appears in dmesg, cause 4 is unlikely and the answer is almost certainly cause 2.

The order to work through

1. id -u, confirm you are 0.
2. capsh --print | grep net_admin, confirm the capability.
3. ls -l /etc/wireguard/wg0.conf, confirm mode 600 and root ownership.
4. dmesg | tail -20 immediately after the failure, look for a denial.

Four commands, and they eliminate the causes in the order of how often they turn out to be the one.

Once the interface comes up

A successful wg-quick up is not the same as a working tunnel. If the interface now exists but nothing passes, you have moved on to a routing or handshake question, not a permissions one: the handshake side is covered in WireGuard handshake troubleshooting, and the address level errors that show up right after in the bad address error.

For a VPS to host all of this on, root and NET_ADMIN come as standard with a KVM instance, which is a reason to prefer one over the cheaper container based offers where exactly this problem is built in. Our notes on picking one are in the cheapest VPS for a WireGuard VPN.