@bubblehornet

Connecte-toi en direct sur ton NAS (tu fixes une IP dans le NAS et ton PC sur la même plage réseau) et essaie de faire des transferts, si les débits sont faibles alors le pb est effectivement au niveau du NAS ou du câble.
Si les débits sont satisfaisants le NAS n'est pas à mettre en cause et il faudra chercher ailleurs.

@Gabin Gabin

Aucune erreur dans tes logs, juste quelques infos classiques relatives à Apache qui n'ont pas d'importance.

En réalité, aucun réglage de DSM ne peut faire que ça fonctionne chez moi et pas chez toi, car les deux conteneurs discutent en direct au sein d'un même réseau sans passer par leur passerelle, le NAS.
Par contre, les permissions et propriétés des fichiers et dossiers peuvent être différentes d'une image à l'autre.

Il faut donc supprimer tout le dossier Nextcloud, recréer les dossiers config et db en aval, et relancer la stack.
L'initialisation a pris près de 5-6 minutes chez moi, je pensais que ça plantait, mais je pouvais constater en même temps que le dossier config se peuplait de fichiers, donc tout semblait normal.

Ah, et dernière chose, tant qu'à faire à ta place j'utiliserais aussi l'image Linuxserver de Nextcloud, qui est activement maintenue. Pendant mon test hier j'ai pu voir que le propriétaire des fichiers était un utilisateur système (ID 33), l'image Linuxserver s'assurera que les fichiers appartiendront au PUID/PGID utilisé.

Si tu as un serveur Bind c'est parfait, DNS Server du NAS c'est Bind avec une interface en fait.
Il te faut juste créer une zone DNS avec ton ndd.fr, comme ça tu feras du split DNS.
Et tu pourras même ajouter des vues par après pour différencier le comportement lorsque tu es par exemple connecté en local ou en VPN (si tu as un serveur VPN).

Il y a 9 heures, Sehoku a dit :

Par contre si je comprend bien même si je fais ça je devrais utiliser nas.toto.synology.me plutôt que drive.ndd.fr pour le SSL?

Alors ça dépend, tu as plusieurs possibilités :

• importer le certificat généré par SWAG dans DSM, fastidieux car manuel
• créer un certificat pour ton domaine ndd.fr dans DSM, mais sans wildcard, pour avoir le même ndd utilisé, ça va coincer avec le NAT du port 80 déjà utilisé par SWAG normalement pour la redirection http -> https, cela dit si tu utilises HSTS tu peux te passer du port 80 sur SWAG
• mettre en place un conteneur acme.sh pour générer un certificat wildcard pour ndd.fr avec le déploiement automatisé du certificat dans DSM ==> la meilleure méthode selon moi
• utiliser le ndd Synology pour les services du NAS qui ne passent par le proxy inversé -> solution du fainéant que j'utilise 😄 

@Vista1967 En temps normal j'essaie de lancer les images de mon côté, mais je ne le fais pas avec des conteneurs qui demandent des privilèges élevés et pour des images aussi peu répandues. Si tu cherches un soft qui permet de faire du boot network PXE sous Docker, regarde du côté de netbootxyz par Linuxserver : https://docs.linuxserver.io/images/docker-netbootxyz/

Beaucoup mieux documenté et pour l'avoir installé chez moi ça fonctionne très bien.

J'ai créé la stack chez moi depuis Container Manager et ça marche parfaitement :

Est-ce que ton port 8244 est bien ouvert sur le réseau local dans le pare-feu du NAS ?

Donc déjà ça montre qu'il n'y a pas de résolution DNS locale dans ton réseau, à ce titre tu y gagnerais beaucoup en suivant ce tutoriel :

Dans ton cas, pour accéder d'un périphérique A à un périphérique B sur ton réseau local, l'IP publique de ta box est sollicitée. Car ne sachant pas vers quoi pointe localement drive.ndd.fr, ton périphérique A s'en remet aux serveurs publiques, qui lui disent que ça pointe chez toi 😄 

Le NAT Hair-pinning (appelé aussi parfois loopback), permet à une box de se rendre compte qu'une requête a priori publique provient en fait d'un réseau interne, pour atteindre un périphérique d'un réseau interne, la requête fait donc un "demi-tour" (d'où le terme d'épingle - hairpin) pour revenir au sein de ton réseau.

J'ai tendance à penser que la succession de routeurs au sein de ton réseau pourrait perturber ce procédé (pour autant que ta box en soit capable).

Lorsque tu es sur les data, ça se passe ainsi :

drive.ndd.fr -> résolution publique -> pointe vers l'IP publique :

* requête port 443 ? ==> reverse proxy -> interface web
* requête port 6690 ? ==> NAS -> transfert de données Drive 

En local :

drive.ndd.fr -> résolution publique (car pas de réso. locale) -> pointe vers l'IP publique -> ?

La méthode la plus simple pour moi :

1. Créer un certificat dédié via DSM (par exemple pour le ndd gratuit fourni par Synology) associé aux services Synology non proxiables (Hyperbackup, Drive (données), etc...) ==> nas.toto.synology.me
2. Modifier le fichier hosts de ton Windows (C:\Windows\System32\drivers\etc) et y inclure la ligne :

