I am trying to modprobe wireguard as root, and it fails with:

modprobe: ERROR: could not insert 'wireguard': Operation not permitted

Adding verbose I get one more line:

[root@localhost ben]# insmod /lib/modules/5.2.11-100.fc29.x86_64/extra/wireguard.ko.xz
insmod: ERROR: could not insert module /lib/modules/5.2.11-100.fc29.x86_64/extra/wireguard.ko.xz: Operation not permitted

dkms runs fine without error. I've also disabled selinux and that made no difference. I don't see anything in the journalctl logs.

Looking through man pages and Google have not turned anything up.

I did find this helpful line in dmesg:

Lockdown: modprobe: Loading of unsigned module is restricted; see man kernel_lockdown.7

However that man page does not exist.

How can I debug this? Any pointers on where to go next?

5 Answers 5


Finally found something on it. It appears to be a "feature" where unsigned code can't be loaded into the kernel when UEFI secure boot is enabled (which it is).

To get the module loading, disable kernel lockdown via sys-rq:

# echo 1 > /proc/sys/kernel/sysrq
# echo x > /proc/sysrq-trigger

Then modprobe should work:

modprobe wireguard

For more information, see:



  • 1
    This is a great answer, and it fixed my issue. Unfortunately, you have to do this every time you update the kernel. Nov 12, 2019 at 18:42
  • For me this issue is still present: # modprobe -vvv wireguard modprobe: INFO: custom logging function 0x55cf4e172a20 registered insmod /lib/modules/5.3.11-300.fc31.x86_64/kernel/net/wireguard.ko.xz modprobe: INFO: Failed to insert module '/lib/modules/5.3.11-300.fc31.x86_64/kernel/net/wireguard.ko.xz': Operation not permitted modprobe: ERROR: could not insert 'wireguard': Operation not permitted modprobe: INFO: context 0x55cf4eb9b4c0 released @Freedom_Ben do you have maybe some idea why?
    – valentt
    Nov 25, 2019 at 11:18
  • 1
    on ubuntu 20.04 i get permission denied for both, e.g. bash: /proc/sys/kernel/sysrq: Permission denied
    – caduceus
    Aug 21, 2020 at 8:41
  • 1
    For anyone running into issues in the future, you can't use sudo echo 1 > /.... Instead, either login as root or do echo 1 | sudo tee /path/to/file. Jan 26, 2021 at 18:30
  • 4
    Unfortunately, now the trick doesn't work anymore... Mar 17, 2021 at 12:27

Maybe the best for long term is to sign your modules.

For Debian and derivatives see:


  • 1
    Please don't post answers that are mostly links; include the relevant question from these links, as they will probably rot away. Dec 2, 2021 at 23:16
  • Link-only answer... edit answer and add the details from the link Dec 13, 2021 at 4:13
  • upvoted because in this case, non-link answer would be detrimental. Mentioning "sign your modules" is the answer, and trying to give more details would be insane.
    – gcb
    21 hours ago

My Fedora 31 distribution didn't accept echoing to sysrq.  The Arch Linux wiki suggested to use Alt+PrtSc+x (on laptops, where Fn is part of the keyboard).  The lockdown was successfully disabled and WireGuard successfully loaded.  I installed akmod, so modprobe wireguard worked for me as an alternative to SysRq+x.  (The Red Hat manual says it should be pressed on a physically attached keyboard.)

  • after rebooting: echo 1 > /proc/sys/kernel/sysrq is still required for Alt+PrtSc+x to be accepted by the system
    – igor
    Dec 29, 2019 at 11:55

I got this to work on my Asus ProArt B550 Creator with an AMI BIOS by changing the "OS Type" BIOS setting from Windows UEFI to "Other OS". No magic SysRq needed.



my problem is to load os module overlay of the Centos 7.x (not compiled module), that normaly are signed... plus secure boot are not enabled (mokutil say "EFI variables are not supported on this system").


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .