.Shad.

Pourquoi n'as-tu pas contacté le support Synology ? C'est la première chose à faire si un problème persiste. Si tu n'arrives plus à le démarrer, on ne pourra pas t'aider.

Tu peux déjà suivre les recommandations de @morgyann Plus simplement, tu peux réactualiser le page avec CTRL+F5 sur Chrome, ou faire un test en navigation privée.

@morgyann De ce que je lis ici : https://hub.docker.com/r/linuxserver/ffmpeg J'ai l'impression que ton WP (Conteneur ou natif ?) doit pouvoir exécuter les commandes de création éphémère de conteneur pour transcoder un fichier donné, soit dans le même répertoire, soit dans un répertoire précis. Ca pourrait déjà être intéressant que tu nous dises ce que tu as tenté, et où ça a échoué. C'est une image inhabituelle c'est tout à fait normal que tu rencontres des obstacles.

Il faudra passer par la création d'un projet pour monter tes disques, la création d'un conteneur ne suffira pas, mon setup utilisé pour mon serveur Debian : version: "2.1" services: scrutiny: image: ghcr.io/analogj/scrutiny:master-omnibus container_name: scrutiny networks: - net-proxy cap_add: - SYS_ADMIN - SYS_RAWIO environment: - COLLECTOR_CRON_SCHEDULE=10 6 * * * - TZ=Europe/Brussels volumes: # config - /opt/scrutiny/config:/opt/scrutiny/config - /opt/scrutiny/influxdb:/opt/scrutiny/influxdb # system mounting - /run/udev:/run/udev:ro devices: # disks - /dev/sda:/dev/sda - /dev/sdb:/dev/sdb - /dev/sdc:/dev/sdc - /dev/sdd:/dev/sdd - /dev/nvme0:/dev/nvme0 - /dev/nvme1:/dev/nvme1 labels: # watchtower label only monitoring - "com.centurylinklabs.watchtower.enable=true" restart: unless-stopped networks: net-proxy: external: true A adapter à ton besoin, les disques (/dev/sdX) peuvent s'appeler différemment sur ton installation de DSM. Concernant /opt/scrutiny/config, il faut transformer ça en /volume1/docker/scrutiny/config par exemple, même chose pour /opt/scrutiny/influxdb.

Bienvenue parmi nous!

Salut, un reset mode 1 permet de rétablir la configuration réseau d'usine sans perte de données, la seule chose à faire est de redéfinir les credentials du compte administrateur. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_reset_my_Synology_NAS_7

Pas sûr de comprendre, ton site en construction intègre la page d'accès au Synology dans un genre d'iFrame ?

Bienvenue parmi nous ! Profite de ton passage ici pour vérifier que la sécurisation de ton NAS est suffisante :

Salut, soit j'ai pas compris soit ton setup, très sympa au demeurant, n'a rien à voir avec Synology ?

Passe le paramètre debug à true dans ton fichier conf.

Je comprends tout à fait ta remarque, mais ce tutoriel n'a pas pour vocation de pousser le cran de la sécurité au maximum. Une fois les utilisateurs un peu plus aguerris, ils pourront tout à fait réduire par exemple la plage 192.168.0.0/16 à leur sous-réseau en particulier. Même chose pour 10.0.0.0/8 avec le sous-réseau qu'ils vont utiliser avec leur éventuel serveur VPN. Et comme tu dis, on peut tout à fait réduire la surface d'exposition par rapport à celle préconisée ici. L'idée est aussi qu'à la moindre d'installation de paquet, ils ne se retrouvent pas bloqués parce que les règles sont trop restrictives (je pense à VPN Server et Container Manager par exemple). Les considérations que tu évoques pourraient probablement l'objet d'un tutoriel axé sur la sécurisation pour utilisateur avancé.

As-tu réellement besoin d'attribuer une IPv6 à ton Pi-hole ? Personnellement mon trafic est grande partie en IPv6 (dual stack natif chez mon fournisseur), et les requêtes sont traitées par mon Pi-hole qui ne dispose que d'une IPv4.

@CMDC83 Je ne comprends pas ton propos, la partie spoofing dont tu parles concerne les attaques sur ton IP publique, dans ce cas on parle de plage d'IP bogon, les ranges d'IP qui n'ont pas vocation à apparaître dans les échanges publiques, dont les plages d'IP privées définies par la RFC1918 ainsi que certains autres blocs Bogon IP addresses, ipv4 and ipv6 bogon IP Ranges (ipgeolocation.io) Sauf à ce que ton NAS établisse une connexion PPPoE directe avec ton fournisseur d'accès, cas qui n'est pas prévu par le tutoriel, il ne dispose pas d'une IP publique IPv4. Et tout les fournisseurs d'accès intègrent dans leurs box les règles de drop pour le spoofing. 10.0.0.0/8 est dans l'extrême majorité utilisé par les réseaux VPN. Or, pour la portabilité des noms de domaine, il est pratique de pouvoir atteindre une adresse en 192.168.0.0/16 depuis 10.0.0.0/8. Si tu établis un serveur VPN chez toi pour te connecter de manière sécurisée, je ne vois aucun problème à autoriser cette plage d'adresses. Les utilisateurs plus avancés pourront mettre en place un serveur DNS local avec des vues VPN et LAN séparées. Mais ce tutoriel va à une solution plus simple avec très peu de (voire aucun selon moi) compromis sur la sécurité.