192.168.10.5       nas.toto.synology.me

et c'est le ndd que tu devras mettre dans ton client Synology Drive Windows

Quant à la meilleure méthode, elle consiste à mettre en place une zone DNS locale qui permette de faire du split DNS, en gros lorsque tu es en local tu résous localement (avec les IP privées) tes noms de domaine, et en dehors de ton réseau, les mêmes noms de domaine se résolvent publiquement.
Ça permet au final :

• d'avoir les mêmes noms de domaine où qu'on soit
• de ne pas devoir effectuer la modification sur chaque poste client
• d'être indépendant des serveurs de nom publiques

@Gabin Gabin Essaie la stack que je t'ai proposée, tjs en tapant db:3306 pour l'hôte.
Si ça ne fonctionne toujours pas, tu donnes un nom à chaque conteneur, par exemple :

container_name: nextcloud-db # pour MariaDB

et

container_name: nextcloud # pour Nextcloud

et cette fois-ci pour te connecter à la db tu mets nextcloud-db:3306

@Gabin Gabin

Où est le champ pour l'hôte de la base de donnée ? je peux pas scroller sur ton écran 😄 

Ca doit être après le champ "Nom de la base de données" j'imagine.

A priori, seule une réinstallation complète du NAS permet de modifier la taille de la partition root.
Sinon peut-être en regardant sur les forums de celui-dont-on-doit-taire-le-nom 😄 

Tu peux supprimer la dernière partie :

volumes:
  iso:
[...]

car tu n'utilises pas les volumes nommés mais des dossiers du NAS.
L'avantage d'utiliser les volumes nommés en l'occurrence c'est que ça évite tout problème de permissions.

Tu es sûr que ton conteneur doit faire office de DHCP pour le réseau ? car c'est ce que tu fais en mappant le port 67 en UDP.

Il y a 2 heures, Vista1967 a dit :

192.168.1.10:26000

Rien ne se passe ça veut rien dire, il y a forcément un code erreur et un texte associé. Et si pas, une recherche qui boucle c'est aussi une info.

@Vista1967 Tu peux c/c le fichier compose que tu as mis dans ton projet ?

Perso j'ai aussi acheté un RS422+ et il est moins au taquet que mon DS218+ 😄 

Bon, il ne sert qu'à du stockage, mais au prix du NAS ils auraient pu y mettre un peu plus de cœur.

