Fenrir

Quel modèle de nas as-tu ? Quelle version du DSM est installée ? As-tu redirigé les ports sur ton routeur ? As-tu activé/configuré le firewall du nas ?

Il n'y a qu'un cas où la qualité est dégradé : quand le synology fait du transcodage : si tu désactives le transcodage, il n'y aura aucune altération de la part du syno. Pour les formats supportés, aucune restriction, pour le syno il s'agit simplement de fichiers, peut importe le format, sauf dans 2 cas : lecture depuis une application synology : DS audio (sur android, ios, ...) et Audio Station (en mode web ou via un haut parleur usb) si tu fais du transcodage : dans ce cas il est limité aux formats qu'il reconnait (de mémoire : flac, mp3, wav, aac, ogg, aiff) Dit autrement, ça ne dépend pas du synology mais de ce que sait lire ton lecteur (tv, ampli, ...)

en fait comme je ne savais pas que sda était un disque neuf, j'ai cru que tu étais entrain d'écrire sur le disque système de ton pc. Par contre il est possible que ta commande ne se termine pas correctement (par exemple si sda est plus petit, même de quelques octets que sdb) ou que le résultat ne soit pas exploitable. Laisse le finir et regarde si tu arrives à récupérer quelque chose sur sda (refais les commandes de diag du début), tu peux aussi tenter de le mettre directement dans le syno.

@kanjusei : je suis d'accord que la 5.2 fait perdre un peu de débit sous Windows (10% chez moi), mais pas à ce point (passage de 90mo/s à 11mo/s)

normalement ça ne change rien que tu sois en raid

ouf, non la commande est terminée ?

les chromecast ne font pas de dlna, mais VideoStation (l'appli de gestion des video des syno) les gèrent très bien oui non essaye d'optimiser un peu ton wifi (cf plus bas) oui, n'oublie pas de laisser la petite "rallonge" hdmi sur la chromecast, elle fait office d'antenne avec un bon wifi ça passe sans soucis ---------------------------- Vu ce que tu dis sur ton wifi, il serait peut être judicieux de commencer par là Tu devrais pouvoir améliorer la situation en faisant quelques ajustements : changement de canal de ta borne wifi pour un autre canal moins encombré : c'est surtout valable en appartement avec plein de voisin mais c'est aussi vrai s'il y a des appareils électrique à proximité (micro onde, allogène, chaine hifi...) passage en 40mhz si ta borne le gère déplacement de la borne dans un endroit plus adapté : je vois trop souvent des bornes wifi contre un mur => perte importante de signal et de couverture : il faut laisser au moins 30cm autour et/ou mal orientés : les bornes des particuliers sont en théorie omnidirectionnelles, en pratique elles ont une orientation préférentielle et/ou dans un coin de la maison : au milieu c'est plus efficace achat d'une borne wifi de meilleur qualité en complément ou en remplacement (dans les 30€ pour un produit correct), il y a aussi des pack CPL+wifi qui marche très bien (plus cher mais plus pratique), par contre évite les répéteurs (on à un signal wifi très fort, mais le débit entre le répéteur et la borne est souvent catastrophique)

Quand je dis "au moins autant", c'est pour indiquer qu'on peut faire du mauvais IPsec (clef partagée courte, authentification PAP et chiffrement faible) et du très bon https (pfs, hsts, courbe elliptique, ...). Dans une configuration standard, un vpn ipsec apporte plus de sécurité que de l'https, mais aussi plus de contraintes (il faut configurer la connexion vpn sur chacun des clients, alors qu'en https, il suffit de donner le lien). Si tu veux plus de détails, je te recommande de chercher sur le forum, il y a de quoi faire

