VPNSmith
Contabo-VPS
self-host-vpnINFO

WireGuard: Unable to Access Interface: Operation Not Permitted beheben

wg-quick bricht mit Unable to access interface: Operation not permitted ab, und der übliche Rat lautet, sudo davorzusetzen. Oft steht sudo aber schon da. Hinter der Meldung stecken vier verschiedene Ursachen, von einer fehlenden Capability im Container bis zu einer Konfigurationsdatei, die das Tool nicht lesen will, und jede hat ihre eigene Prüfung.

Von Eric Gerard · Gründer · VPNSmith - Spezialist für selbstgehostete VPNs & DSGVO-VPS5 Min. LesezeitFoto via Pexels

Affiliate-Hinweis - Dieser Artikel enthält Affiliate-Links zu Contabo. Wenn du darüber einen VPS bestellst, erhalten wir eine Provision, ohne dass dir zusätzliche Kosten entstehen.

Du führst wg-quick up wg0 aus, und es bleibt bei einer Zeile stehen:

Unable to access interface: Operation not permitted

Die erste Antwort, die du findest, lautet: sudo davorsetzen. Sehr oft steht sudo aber schon da, und der Befehl scheitert trotzdem. Genau dort bleiben die meisten hängen.

Was die Meldung eigentlich sagt

Operation not permitted ist EPERM, vom Kernel zurückgegeben, wenn wg versucht, das Interface über Netlink zu konfigurieren. Der Kernel wurde gefragt, und der Kernel hat Nein gesagt. Das ist eine engere Aussage, als es aussieht, und es lohnt sich, sie von zwei Fehlern abzugrenzen, mit denen sie gern verwechselt wird:

  • No such device heißt, das Interface ist nicht da. Anderes Problem.
  • Command not found oder ein Modulfehler heißt, dass die Tools oder das Kernelmodul fehlen. Ebenfalls etwas anderes.

Hier sind die Tools gelaufen, der Aufruf wurde abgesetzt, und die Berechtigung wurde auf Kernelebene verweigert. Die Frage ist also nicht "bin ich root", sondern "was blockiert diesen Aufruf sonst noch".

Ursache 1: Du bist tatsächlich nicht root

Mit einem Befehl auszuschließen, also kostet es nichts:

id -u

Steht da nicht 0 und hast du kein sudo benutzt, ist das deine Antwort. Gibt er 0 aus, geht es weiter. Beachte, dass sich sudo wg-quick up wg0 und sudo -E wg-quick up wg0 bei den Umgebungsvariablen unterschiedlich verhalten, aber keiner von beiden ändert etwas an den Capabilities weiter unten.

Ursache 2: Ein Container ohne CAP_NET_ADMIN

Das ist der häufige Fall, und sudo kann ihn nicht lösen. In einem Container kannst du uid 0 sein und trotzdem nicht die Capability besitzen, die Netzwerkverwaltung erlaubt. Root im Container ist nicht Root auf dem Host.

Prüfe, was du wirklich hast:

capsh --print | grep -i net_admin

Fehlt cap_net_admin im effektiven Set, lehnt der Kernel jedes Mal ab, egal ob mit sudo oder ohne. Für Docker:

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

Bei einem unprivilegierten LXC-Container reicht die Capability allein meist nicht, weil das tun-Gerät nicht sichtbar ist; das Gerät muss in der Container-Konfiguration durchgereicht werden. Dasselbe gilt, wenn der gemietete "Server" selbst ein Container ist: Bei VPS-Tarifen auf OpenVZ- oder LXC-Basis entscheidet der Kernel des Anbieters, was du darfst, und kein sudo auf deiner Seite fügt NET_ADMIN hinzu. Die Lösung ist dort eine KVM-Instanz, dazu mehr am Ende des Artikels. Läuft dein WireGuard bewusst in einem Container, wird das containerisierte Setup separat in WireGuard in Docker betreiben behandelt.

Ein Maschendrahttor, mit einer umwickelten Kette und zwei Vorhängeschlössern verschlossen, eines blassgelb und eines schwarz, dahinter durch das Gitter trockenes braunes Unkraut
Ein Maschendrahttor, mit einer umwickelten Kette und zwei Vorhängeschlössern verschlossen, eines blassgelb und eines schwarz, dahinter durch das Gitter trockenes braunes Unkraut

Wenn du lieber mit einer Container-Definition startest, die die richtigen Capabilities schon mitbringt: Die docker-compose-Vorlage in unserem WireGuard Self-Hosting Kit (9 USD, PDF + Markdown + fertige .conf-Dateien) deklariert cap_add: NET_ADMIN, SYS_MODULE und den Sysctl net.ipv4.ip_forward=1, wobei die Web-UI nur an die Tunneladresse gebunden ist. Das Kit enthält außerdem eine Checkliste mit 12 Ursachen für einen Tunnel, der zwar hochkommt, aber keinen Verkehr durchlässt. Alles auf dieser Seite bleibt kostenlos. Das Kit auf Gumroad ansehen.

Ursache 3: Die Konfigurationsdatei, die das Tool nicht liest

wg-quick liest /etc/wireguard/wg0.conf, bevor es das Interface anfasst. Zwei Probleme auf Dateiebene landen in der Nähe dieses Schritts:

ls -l /etc/wireguard/wg0.conf

Der Modus sollte 600 sein und der Besitzer root. Eine für alle lesbare Konfiguration mit privatem Schlüssel ist für sich schon ein echtes Problem, und wg-quick weist dich darauf hin. Eine Datei, die der aufrufende Benutzer nicht lesen kann, führt schon früher im Ablauf zum Fehler, vor jedem Netlink-Aufruf. Lies also die gesamte Ausgabe und nicht nur die letzte Zeile.

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

