8

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
Joe
  • 336
  • 1
  • 2
  • 7

3 Answers3

3

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:

#!/bin/bash

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.

natxo asenjo
  • 5,641
  • 2
  • 25
  • 27
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.

Yaron
  • 181
  • 1
  • 10
2

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.

Anderson Medeiros Gomes
  • 2,252
  • 8
  • 20
  • 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? – Lasse Michael Mølgaard Feb 14 '20 at 06:11
  • Anderson, i tried the suggested solution, but it doesn't work – Joe Feb 14 '20 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. – Anderson Medeiros Gomes Feb 15 '20 at 01:52
  • @Joe Interesting. So I think that the only option is to automate the manual fix at boot time, as [@natxo asenjo's answer](https://serverfault.com/a/1003129/293407). – Anderson Medeiros Gomes Feb 15 '20 at 02:01