.Shad.

Disk et Monitor n'ont pas encore été mis à jour pour DSM 7 : https://synocommunity.com/package/synocli-monitor https://synocommunity.com/package/synocli-disk

@Einsteinium Après réflexion, je pense que ça ne suffira pas pour Plex, car on précise un PUID et un PGID (a priori pas videodriver), or on a besoin que l'utilisateur "abc" (utilisateur par défaut Linuxserver) appartienne au groupe videodriver (si on veut s'affranchir du chmod). Ca a été l'objet d'une demande, mais cela nécessite soit de build sa propre image (pas pratique), soit d'exécuter un script après chaque recréation de conteneur (pas pratique non plus). En réalité, l'équipe Linuxserver met de la mauvaise volonté pour corriger ce défaut, car Emby (l'image officielle) propose une bonne solution pour pallier ce problème, une variable d'environnement GIDLIST : GIDLIST=937 Dans le cas présent, ça ajouterait l'utilisateur courant du conteneur au groupe d'id 937 (videodriver), ainsi "abc" pourrait parfaitement accéder à /dev/dri/renderD128. Une autre solution est d'utiliser PGID=937, on se retrouvera avec des fichiers dont le groupe est videodriver, je ne trouve pas ça tip top, mais ça serait fonctionnel. Par contre, cela nécessite que les droits de l'utilisateur Plex soit définis au niveau de l'utilisateur et pas du groupe (users ou dédié). L'autre solution (la meilleure selon moi) serait d'utiliser des volumes docker et pas des bind sur l'host, mais on ne peut pas nommer ces volumes si on passe par l'interface Docker de DSM. D'un point de vue facilité, le chmod reste ce qu'il y a de plus simple en l'état.

Non rien de tout ça lol. C'est une suggestion soumise à l'expert mdr.

Rien, la suggestion s'adresse à @Einsteinium. 😉 Voir s'il pense comme moi déjà. 😉

@Einsteinium Je viens de remarquer une différence entre DSM 6 et DSM 7 en voyant le message de @GrOoT64. /dev/driv/renderD128 n'appartient plus à root/root mais root/videodriver. J'ai cherché avec find, je n'ai trouvé aucun autre fichier qui appartienne à ce groupe. Il serait dès lors beaucoup plus propre que l'utilisateur exécutant Plex via Docker soit membre de ce groupe, les permissions étant 660 par défaut ça devrait être fonctionnel. Et c'est beaucoup moins dangereux et permissif qu'un chmod 666. Il semblerait que le paquet Plex Media Server pour DSM 7 soit prévu pour utiliser ce groupe : https://www.gitmemory.com/issue/SynoCommunity/spksrc/4215/757384200 (pas directement lié vu qu'on parle de ffmpeg ici, mais on voit que Plex est inclus dans le groupe videodriver).

Je pense juste que l'emplacement a changé, mais autant voir avec les autres oui.

Pourquoi avoir deux clés différentes ? Quel intérêt ? Le message semble clair, la clé d'Artemis est sûrement d'un format trop récent pour WinSCP. Probablement que la clé d'Ares est plus ancienne et convient.

Le chmod du driver graphique et la création de device faut pas avoir peur quand même pour faire ce genre de chose. 😄 Pour Nginx, moi je vois ça chez moi :

Pas de raison que ça ne passe pas en même temps. 😉

Bienvenue, quels modèles de NAS possèdes-tu ?

Bienvenue, tu pourras faire tout ça et bien plus encore avec ce NAS. 🙂

Par défaut je crois que Plex expose son interface sur le port 32400. Vérifie donc qu'en tapant l'adresse IP du NAS suivi de ce port tu accèdes à Plex depuis ton PC. Attention qu'avec un 120j c'est l'entrée de gamme, il faudra que ta box soit en mesure de décoder les vidéos que tu liras, car ne compte pas sur le NAS pour transcoder à la volée.

Attend que l'indexation se termine dans un premier temps. Il m'arrive que certaines photos n'apparaissent que lorsque l'indexation est terminée.

Tu peux déjà regarder si c'est bien Webstation qui émet sur le port 80 sur ton NAS et que quelque chose d'autre n'a pas pris sa place. Tu peux commencer par taper en SSH sur ton NAS : netstat -tunlp | grep 80 Tu dois également vérifier que ta box effectue bien une redirection du port 80 vers le NAS. Et que l'interface de la box n'est pas déjà sur le port 80 (HTTP).

Je ne pense pas qu'une synchronisation des NAS te permette d'utiliser indistinctement les applications de l'un ou l'autre car les données des applications se trouvent généralement dans des dossiers partagés cachés. Pour les serveurs mails c'est ambitieux de vouloir les utiliser pour le boulot. Ce n'est pas facile à maintenir, et le risque que ses mails atterrissent en spam ou qu'elle ne reçoive pas certains mails n'est pas négligeable. Pour Minecraft, tu peux poster un sujet dans la section dédiée en suivant les instructions du fil qui s'y trouve en post-it.

Bienvenue 🙂

En ligne de commande seulement que je sache.

Bienvenue !

Tu peux toujours utiliser du chiffrage gpg dans ton script pour ne pas mettre en plain text ton mot de passe maître. En utilisant une paie de clé publique/privée gpg par exemple. Comme l'a dit @Jeff777 tu as un accès en cache via les applis à ton coffre. Pour ma part j'ai une tâche récurrente mensuellement dans mon calendrier qui me rappelle d'exporter mon coffre BW 😄 Et j'ai une sauvegarde tous les trois jours des données de mes conteneurs.

@superspiff83 Par sous-domaine non existant tu entends quoi ? pas renseigné par ta zone DNS (mais de souvenir tu avais un enregistrement wildcard (*) dans ta zone DNS) ou pas couvert par ton certificat (si tu fais une validation DNS par OVH alors c'est normalement une certification wildcard que tu obtiens, donc tous les sous-domaines de ton domaine racine sont couverts. En utilisant les ports personnalisés à la place des domaines personnalisés dans le portail des applications de DSM ça ne fonctionne pas ?

Non

Jusque-là il fallait s'amuser à aller dans les réseaux, il était temps !

Je te dis j'ai jamais eu besoin de créer ce dossier. Simplement celui pour les fichiers de configuration stipulé dans la doc.

Oui mais ce que je veux dire c'est que ce chemin concerne le conteneur et pas le NAS. Donc créer ce dossier sur le NAS ne fera rien. 🙂

Un conteneur ne te donnera jamais d'infos dans ses logs ni où que ce soit relatives à un chemin sur le NAS. Uniquement au sein du conteneur. Donc si tu as créé ce dossier sur le NAS c'est logique qu'il soit vide. Un conteneur n'a aucune idée de l'arborescence de son hôte, jamais.