Nouveau NAS : installation des containers

Suite de l’installation d’OMV sur le nouveau NAS, avec cette fois l’installation des containers Docker qui tournaient sur l’ancienne machine, à savoir Dockge, Plex, Homepage, Qbittorrent et Nextcloud.

Je ne vais pas reprendre ici chaque installation en détail, des articles existent déjà à ce sujet. D’autant que je vais tout simplement reprendre les fichiers compose.yaml que j’utilisais sur l’ancienne machine pour recréer les containers avec l’aide de Dockge. J’aurai juste quelques paramètres à adapter à chaque fois pour le nouveau NAS (chemin fichiers typiquement), ça devrait donc être assez facile.

Je me contenterai donc dans cet article des quelques problèmes rencontrés (ou changements effectués) sachant que dans l’ensemble tout s’est bien passé. Mais forcément, il arrive de tomber sur un problème jamais rencontré auparavant, on peut appeler cela les joies de l’informatique.

Au menu donc : un souci de token avec Plex pour Homepage, un problème réseau avec la WebUI de Qbittorrent, et même un changement de container pour d’autres raisons. Enfin, Nextcloud, le container que j’appréhendais le plus à réinstaller, n’a lui posé aucun problème : une autre joie de l’informatique sans doute ! 😉

C’est parti !

OMV

J’en étais resté dans l’article précédent à l’installation des OMV-Extras et de « openmediavault-compose » depuis Système-Extensions. Il me restait à configurer les dossiers partagés dans le menu Stockage, puis à aller dans le menu Service-Compose-Paramètres, et y définir l’emplacement des « Compose Files » et « Data », soit respectivement AppData et OMV-DATA dans mon cas (je reproduis ce que j’avais sur l’autre machine).

J’en profite aussi pour déplacer Docker vers le disque NVMe plutôt que de laisser sur le disque système :

Puis en bas de la page, je choisis « Reinstall Docker » et « Restart Docker ». Voilà, tout est prêt côté OMV.

Dockge

Je commence donc par Dockge, qui va permettre de créer tous les autres containers, cet outil est vraiment génial, et je me passe complètement de Portainer (proposé par OMV), que je n’ai d’ailleurs pas installé. Je suis la procédure d’installation de la page sur GiHub, et démarre le container. R.A.S.

Homepage

Puis j’installe mon premier container via Dockge, à savoir Homepage, très pratique pour se créer un « Dashboard », ou un tableau de bord bien pratique pour gérer l’ensemble de mes services, qu’ils soient auto-hébergés ou chez mon fournisseur. Voilà ce que cela donnera à la fin :

Problème avec Plex et Homepage

Je commence ensuite par Plex. Le container s’installe sans souci particulier, et je copie les fichiers de ma bibliothèque média via une connexion NFS fait entre les deux machines. Tout se déroule sans encombre, et côté TV, je vois deux instances apparaître au lancement de la smart application, et je choisis la nouvelle instance. R.A.S.

Je vais en fait passer plus de temps à l’intégrer dans le dashboard Homepage, car il me faut trouver le « token » et je ne savais plus comment j’avais fait : sur cette page , il faut suivre la procédure pour « The device token« . Ensuite, copier le token pour la valeur de key dans le fichier services.yaml que l’on vient de créer pour définir le serveur Plex :

- NAS-N150:
    - Docker:
      - Plex:
          icon: plex.png
          href: http://192.168.1.32:32400/
          description: Media Server - Séries, films, documentaires...
          server: my-docker
          container: plex_n150
          widget:
            type: plex
            url: http://192.168.1.32:32400
            key: 92xxxxxxxxxxxxxxxXj

Mais cela ne fonctionnait toujours pas, j’avais une API Error sur le dashboard d’Homepage :

Le problème venait de la ligne server: my-docker (que j’avais copier/coller du précédent serveur) : c’est bien la valeur par défaut, mais il faut toutefois aller dans le fichier docker.yaml et dé-commenter les lignes correspondantes, ce qui n’est pas fait par défaut lors de l’installation de Homepage :

---
# For configuration options and examples, please see:
# https://gethomepage.dev/configs/docker/

# my-docker:
#   host: 127.0.0.1
#   port: 2375

 my-docker:
   socket: /var/run/docker.sock

Et l’accès via l’API au container Plex fonctionne enfin :

Problème avec Qbittorrent