Visiblement c'est la partie IPv6 qui pose problème. Est-ce que la gateway a bien toujours la même IP link-local que celle renseignée dans le réseau macvlan ? Sans être une solution, un contournement : https://github.com/moby/libnetwork/issues/2455 La team Docker n'a pas l'air pressée de traiter ce problème. Mais ici : https://github.com/moby/moby/issues/43466 Apparemment c'est l'utilisation de SLAAC sur le NAS qui engendre ce problème. Est-ce que tu obtiens tes IP via SLAAC ou DHCPv6 ?

@CyberFr L'idée de ce tutoriel est de limiter les réglages à un usage basique néanmoins sécurisé pour néophyte. C'est pourquoi seule la configuration de LAN 1 est évoquée, c'est transposable à LAN 2, etc... Paramétrer l'interface VPN de DSM implique généralement qu'on a mis en place VPN Server. Qui implique selon moi l'assimilation et la mise en places des recommandations du présent tutoriel. Configurer les règles par interface permet notamment de maîtriser beaucoup plus facilement ce qui est exposé et où c'est exposé. Pour un utilisateur tel que toi, tu apprendras assez peu de choses, ça reste intéressant de le lire en diagonale, notamment les règles concernant IPv6.

Dans la résolution DNS elle n'intervient pas, elle communique au moment de l'octroi du bail DHCP quel(s) serveur(s) DNS utiliser, ça c'est vrai. Pour ton problème, je n'ai jamais eu le moindre souci, mais j'utilise les connexions RJ45 natives du NAS. Quand tu dis que le Pi-hole reste en plan, tu veux dire que le conteneur n'est pas créé ? ou que la résolution DNS ne fonctionne pas ? ou que l'interface virtuelle n'est pas encore montée ? Pour la température elle correspond à celle du capteur CPU.

Je ne suis pas très calé sur ce sujet-là, je laisse @Mic13710 et @maxou56 donner leur avis, ils sont bien plus compétents en la matière.

Je trouve la suggestion intéressante, j'en ouvrirai aussi une dans ce sens. 🙂

Est-ce qu'à l'installation, le paquet n'a pas créé un utilisateur dédié ? Via le terminal, tu peux essayer via un utilisateur administrateur : ps aux | grep jellyfin ou juste ps aux et vérifier si un processus correspond à Jellyfin, la première colonne de l'output te dira quel utilisateur exécute l'application. C'est de cet utilisateur dont tu devras t'assurer qu'il a les accès suffisants pour parcourir la bibliothèque. Je recommande l'utilisation de Docker plutôt que de passer par un paquet Synology pour ce genre de logiciel, car ils ont vite tendance à placer des fichiers à des endroits indéterminés dans DSM et créer des utilisateurs dont l'octroi des permissions est flou.

Salut, As-tu une sauvegarde récente des données ? Autre chose, as-tu essayé de démarrer en enlevant un disque alternativement ?

Même si tu as plusieurs utilisateurs dans Jellyfin même, un seul utilisateur exécute le programme. Via Docker j'imagine ?

Salut, Il faut que l'utilisateur correspondant aux PUID/UID et PGID/GID dans la configuration du conteneur (emby ou jellyfin) ait les droits en lecture écriture et le droit de traverser sur un dossier partagé. L'accès en lecture également le droit de traverser les dossiers.

Salut, A partir du moment où le fichier de configuration ne se situe dans pas dans /volumeX, alors le plus simple est d'utiliser l'accès via SSH pour le modifier. Pour son emplacement c'est difficile à dire, je ne sais pas où les paquets tiers sont installés, s'il y a un emplacement privilégié, je n'en utilise pas. Par contre pour faciliter l'utilisation du terminal tu peux installer les paquets SynoCLI de SynoCommunity, ils ajoutent des commandes dans le shell, la plupart sont très utiles et certaines même indispensables à mes yeux.

Tailscale est également une solution, mais tes données transitent aussi par un service tiers. Et il a des fonctionnalités que QuickConnect ne propose pas, à savoir créer un réseau VPN entre tous tes périphériques utilisant Tailscale. Mais ce n'est pas un paquet Synology, donc pas de support officiel.

Effectivement, simplissime. 🙂