MilesTEG1

@loli71 De rien, pas de souci, je le mettrais à jour. Je vais faire un dépôt github ou un gist pour que ce soit plus simple ^^ Pourtant, dans tes commandes, c'est pas /tmp que tu utilises : Oui c'est sûr, mais pour être tranquille, j'aime bien que ça vérifie les dossiers. S'ils sont déjà existants, la commande ne fera rien 🙂 Très bonne idée 🙂 Je finalise le script dès que je peux, et le reposte. Tu verras si tu l'intègres au tuto et donc fait quelques modifs pour aller avec le script 🙂 (je n'oblige à rien 😉 )

Alors, avant d'aller faire dodo, superbe tuto qu'il me faudra mettre en place prochainement 😉 Deux petites choses que je ferais un peu autrement : Ce qui suit mérite d'être mis dans un fichier script, pour ne pas avoir de problème d'échappement de variable Je proposerai ceci : #!/bin/bash # Script pour télécharger la version choisie de wireguard-ui VERSION="0.5.1" # Changer la version pour pointer sur la dernière (voir un peu plus bas) ARCHI="amd64" # Changer architecture si besoin docker_volume="volume1" # Changer pour le volume dans lequel se trouve le dossier docker # Par exemple : volume4 nom_conteneur="wireguard" # Changer par le nom du conteneur qui sera créé. # Servira comme nom de dossier dans le dossier docker temp_dir="tmp/" ########################################################################################## # Si la volonté est d'avoir la dernière version disponible, ceci peut aider. # Commenter les 3 lignes suivantes si latest_gh_version="${$(curl -sL https://api.github.com/repos/ngoduykhanh/wireguard-ui/releases/latest | jq -r ".tag_name"):1}" printf "La dernière version disponible sur GitHub est la : %s\n" $latest_gh_version VERSION=latest_gh_version ########################################################################################## return_code="" dossier_conteneur="/${docker_volume}/docker/${nom_conteneur}" if [ ! -d "${dossier_conteneur}" ]; then echo "Le dossier ${dossier_conteneur} n'existe pas. On va le créer." mkdir -p "${dossier_conteneur}" return_code="$?" if [ "$return_code" -ne 0 ]; then echo "Erreur à la création du dossier temporaire $temp_dir... Fin du script." exit 1 fi fi return_code="" if [ ! -d "$temp_dir" ]; then echo "Le dossier $temp_dir n'existe pas. On va le créer." mkdir -p "$temp_dir" return_code="$?" if [ "$return_code" -ne 0 ]; then echo "Erreur à la création du dossier temporaire $temp_dir... Fin du script." exit 1 fi fi cd "$temp_dir/" wget -O "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" "https://github.com/ngoduykhanh/wireguard-ui/releases/download/${VERSION}/wireguard-ui-${VERSION}-${ARCHI}.tar.gz" || exit 1 tar -zxf "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" mv wireguard-ui "${dossier_conteneur}/wireguard-ui/wg-ui" rm -f "wireguard-ui-${VERSION}-${ARCHI}.tar.gz" # Fin du script. (Bon OK, je me suis un peu lâché ^^) Demain, enfin dans la journée, je ferais une autre version du script avec option --update pour faire la dernière partie avec ceci : cat <<EOF | docker exec --interactive wireguard bash s6-rc stop custom-svc-wg-ui.sh cp -f /wireguard-ui/wg-ui /app/wg-ui s6-rc start custom-svc-wg-ui.sh EOF

La comme ça je dirais de mettre des " " entourant l’URL. je regarderai demain.

Alors dans le LAN, ça cause bien plus de soucis qu'autre chose... Donc perso, je désactive l'IPv6. Sauf dans un cas particulier où je crois que je n'ai pas la possibilité de le faire : l'appleTV pour l'application OQee. C'est d'ailleurs pour cette dernière que mon routeur est relais IPv6 de la freebox. Sinon j'aurais aussi coupé l'IPv6 sur la connexion internet du routeur, enfin je veux dire que je n'aurais pas mis le RT en relais. Pour internet, là je laisse comme c'est. Et preuve que ça fonctionne bien 😉 L'autre raison, c'est que j'ai énormément de mal à assimiler les notions concernant l'IPv6... Je n'ai rien trouvé sur le net qui vulgarise le sujet suffisamment, ni trop pour que je puisse comprendre comment je peux affecter une IPv6 aux appareils sans les rendre vulnérables sur internet puisqu'en v6 il n'y a pas de port forwarding...

Pas sûr que ce soit ça qui coince... Sur mon RT (Synology je reprécise, avec SRM 1.3....) j'ai configuré le DDNS synology pour le VPN Plus Server que j'ai installé dessus. Et bien ce ndd obtient bien une adesse IPv4 et une IPv6 : Je ne sais pas si sur DSM la gestion est différente, mais mon RT qui est en DMZ de la freebox possède bien les deux types d'adresses IP. En revanche, pas mon NAS car j'ai désactivé l'IPv6 partout où je le pouvais dans le LAN.

Pour information, je peux connecter mon mac sur le vpn L2TP (sur mon routeur synology) via le partage de connexion 4G de mon smartphone qui possède une ipv6. mon routeur est derrière une Freebox Pop qui elle aussi possède une ipv6. le routeur en possède donc forcément une musique je l’ai configuré en relais ipv6 pour pouvoir bénéficier de OQEE sur mon AppleTV. bref tout ça pour dire que la connexion au VPN en L2TP fonctionne même s’il y a dès ipv6. par contre j’ai une ipv4 full stack sur ma connexion internet . Et sinon le smb ça n’est pas vraiment sécurisé, non ? donc l’ouvrir sur internet ne me parait pas du tout une bonne idée…