Quand tu dis que la connexion Internet fonctionne, tu test depuis ton pc ou depuis le nas ? J'ai déjà un problème du genre, bien que mon nas soit en DHCP, il avait gardé un mauvais paramètre comme s'il était en ip fixe (dans mon cas c'était le DNS). Pour corriger le problème, configure le nas en IP fixe en renseignant bien le routeur et les DNS, valide que ça fonctionne puis repasse le en DHCP (enfin si tu le souhaite)

c'est quoi /dev/sda ???? si c'est le disque de ton pc, tu es entrain de copier les blocs du disque sdb sur le disque sda, tu es certain de ce que tu es entrain de faire là ??????? si sda est le disque "normal" de ton pc (c: sous windows), tu viens de le flinguer (pas physiquement, mais les données sont perdues) tu as bien lu mon message en gras et en rouge au début du post précédent ? dans tous le cas, tu peux annuler la commande, peu de chance que ça soit utilisable

EDIT : attention, j'avais mal lu ta commande, tu redirige sur /dev/sda1.gz, qui heureusement n'existe pas, à peu de chose près tu allais écraser le disque de ton pc redirige (le > ) vers un fichier dans un dossier, surtout pas vers /dev ​Si tu fais ça sur un live CD sans avoir ajouté un support de stockage, tu vas avoir du mal à copier les données Branche un disque externe ou monte un volume réseau (en nfs par exemple) Tu peux aussi segmenter le zip de sortie en plusieurs "petits" fichiers si tu n'as de pas disque assez grand ​là ça ne sent pas bon, tu peux oublier le mode "j'ai de la chance", au moins pour le moment Une fois le dump du disque effectué, essaye la méthode proposée ici : http://unix.stackexchange.com/questions/42277/linux-repairing-bad-blocks-on-a-raid1-array-with-gpt

En IPsec, au moins autant que du https avec login+password ​Du coté syno, ça prend 2 minutes et sur les périphériques (android, linux, ...) c'est pareil La contrainte, c'est que si c'est pour rendre accessible des services à plusieurs personnes (un site web par exemple), ce n'est pas adapté, mais si c'est pour 2/3 personnes, c'est nickel

dans le pannueau de conf du syno, tu as une option pour activer le SSH (dans terminal et snmp) Le SSH c'est un protocole qui te permets d'accéder en commande à ton syno, en général pour faire des réglages plus avancés. Tu n'as pas besoin de t'en servir et encore moins de le rendre accessible depuis Internet, c'est juste pour avoir une autre porte d'entrée sur ton syno en cas de problème avec l'interface web

​de ?

​ls /dev/md* il ne devrait pas y en avoir d'autres, sauf si ton linux est en raid

pour répondre à ton autre post, aucune idée, par contre une mise à jour vient de sortir, en théorie elle corrige le problème d'hibernation

Tu peux aussi activer le ssh sur le syno (sans l'ouvrir à tout le monde), comme ça tu auras un autre accès au nas en cas de problème.

https://www.synology.com/fr-fr/knowledgebase/tutorials/493 Dans ton cas, tu dois réinstaller le système d'exploitation

J'ai fait quelques tests, mais simuler des secteurs défectueux n'est pas chose facile dans une vm, donc pas certain que mon test soit pertinent, d'autant que je ne suis pas sûr du type de problème rencontré. -------------- pour chacune des commandes qui suit : adapte le nom du device à ton conf (sdX, mdX, ...) et post le résultat ici -------------- Commence par faire un dump de la partition raid, il faut de la place (au moins autant que la taille du disque) et du temps (c'est fonction de la vitesse de tes disques, de leur état et de la taille du volume) : dd if=/dev/md0 conv=sync,noerror bs=64K | gzip -c > /un/endroit/avec/plein/de/place/md0.gz Il faut remplacer md0 par la valeur qui va bien. Si ça ne marche pas, fait un backup de la partition complète (/dev/sdb3 d'après ta capture), voir du périphérique (/dev/sdb) : dd if=/dev/sdb3 conv=sync,noerror bs=64K | gzip -c > /un/endroit/avec/plein/de/place/sdb3.gz Tu as maintenant une copie de ton volume à conserver. Test aussi la commande suivante : mdadm --examine /dev/sd[bcdefghijklmn][1234] >> conf.raid && cat conf.raid Ça devrait te retourner les infos du raid dans le fichier conf.raid (il faut les garder : copier coller quelque part, entre autre ici) ------------------------- Ensuite tu peux tester le mode "j'ai de la chance" : gunzip /un/endroit/avec/plein/de/place/md0.gz mkdir /mnt/loop1 mount -o ro,loop /un/endroit/avec/plein/de/place/md0 /mnt/loop1 ls /mnt/loop1 Si tu as de la chance, tu devrais voir des fichiers. Si ce n'est pas le cas, post le résultat de la commande : file /un/endroit/avec/plein/de/place/md0 Si rien ne marche, on testera autre chose, mais ça va devenir violent (et je ne suis pas certain de me rappeler comment faire, je n'ai pas travailler sur des blocs depuis plus de 10 ans)

Rien ne t’empêche d'activer le HTTPS, tu n'es pas obliger de le forcer, il faut juste ouvrir des ports supplémentaires. Pour la sécurisation : tous les comptes doivent avoir un vrai (complexe et long) mot de passe active le firewall du synology active l'anti brute force et le ddos chiffre les communications qui peuvent l'être Le serveur VPN du synology permet d'avoir un bon niveau de sécurisation sans trop se prendre la tête (personnellement c'est comme ça que j'accède à la plupart des services de mon syno)

Tu as plus de chance de perdre tes données en branchant le disque sur un poste windows (même sans rien faire), qu'en tentant de le monter sous linux (à condition de ne rien faire) J'installe la vm et je reviens

Avant tout, backup tes données ailleurs que sur le nas (au moins temporairement) C'est possible mais il faut faire pas mal de manip (passer le syno en SHR, retirer un disque, en remettre un autre, reconstruire le raid, retirer un disque, étendre le volume, supprimer le shr, remettre le disque) Un backup de la conf et une réinstallation complète devrait te prendre moins de temps (sauf si tu as fait beaucoup de changements)

En théorie c'est possible de downgrader (la procédure est dans ton précédent post), mais je ne l'ai jamais tenté. Ce que tu peux aussi tester, c'est une fresh install sur tes autres disques dans la même version pour vérifier si le problème existe dans la conf par défaut. A noter que je n'ai jamais eu une telle baisse de débit, quelque soit la version

si ton raid est endommagé il est possible que mdadm ne le reconnaisse pas, ce qui est étrange c'est que ton appli graphique elle le reconnait. Tu as essayé de la monter avec cette application ? Je vais créer une petite vm avec du raid pour voir si j'arrive à reproduire ton problème, si j'ai des news je te ferai un retour

Il doit y avoir un problème avec ta commande, dans le pire des cas elle ne s'est pas appliquée où il fallait cd /volume1/XXXXXXXX/ mv * /volume1/Serveur/XXXX/ je ne sais pas comment tu l'as entré dans le gestionnaire des taches, mais si les sauts de lignes sont mal interprétés, tu as peut être fait de la casse (ça dépend d'où est le chemin par défaut) Chez moi le path par défaut des commandes est /usr/syno/synoman/webapi et les sauts de ligne sont correctement interprétés Donc si le mv s'est fait dans ce dossier, tu as cassé une partie du système => reset (ça n'efface pas les fichiers, juste la conf) Dans tous les cas, bien qu'il soit un peu tard, quand on fait une commande de ce type, surtout en root : on ajoute des tests on précise les chemins en entier (mv * à remplacer par mv /volume1/XXX) on met le tout dans un script (comme dans l'exemple de l'interface)