robin@fabre:~/blog/synology-maj-dsm-module-tun-docker-vpn$ ▮ MONTPELLIER · ● data & bidouilles

cat synology-maj-dsm-module-tun-docker-vpn.md

Synology : après une mise à jour DSM, ta stack Docker VPN ne redémarre pas

Publié le 16 juin 2026 · #synology #dsm #docker #vpn #gluetun #nas #tuto #homelab

Après une mise à jour DSM sur mon NAS Synology, mauvaise surprise : aucun de mes conteneurs Docker n’était remonté. Toute la stack — gluetun et tous les conteneurs qui passent par lui — affichait Exited depuis le reboot, alors que tout est censé redémarrer tout seul.

Si tu utilises gluetun (ou n’importe quel conteneur VPN) sur un Synology, il y a de bonnes chances que tu tombes un jour sur ce cas. Voici le diagnostic complet, parce qu’il y a en fait deux causes indépendantes qui se cumulent.

Le symptôme

Relancer gluetun à la main échoue avec :

error gathering device information while adding custom device "/dev/net/tun":
no such file or directory

Et sans gluetun, tous les conteneurs en network_mode: container:gluetun restent bloqués derrière.

Cause n° 1 : la mise à jour DSM a déchargé le module tun

La MAJ DSM a retiré le module noyau tun : /dev/net/tun n’existe plus. Sans lui, gluetun ne peut pas monter son interface VPN. C’est le bloqueur dur.

Le fix immédiat, en SSH sur le NAS :

sudo insmod /lib/modules/tun.ko
sudo mknod /dev/net/tun c 10 200
sudo chmod 666 /dev/net/tun

Puis on relance gluetun d’abord (les autres conteneurs utilisent son réseau, l’ordre compte) :

sudo /usr/local/bin/docker start gluetun
# attendre qu'il soit healthy, puis :
sudo /usr/local/bin/docker start <tes-autres-conteneurs>

Au passage, un piège Synology : sudo a un PATH réduit qui ne contient pas /usr/local/bin, donc sudo docker ne marche pas — il faut le chemin complet sudo /usr/local/bin/docker.

Cause n° 2 : restart: unless-stopped ne fait pas ce que tu crois

Mes conteneurs sont tous en restart: unless-stopped. Alors pourquoi rien n’est remonté ?

Parce que pendant une mise à jour, Container Manager stoppe explicitement les conteneurs (Exited (0)). Et unless-stopped, c’est littéral : un conteneur arrêté « proprement » ne sera pas relancé au boot suivant. La politique de restart ne te protège donc pas contre les mises à jour DSM.

Le fix durable : un script au démarrage

Plutôt que de refaire ça à la main à chaque MAJ, j’ai mis un script de boot qui :

  1. recharge le module tun et recrée le device node si absent ;
  2. attend que le daemon Docker soit prêt ;
  3. relance la stack dans le bon ordre (gluetun d’abord, le reste ensuite) ;
  4. logge tout dans /var/log/ pour vérifier après coup.

À câbler dans le Planificateur de tâches DSM : tâche déclenchée « Au démarrage », utilisateur root. C’est la seule étape qui passe par l’interface — le Planificateur ne se crée pas proprement en CLI.

En résumé

  • /dev/net/tun peut disparaître à chaque mise à jour DSM : ce n’est pas toi, c’est Synology.
  • restart: unless-stopped ne survit pas à un arrêt explicite par Container Manager.
  • Un script « Au démarrage » qui recharge tun et relance la stack dans l’ordre règle les deux problèmes d’un coup.

← cd ~/blog