Il y a aussi ce forum dont la communauté francophone est très active : https://www.forum-nas.fr/ il y a plusieurs marques qui sont traitées et qnap c’est par ici : https://www.forum-nas.fr/categories/qnap.15/

@Mic13710 Ses règles de parefeu sont en effet un peu étranges. Mais il n'a pas besoin de dernière règle refusant tout sur tout car il est dans une interface spécifique, et tout en bas il a coché "Refuser l'accès" si aucune règle n'est remplie.

@StéphanHil faudrait regarder les réglages de tes pare-feu. et aussi , ton 718 et ton 218 sont-ils accessibles de la même manière sur internet ? ou bien y en a t’il un qui fait reverse proxy ? Il faut investiguer car ça n’est pas normal ce que tu décris . je suis dans le même cas que @Mic13710: nas accessible pour pleins de services sur internet mais 0 tentatives sur le compte admin ou un autre. regarde déjà ce qu’il en est du port ssh : est il ouvert sur le net ? Si oui c’est une bine mauvaise idée … je reviens à ce que j’ai dit juste avant : pare-feu ! Montre nous leur configuration.

Du coup tu mets vraiment le doute . Je me suis contenté de la mention HW, je n’ai pas regardé côté utilisation cpu … faudra que je Check ça . mais chez vous , pour ceux chez qui ça transcode pas en Hw, vous n’avez pas du tout la mention HW dans le Dashboard de Plex ? (Ou de tautulli)

@_DR64_Tu m'étonnes, avec le CPU à 100%, le NAS n'est plus bon à rien 😅

Donc là, je confirme, sans downgrade de PMS, ça fait bien du transcodage HW :

C’est étonnant , le transcodage HW fonctionne (enfin lorsque j’ai fait un test hier) sur mon 920+ pourtant équipé d’un cpu J4125… donc potentiellement dans la liste des cpu avec la régression de Plex… mon pms est en Version 1.32.2.7100 . je referais quelques tests demain.

@_DR64_tu voudrais bien contextualiser le dernier log que tu as donné ?

https://hub.docker.com/r/plexinc/pms-docker Du coup si ça ne change rien, c'est que l'utilisateur pour Plex n'a pas les droits d'accès sur les dossiers contenant les médias. Vérifie de ce coté-là.

Enlève la ligne UMASK, et met celle-là : - CHANGE_CONFIG_DIR_OWNERSHIP="true"

@_DR64_Comment ça tu ne vois pas tes médias ? je n'ai pas eu de soucis... ha si, il a fallu que je change les permissions du dossier de configuration : mettre l'utilisateur dédié aux médias-servers, celui placé en PUID et PGID dans le docker-compose. Sans cela, effectivement le PMS ne se lançait pas.

@_DR64_aux vues du log que tu as posté, je te suggère d’aller poster ça sur le forum officiel pour faire remonter le bug. Ils pourront aider à résoudre le souci. par contre essaye de mettre l’image officielle plutôt que linuxserver . j’ai du faire ça pour essayer les commandes qu’ils me donnaient. Depuis je suis resté sur l’image officielle. Linuxserver est bien, mais niveau aide/support quand il y a des soucis, c’est assez limité et ils bottent très vite en touche surtout si on n’utilise pas leurs méthodes d’installation préconisée. Exit Portainer pour eux…

Essaye de repasser sur une version antérieure de pms en spécifiant la version dans le fichier docker-compose. peut être qu’une des versions récentes a cassé le transcode hw avec le cpu du 918+ …

Avez vous fait un tour sur le forum officiel pour voir si le souci était signalé ? car si ce n’est pas le cas , le correctif n’arrivera probablement jamais. Autre chose : vu que vous avez les bonnes permissions sur /dev/dri/ avez vous tenté : 1. Le reboot du nas ? 2. Le reboot du pms ? 3. La re-création du conteur ? 4. Si tout ça ne fonctionne toujours pas , essayez en créant un autre conteneur avec un nouveau dossier de configuration vierge et avec seulement quelques médias pour tester le transcode HW. c’est grâce à ce point que j’ai vu sur le l’asustor que ça ne fonctionnait pas mieux… pour ensuite trouver qu’il s’agissait d’une nouvelle option de configuration du nas lui même dans ADM qu’il fallait cocher 😅

Ha oui J’ai pas précisé mais oui dsm 7.2 depuis quelques jours.

@maeglincomment est configuré le pare-feu du nas ? le port 443 est-il bien routé depuis la box vers le nas ? au besoin , j’ai un tuto rapide sur le reverse proxy et le nom de domaine synology. Si tu veux aller jeter un œil à mon profîl, tu auras le lien (vers un autre forum) : https://www.nas-forum.com/forum/profile/35059-milesteg1/?tab=field_core_pfield_14

Bonsoir, De mon coté, sur le DS920+, pas de soucis : PS : j'utilise la version officielle en Docker, pas en paquet. les permissions de /dev/dri et de ce qui est dedans :

@AlphAndruinoces erreurs sont dues aux caractères de retour à ligne qui diffèrent entre Windows (CRLF) et Linux (LF). N’utilise pas notepad mais plutôt un éditeur qui permet de changer les retours à la ligne comme vscode ou notepad++. ou bien tu édites tes fichiers depuis le nas directement.

@Slayer-fr Il me semble que j'ai déjà essayé DarkReader. Et j'ai abandonné. Je ne me rappelle plus pourquoi, mais si je n'ai pas continué, c'est qu'il devait y avoir une raison...