Je reprends donc la même stack que j’utilisais (il s’agit d’une version de Qbittorrent avec OpenVPN d’intégré et compatible armv7l soit une architecture x32), et lance le container. Au premier démarrage, il me demande un fichier .ovpn comme je l’avais noté lors de ma première installation, pas de surprise. Je copie donc le fichier dans le dossier créé lors du premier démarrage (AppData/Qbittorrent/openvpn), et je relance. Tout semble aller pour le mieux, et j’ai bien le message [info] Started qBittorrent daemon successfully...

Mais par contre impossible d’accéder à l’interface WebUI, pas de réponse… Et quand je regarde l’état des ports de mon NAS depuis le PC, je vois ceci :

$ nmap -sT 192.168.1.32
Starting Nmap 7.95 ( https://nmap.org ) at 2025-06-25 10:00 CEST
Nmap scan report for NAS-N150.lan (192.168.1.32)
Host is up (0.00021s latency).
Not shown: 991 closed tcp ports (conn-refused)
PORT     STATE    SERVICE
..
8080/tcp filtered http-proxy
8090/tcp open  opsmessaging
..

Le port 8090 est celui que j’utilise pour l’interface d’OMV, il apparaît bien « open » et est parfaitement fonctionnel.
Le port 8080 est celui que j’ai défini pour la WebUI de Qbittorrent, et il apparaît « filtered« .

J’essaie un autre port, avec le même résultat. Peut-être problème de pare-feu alors ? mais je vois dans les logs du container que les règles sont créées (sans trop creuser), et je me dis que ce problème va être compliqué à résoudre, je sèche un peu. Je pose alors une question sur le forum d’OMV à tout hasard. Mais je continue de chercher une solution, et 💡 je me rends compte que la route définie dans le container est incomplète (heureusement que je peux la comparer avec celle du container tournant encore sur l’autre machine !). Voilà la route que je vois sur l’ancien NAS dont l’accès à la WebUI fonctionne :

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
...
192.168.1.0     172.27.0.1      255.255.255.0   UG    0      0        0 eth0
...

Alors que sur le nouveau NAS je n’ai aucune route concernant mon LAN (192.168.1.x), ce qui explique pourquoi mon interface est injoignable. Elle est pourtant bien définie dans le fichier compose.yaml sur les deux machines de manière identique (LAN_NETWORK=192.168.1.0/24) mais pour une raison inconnue elle n’a pas été créée. Je l’ajoute donc à la main :

# ip route add 192.168.1.0/24 via 172.27.0.1 dev eth0

Bingo ! je peux enfin accéder à mon interface WebUI de QBittorrent ! 😎

J’ai tout de même un dernier souci, impossible de m’identifier avec le mot de passe par défaut ! En fait, le mot de passe est regénéré à chaque démarrage tant que l’on ne s’est pas loggué une première fois pour le modifier via l’interface : avec tous mes essais de démarrage, ce n’est donc plus le même ! 🙁 Il faut alors aller dans AppData/Qbittorrent/qBittorrent/data/logs et lire le fichier qbittorrent-daemon.log pour trouver sa dernière valeur :

root@NAS-N150:/srv/dev-disk-by-uuid-f39c071a-91e2-4184-971f-a722a7697ca5/AppData/Qbittorrent/qBittorrent/data/logs# cat qbittorrent-daemon.log
...
******** Information ********
To control qBittorrent, access the WebUI at: http://localhost:8080

The WebUI administrator username is: admin
The WebUI administrator password was not set. A temporary password is provided for this session: uw6bJP8kR
You should set your own password in program preferences.

Voilà, mon interface WebUI de Qbittorrent fonctionne enfin ! Tout content, je renseigne la question posée sur le forum OMV avec la solution à mon problème. Quelqu’un avait d’ailleurs répondu à ma question initiale en me demandant ma config.

Après avoir vu ma solution, cette même personne me conseille quand même de vérifier le réseau utilisé par QB, et que ce soit bien celui de mon VPN. Je lui répond que vu les logs, et le fait que j’ai sélectionné l’interface tun0 dans la WebUI de QB, ça doit être bon. Il me donne alors une autre méthode de vérification très pratique.

Tester l’adresse réseau utilisée par qBittorrent

Il suffit d’aller sur ce site de TorGuard : le test est assez malin, puisqu’il s’agit de charger un fichier torrent sur lequel ils sont également connectés, et vont alors pouvoir vérifier l’adresse IP utilisée par mon client.

Je fais donc un click droit sur le bouton « Download Now » et je copie le lien. Puis je passe sur la WebUI de QB et je fais « Fichier-Ajouter un lien torrent », et je colle le lien précédemment copié. Je vois alors le torrent apparaître :

Après quelques secondes, il suffit de revenir sur la page d’origine de TorGuard, et l’on voit l’adresse IP utilisée par notre client Qbittorrent :

Un simple whois dans un terminal de cette adresse me confirmera que c’est une adresse de mon fournisseur de VPN.

Nouveau container qBittorrent

Mais la personne du forum OMV me conseille également d’utiliser un autre container Qbittorrent-OpenVPN, car le mien date un peu : je vois dans les logs que je suis en v4.6.7. Le container qu’il me conseille utilise la v5.1.1 (comme on peut le voir sur le screenshot ci-dessus, pris avec ce nouveau container).

En fait, j’étais resté avec ce container car c’était l’un des seuls incluant OpenVPN ET supportant l’architecture armlv7 x32, ce qui n’était pas évident à trouver. C’est d’ailleurs la raison pour laquelle j’installe ce nouveau NAS.

J’arrête donc mon container QB, adapte les paramètres du nouveau compose.yaml avec mes valeurs, et le lance : même chose qu’avec l’autre container, il faut copier le fichier du fournisseur de VPN dans le répertoire créé après le premier démarrage. Pour le reste, tout fonctionne immédiatement et je peux me logguer via la WebUI sans problème.

Finalement ce problème d’accès à la WebUI a été positif, puisque j’ai maintenant un container plus à jour, et appris une méthode intéressante pour tester l’IP utilisée par le client Qbittorrent.

Installation Nextcloud

Ce que j’imaginais le plus difficile s’est finalement plutôt très bien passé. Il faut par contre tout définir correctement au niveau réseau avant de lancer le container :

au niveau d’internet, via mon fournisseur d’accès, pour définir le sous-domaine DNS que j’ai défini.
au niveau de la box internet, pour bien rediriger les port 80 et 443 sur la bonne machine.
Dans les fichiers de configuration Nextcloud et Swag, pour bien obtenir les certificats LetsEncrypt.

Sinon, je précise tout de même que l’on ne peut accéder à l’interface Web de Nextcloud (pour la phase « web-based » installation de Nextcloud) via l’adresse IP locale (sinon on arrive sur la page de swag) :

Il faut absolument utiliser le nom de domaine que l’on a défini dans le fichier compose.yaml. En même temps, c’est le rôle de Swag de protéger l’accès du serveur, donc rien de vraiment surprenant en y réfléchissant !

Après la web-install de Nextcloud (on ne peut le faire avant), je modifie le fichier /srv/dev-disk-by-uuid-f39c071a-91e2-4184-971f-a722a7697ca5/AppData/Nextcloud/config/www/nextcloud/config/config.php de Nextcloud comme je l’avais fait sur l’ancienne machine :

  'trusted_proxies' => 
  array (
    0 => '127.21.0.0/16',
  ),
  'trusted_domains' => 
  array (
    0 => '192.168.1.32:443',
    1 => 'nextcloud.xxxx.yyy.fr',
  ),

J’ajoute la ligne avec l’adresse IP dans la section « trusted-domains » mais cela ne résout pas le pb swag rencontré plus haut comme je le pensais : cette ligne ne sert donc peut-être à rien.

Et j’ajoute la partie « trusted_proxies » qui n’existe pas par défaut, après avoir vérifié l’adresse utilisée par le container (accès au terminal via Dockge) :

Ce n’est pas obligatoire, mais cela génère un avertissement dans Nextcloud-Paramètres d’administration, dans les Avertissements de sécurité & configuration (voir cet article).

Conclusion

Finalement, tout a été assez facile. C’est évidemment très pratique d’avoir encore la machine précédente qui fonctionne si l’on a besoin de comparer des choses. Grâce à ma question sur le forum d’OMV, j’ai même un container QB incluant OpenVPN plus récent et activement mis à jour.

Mes containers sont désormais tous à jour avec des versions x64 supportées, ce qui n’était plus le cas depuis un bout de temps avec l’architecture x32.

Ce nouveau NAS est beaucoup plus puissant et rapide, je suis curieux de voir si j’aurai encore des problèmes à visionner certaines vidéos comme je l’avais sur l’ancien : notamment le « bit rate » qui semblait poser problème à partir d’un certain seuil. Ce ne devrait plus être le cas désormais…

Voilà, il ne me reste qu’à voir quels nouveaux containers je vais pouvoir installer maintenant que mon serveur est en x64 : sans doute pi-hole qui me permettra de dédier mon raspberry à Volumio et m’évitera d’avoir à bidouiller l’image système pour faire cohabiter les deux… et peut-être Calibre, l’idée de disposer de ses e-books à distance me plaît pas mal… et peut-être d’autres puisque je ne suis limité par un hardware dépassé !

Pascal's weblog