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.

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 | taildirekt 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
id -u, bestätigen, dass du 0 bist.capsh --print | grep net_admin, die Capability bestätigen.ls -l /etc/wireguard/wg0.conf, Modus 600 und Besitzer root bestätigen.dmesg | tail -20unmittelbar 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→