Ursache 4: Etwas oberhalb des Kernels sagt Nein

Bist du root, hast NET_ADMIN und ist die Datei sauber, dann schau, was sonst noch EPERM auf einen Netlink-Aufruf zurückgeben kann:

  • Ein Sicherheitsmodul. SELinux oder AppArmor im Enforcing-Modus können die Operation verweigern. dmesg | tail direkt nach dem fehlgeschlagenen Befehl ist der schnellste Weg, eine Ablehnung zu sehen, denn diese Module loggen dort, wo der Befehl schweigt.
  • Ein schreibgeschütztes oder eingeschränktes /sys. Manche gehärteten oder minimalen Umgebungen hängen es so ein, dass die Einrichtung des Interfaces blockiert wird.
  • Ein Syscall-Filter. Ein seccomp-Profil, das die betreffenden Aufrufe verwirft, erzeugt dieselbe errno ohne jeden weiteren Hinweis.
dmesg | tail -20

Erscheint nichts in dmesg, ist Ursache 4 unwahrscheinlich, und die Antwort ist fast sicher Ursache 2.

Die Reihenfolge zum Abarbeiten

  1. id -u, bestätigen, dass du 0 bist.
  2. capsh --print | grep net_admin, die Capability bestätigen.
  3. ls -l /etc/wireguard/wg0.conf, Modus 600 und Besitzer root bestätigen.
  4. dmesg | tail -20 unmittelbar nach dem Fehler, nach einer Ablehnung suchen.

Vier Befehle, und sie schließen die Ursachen in der Reihenfolge aus, in der sie sich am häufigsten als die richtige herausstellen.

Sobald das Interface hochkommt

Ein erfolgreiches wg-quick up ist noch kein funktionierender Tunnel. Existiert das Interface jetzt, aber nichts geht durch, bist du bei einer Routing- oder Handshake-Frage angekommen, nicht mehr bei einer Berechtigungsfrage: Die Handshake-Seite behandelt WireGuard-Handshake-Fehlerbehebung, und die Adressfehler, die direkt danach auftauchen, der Fehler bad address.

Für einen VPS, auf dem das alles laufen soll: Root und NET_ADMIN gibt es bei einer KVM-Instanz standardmäßig, ein Grund, sie den billigeren containerbasierten Angeboten vorzuziehen, bei denen genau dieses Problem eingebaut ist. Ein KVM-Gast läuft mit eigenem Kernel, wg-quick up fragt also einen Kernel, den du kontrollierst, nicht den des Anbieters. Die Cloud-VPS-Reihe von Contabo ist KVM-virtualisiert (laut contabo.com, geprüft am 18. Oktober 2026) und die, die wir für unsere eigenen Anleitungen nutzen; unsere Notizen zu den Alternativen stehen in der günstigste VPS für ein WireGuard-VPN.

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200-Mbit/s-Port

Ein KVM-VPS, auf dem Root wirklich Root ist → Contabo Cloud VPS 45,50 €/Monat (geprüft am 18. Okt. 2026, erste 24 Monate) · KVM, eigener Kernel, NET_ADMIN inklusive · 4 vCPU, 8 GB RAM, öffentliche IPv4→

★ Nürnberger DSGVO-Rechenzentrum · ✓ Dedizierte IPv4 inklusive · 200-Mbit/s-Port

Hoste dein VPN auf deinem eigenen VPS → ContaboVoller Root-Zugriff · öffentliche IPv4 · wähle deine Region→

Häufig gestellte Fragen

Warum meldet wg-quick Operation not permitted, obwohl ich sudo benutzt habe?
Weil sudo dir Root-Rechte gibt, Root aber nicht das Einzige ist, was geprüft wird. In einem unprivilegierten Container verweigert der Kernel den Netlink-Aufruf ohne CAP_NET_ADMIN trotzdem, und unter einer restriktiven LSM-Richtlinie oder mit schreibgeschütztem /sys scheitert derselbe Aufruf auch für Root. Die Meldung gibt die Ablehnung durch den Kernel wieder, nicht das Fehlen von sudo.
Was bedeutet Operation not permitted hier eigentlich?
Es ist errno EPERM, das der Kernel zurückgibt, wenn wg versucht, das Interface über Netlink zu konfigurieren. Etwas im Kernel hat entschieden, dass dieser Prozess das Interface nicht anfassen darf. Das ist etwas anderes, als wenn das Interface nicht existiert (dann kommt stattdessen ein Fehler no such device).
Wie behebe ich das in Docker oder LXC?
Gib dem Container NET_ADMIN und Zugriff auf /dev/net/tun. Bei Docker ist das --cap-add NET_ADMIN --device /dev/net/tun. Bei einem unprivilegierten LXC-Container musst du in der Regel das tun-Gerät in der Container-Konfiguration durchreichen, weil die Capability allein nicht reicht.
Kann eine falsche Dateiberechtigung der Konfiguration das auslösen?
Sie kann an derselben Stelle zu einer Ablehnung führen, ja, aber der Wortlaut hängt von der Version ab. wg-quick warnt, wenn /etc/wireguard/wg0.conf für alle lesbar ist, und eine Datei, die der aufrufende Benutzer gar nicht lesen kann, scheitert schon früher. Prüfe, ob der Modus 600 und der Besitzer root ist, bevor du weitersuchst.
Heißt dieser Fehler, dass WireGuard nicht installiert ist?
Nein. Ein fehlendes Kernelmodul oder fehlende Tools erzeugen andere Fehler, typischerweise eine Meldung module not found oder command not found. Operation not permitted bedeutet, dass die Tools gelaufen sind und der Kernel die Anfrage abgelehnt hat.