La taille des logs est limitée (il y a une rotation des logs au bout d'un moment), ça finira par disparaître.
Qu'est-ce qui te gêne ?

@PascalFr On peut y regarder un soir de la semaine si tu veux, MP moi tes disponibilités, je piocherai dedans.

@Gabin Gabin

Plusieurs choses :

• Je te conseillerais d'utiliser l'image Linuxserver de MariaDB, plus adaptée de façon générale à l'utilisation sur un NAS.
• La fonction des links est dépréciée depuis longtemps pour communiquer avec un autre conteneur, il faut utiliser un réseau bridge personnalisé.
• As-tu précisé le port (3306) pour la connexion à la DB dans le wizard Nextcloud ? ==> db:3306

Si ça ne fonctionne pas plus, recrée des dossiers vierges et essaie cette stack :

 

version: '2.1'
services:

  db:
    image: linuxserver/mariadb
    restart: unless-stopped
    networks:
      - net-nextcloud
    volumes:
      - /volume1/docker/nextcloud/db:/var/lib/mysql
    environment:
      - PUID=1026
      - PGID=100
      - MYSQL_ROOT_PASSWORD=XXXXXXXXX
      - MYSQL_PASSWORD=XXXXXXXXX
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud

  app:
    image: nextcloud
    restart: unless-stopped
    networks:
      - net-nextcloud
    ports:
      - 8244:80
    volumes:
      - /volume1/docker/nextcloud/config:/var/www/html
    environment:
      - PUID=1026
      - PGID=100
      - MYSQL_PASSWORD=XXXXXXXXX
      - MYSQL_DATABASE=nextcloud
      - MYSQL_USER=nextcloud
      - MYSQL_HOST=db

networks:

  net-nextcloud:

@Sehoku

Qu'as-tu mis dans ton client Synology, j'entends client desktop Windows ou Mac ? (pas Android ou iOS)

drive.ndd.fr pour l'adresse du NAS ?

En parallèle, peux-tu faire via le terminal :

nslookup drive.ndd.fr

Hello, content que ça réponde à ton besoin.

drive.ndd.fr pointe vers ton proxy ou ton NAS ? car le ndd doit pointer vers le NAS pour le trafic qui passe par le port 6690. Ce que tu peux faire passer par le proxy c'est l'interface d'accès à Drive.

@LeoM

Mopidy + Snapcast + Iris

Avantages :

• Permet de gérer autant de flux que tu as d'instances de Mopidy (multipliables, via docker ou vm)
• Intégration des clients (snapclient) au serveur Snapcast (snapserver) triviale
• Réglage possible de la latence de diffusion pour mieux synchroniser les sources sonores
• Intégration possible de Airplay via shairport-sync et Snapcast

Inconvénients :

• Certains services de streaming ne sont pas disponibles (Deezer car interdit par Deezer, Youtube Music car plugin à l'abandon)
• Même si Iris (https://github.com/jaedb/Iris) est très potable pour une interface graphique gratuite, je ne suis pas sûr que ça réponde à tes exigences
• Faut clairement mettre les mains dans le cambouis, et ça demande un peu de maintenance lors des changements majeurs de version

Une autre solution que tu pourrais envisager c'est Volumio : https://volumio.com/fr/

Volumio

Avantages :

• Complètement compatible avec des Raspberry Pi et des modules Hifiberry (c'est même l'idée de départ)
• Interface simple, jolie et efficace
• Tu peux streamer un flux sur 6 clients en simultané
• Compatible Chromecast et Airplay
• Intégration de quasi tous les services de streaming

Inconvénients :

• La version gratuite n'inclut pas le multiroom (et l'intégration native de plusieurs services), il faut passer sur abonnement Premium (mais le prix est démocratique)
• Si tu veux plus de 6 appareils connectables, il te faudra un 2ème abonnement
• Il faudra passer par une VM si tu veux héberger Volumio sur ton NAS, et ce n'est pas l'installation la plus simple, plus facile de l'installer sur un Raspberry Pi.

A savoir que si tu achètes un ampli chez eux (https://fr.shop.volumio.com/), tu as l'abonnement premium à vie inclus.

Je me suis posé les mêmes questions que toi récemment, hormis la partie audiophile, et j'ai utilisé le mois gratuit de Volumio Premium (voir la liste des fonctionnalités pour les versions gratuite et premium : https://volumio.com/volumio-premium-plan/). Honnêtement, c'est uniquement parce que j'avais besoin de pouvoir avoir plusieurs flux simultanés possibles que je n'ai pas poursuivi dans cette direction, sinon ça répondait parfaitement à mon besoin.

Par rapport à ton besoin, ce qui peut manquer je pense c'est la possibilité de lire directement sur le smartphone, mais il y a peut-être un plugin qui le permet, à vérifier.

Dernière chose, je dirais que si tu as besoin d'un WAF élevé (Wife Approval Factor 😉), il vaut mieux je pense mettre économiser et te diriger vers une solution Sonos. La mienne utilise Iris mais peste parfois à juste titre sur certains comportements 😄 

C'est le healthcheck qui te dit que le conteneur est malade.

Enlève le healthcheck et la ligne suivante (test: ...) du fichier compose.
Avec quel compte crées-tu tes 3 dossiers de données ? un utilisateur admin ?

Et tes logs ne vont pas plus loin que ça ? tu obtiens quoi comme erreur lorsque tu tapes dans ton navigateur l'IP de ton NAS suivi du port 7890 ?

Hello @LeoM tu serais le premier à t'intéresser à ce tutoriel 😄 Il est assez simple à mettre en place, mais pâtit de quelques défauts de "confort" depuis la dernière màj (il reste 100% fonctionnel).

Si tu veux pouvoir diffuser de la musique sur le périphérique "client" c'est possible aussi, mais c'est pas l'utilisation première prévue (diffusion multiroom et simultanée d'un OU plusieurs flux dédiés sur des clients différents).

Si tu rencontres des difficultés je serai là pour t'aider, ne t'inquiète pas.

Je plaide pour un simple problème de nom d'hôte utilisé.

Le plus simple est de faire tourner sa seedbox dans un conteneur, et d'y associer un client VPN, des tas d'image existent, par exemple : https://hub.docker.com/r/haugene/transmission-openvpn/

Il faut par contre avoir un NAS compatible Docker, pour DSM 7 c'est : https://www.synology.com/fr-fr/dsm/packages/ContainerManager
Pour DSM 6 c'est : https://www.synology.com/fr-fr/dsm/packages/Docker?os_ver=6.2

Pas d'expérience à ce sujet pour ma part, si je devais en acheter une pour mon RS422+ ce serait sûrement l'officiel (oui pigeon, mais pas envie de m'embêter avec d'éventuels problèmes de compatibilité).

@PascalFr Rien, une intuition, je viens de l'installer ça marche bien.
Mais j'ai dû créer les dossiers des volumes auparavant, car les ID utilisées par l'application (100/101) ne sont pas compatibles avec les ACL DSM qui empêchent la création automatique des dossiers.

Donc, si je reste sur les consignes du tutoriel, tu dois créer des dossiers data, config et logs dans ton dossier stirling.
Et pour la stack compose, si je suis les dernières consignes reprises sur le github, je dois monter :

- /volume1/docker/stirling/data:/usr/share/tessdata

et pas :

/volume1/docker/stirling/data:/usr/share/tesseract-ocr/5/tessdata

De ce que je peux voir les variables PUID et PGID documentées ne sont pas implémentées correctement, ce qui aurait permis de ne pas avoir à créer les dossiers manuellement. Ce sera peut-être corrigé à l'avenir, en attendant tu peux laisser les deux lignes les spécifiant dans ton fichier compose.