Can't use systemctl to start wireguard interface in Fedora 38

In Fedora 37 I was able to have systemctl automatically enable my wireguard interface by simply putting a valid wg0.conf file in /etc/wireguard/ and then running sudo systemctl enable wg-quick@wg0.service

Since upgrading to Fedora 38, i get this error in the journal when systemctl tries to start wg-quick@wg0.service:

[#] nft -f /dev/fd/63
internal:0:0-0: Error: Could not open file "/dev/fd/63": Permission denied

I can still start the wireguard interface using wg-quick up wg0, but I can’t do automatically with systemctl.

Does anyone know why?

On Fedora, it is best to configure WireGuard with NetworkManager:

nmcli connection import type wireguard file /path/to/wg.conf

WireGuard in NetworkManager – Thomas Haller's Blog


“Use something else” is not an ideal solution.
It would be good to figure out what broke this in the first place, as having both options is better than just having to obligated to use NetworkManager.

Even weirder considering a straight up “sudo wg-quick up wg0” works.

There are best practices to help you avoid unnecessary problems.
You must have a good reason to justify going against it.

This seems likes an unnecessarily rigid position, on top of being biased.

Which best practices are you referring to? The only part of the Fedora documentation that mentions Wireguard, “Configure Wireguard on Fedora CoreOS” uses systemd on both the server-side and the client-side, which one can assume to be Fedora (Workstation).

In any case, Wireguard on Fedora automatically installs a systemd unit for each conf file. If Fedora doesn’t support using systemd to manage Wireguard tunnels, it should not install systemd units to manage Wireguard tunnels.

So what is causing this regression and how can it be fixed?

You shouldn’t confuse this forum with a bug tracker.

Since the topic was marked as solved by the OP, this is apparently an example of an XY problem which often doesn’t require to answer the question directly.

If you want a different solution, create a new thread and explain why the existing tested and working method, providing most possible system and interface integration, doesn’t fit your setup.

@vgaetera You make a fair point, yes it does look a lot like a XY problem.

However, both solutions (NetworkManager vs. systemd unit) don’t provide exactly the same thing: with the systemd unit, you can have the VPN tunnel come up as soon as the machine boots, whereas the NetworkManager solution only connects once you are logged in, as far as i know.

In any case, there is a solution.
It turns out there was a SELinux context issue, and running restorecon -R -v /etc/wireguard/ fixed it:

Relabeled /etc/wireguard/wg0.conf from unconfined_u:object_r:user_home_t:s0 to unconfined_u:object_r:etc_t:s0

My wireguard config file had initially been written in my home directory, and then copied over to /etc/wireguard/, bringing with it the wrong SELinux context.

So, in summary:

  • chmod 0700 /etc/wireguard/
  • chown root: /etc/wireguard/
  • chmod 0600 /etc/wireguard/*
  • restorecon -R -v /etc/wireguard/

and then systemctl has no issue reading the wg0.conf file.


It can connect at boot without waiting for the user to log in, and I’m certain about it because one of my machines works like that.

What you described matches a very specific connection setting:

This should solve the problem:

nmcli connection modify CONNECTION_ID \
    connection.autoconnect "" \
    connection.permissions ""