There are lots of questions pertaining this error, and there is a suggested manual fix which works well, but there's no permanent solution. How can i permanently solve this? Im having this issue on a debian wheezy server, using OpenVPN client to connect to an OpenVPN server.

The suggested fix is the one below. Seems like, /dev/net is not automatically created and of course disappears on each reboot.

mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun
  • it's work like a charm on synology nas, i was try to use zerotier and was unable until i see this answer !!! Jul 25, 2022 at 15:53

3 Answers 3


It happens in Arch/Manjaro as well.

I managed to figure out the problem, apparently a kernel upgrade is simply moving the modules directory, so trying to reach the modules from their known location is unavailable, the current running kernel is still running but I can't seem to modprobe (load) any modules which are not already loaded (such as tun required for OpenVPN connections).

So for example, the /lib/modules/ directory had the following directories before the upgrade (I have multiple kernels, notice the 5.16 series):

5.15.32-1-MANJARO  *5.16.14-1-MANJARO*  extramodules-5.15-MANJARO  extramodules-5.16-MANJARO

And this is the status after the upgrade:

5.15.32-1-MANJARO  *5.16.18-1-MANJARO*  extramodules-5.15-MANJARO  extramodules-5.16-MANJARO

Trying to load the tun modules shows the following message:

modprobe: FATAL: Module tun not found in directory /lib/modules/5.16.14-1-MANJARO

Which perfectly makes sense as this directory doesn't exist.
So, what is my proposed solution in this case? A restart.


debian wheezy has been out of support since may 2018 (https://www.debian.org/releases/wheezy/), you should not be using it in 2020 any more for production.

Now, with that out of the way, you could add the commands that temporarily fix your issue adding those commands a bash script that you add to your root crontab with the @reboot nickname (man 5 crontab).

So create a bash script somewhere in your file system with something like this:


mkdir -p /dev/net
mknod /dev/net/tun c 10 200
chmod 600 /dev/net/tun

/etc/init.d/openvpn restart

Save it with 755 permissions and modify the root crontab:

# crontab -e

with this content at least

@reboot /path/to/where/you/saved/the/script

And after rebooting it should have started openvpn successfully.

  • 3
    As an alternative, the code snippet can be be written into /etc/default/openvpn file, which is sourced by /etc/init.d/openvpn script. Feb 15, 2020 at 2:05
  • nice, I do not have a debian wheezy handy to test, but this should be the preferred option if it works Feb 15, 2020 at 10:04

I think that a possible solution is to configure the system to load the tun kernel module during startup. In order to do so, list the tun module name in /etc/modules file:

# echo tun >> /etc/modules

udev is the system component that creates and maintains device nodes in /dev folder according to loaded kernel modules and connected hardware devices. I believe that by loading tun kernel module at boot time, the system will create the /dev/net/tun device node on every startup.

I hope it helps.

EDIT: I am a bit outdated. After launching a Debian Wheezy image published in Vagrant Cloud website, I figured out that udev in fact handles permissions, ownerships and symlinks regarding already existing device nodes. Device nodes are actually created by the kernel itself and are exposed to userspace through the devtmpfs pseudo-filesystem.

devtmpfs filesystem is mounted at initramfs time. The file /usr/share/initramfs-tools/init, which gets executed once grub extracts initramfs to memory, presents code that mounts a devtmpfs filesystem into /dev, falling back to a standard tmpfs filesystem if unsuccessful.

In addition, to have devtmpfs filesystem available, Debian Wheezy kernel is shipped with CONFIG_DEVTMPFS=y enabled.

  • On Busybox systems I have experienced that tun.o or tun.ko does exist in the default modules directory. In that case insmod /path/to/tun.o will be the way to go? Feb 14, 2020 at 6:11
  • Anderson, i tried the suggested solution, but it doesn't work
    – Joe
    Feb 14, 2020 at 16:39
  • @LasseMichaelMølgaard It depends on how the Busybox system is implemented. I am not sure on how device nodes are maintained in such systems. Anyway, modprobe and insmod are to kernel modules as apt-get and dpkg are to software packages, so insmod may work. Feb 15, 2020 at 1:52
  • @Joe Interesting. So I think that the only option is to automate the manual fix at boot time, as @natxo asenjo's answer. Feb 15, 2020 at 2:01

You must log in to answer this question.

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