JacquesF

Members
  • Content Count

    378
  • Joined

  • Last visited

  • Days Won

    11

JacquesF last won the day on April 10

JacquesF had the most liked content!

Community Reputation

44 Excellent

About JacquesF

  • Rank
    Super Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Ah ces américains, peuvent pas écrire Octets comme tout le monde (ou presque...) Bon, là c'est un problème plus simple à tester. Jacques
  2. Comme je l'ai écrit plus haut, il suffit de les arrêter une à une et de regarder avec la commande les connexions qui ont disparues. Ensuite, regarder l'appli et son paramétrage si le débit a significativement baissé. Si le NAS est accessible de l'extérieur, le proxy peut être utilisé par des hackers pour lancer des attaques ou naviguer en toute discrétion par exemple. A suivre...
  3. Bonjour, Est-ce que tu utilises Docker ? Si oui, regarde quelles sont les applications qui fonctionnent dedans et arrête les une à une pour voir (toujours avec la même commande) si les connexions en ESTABLISHED liées à Docker disparaissent. Je n'utilise pas docker, mais il y a pas mal de monde qui s'en sert sur ce forum et on pourra t'aider en cas de problème de configuration. L'important est de trouver quelle application génère ces connexions, et probablement ce trafic en plus, pour ensuite pouvoir la corriger ou la supprimer si elle ne sert vraiment pas. Jacques
  4. Bonjour, et désolé pour le retard. L'essentiel des connexions semble être causé par nginx (en proxy ?) et docker-proxy et aussi DownloadStation. Si le proxy est ouvert, alors il est possible qu'il serve à pas mal de personnes à l'extérieur. Dans les programmes qui ont des connexions ouvertes, on ne voit que ceux-là pour le moment : docker-proxy nginx: worker synodlwget (DownloadStation) sshd (en local uniquement) Le plus simple est de couper une à une les VM qui sont gérées par Docker (si le nom docker-proxy n'est pas significatif pur isoler la VM
  5. La commande netstat existe sur Synology. Un netstat -lataupe (le second a n'est la que pour se souvenir de la commande, un autre façon de s'en souvenir mais moins élégante est -lapute) en root dans un console SSH devrait indiquer quelles sont les connexions établies, et éventuellement trouver les programmes actifs qui ne devraient peut-être pas y être (présence de trojans ou de virus au cas où). Selon les résultats, on pourra aller plus loin. Jacques
  6. Bon, c'était plus simple effectivement... Ça servira peut-être à d'autres les idées développées ici. Bonne fin de journée Jacques
  7. Bonjour L'idée d'Evotk (sauf erreur d'interprétation) n'est pas de rajouter un disque, mais d'utiliser un disque sur lequel tu installes la même version de DSM. Ensuite, quand tu veux tester une mise à jour, tu déconnectes tous tes disques, insère ce disque à la place et teste cette mise à jour sur ce disque. Si tout se passe bien, tu peux raisonnablement penser que ce sera la même chose sur la version "utile" de ton NAS. Dans ce contexte, il est intéressant d'installer les packages dont tu as vraiment besoin (surtout pour docker et la gestion des caméras éventuellement), b
  8. Le paramètre a disparu de la configuration en 6.2, auparavant il était dans Panneau de configuration / Réseau / Interface réseau / Modifier / Activer Jumbo Frame Ceci permettait de modifier le MTU. En 6.X, le chemin est le même mais le nom est devenu Configurer manuellement la valeur de la MTU. Si la valeur est différente, on peut rencontrer des soucis (je l'ai vécu) bien qu'en théorie la valeur du MSS étant échangée à la connexion entre les PC on ne devrait pas dépasser celle du MTU... mais bon, ça n'a pas l'air d'être vrai dans tous les cas. Les switches gigabit SOHO ne
  9. Bonsoir, Est-ce que les Jumbo Frames n'auraient pas été activées dans la configuration du Syno (et pas pour le reste du réseau, switch compris) ? Ou l'inverse, activées sur les PC mais pas sur le NAS ? Ça pourrait être une piste, sur les gros transferts,le fait d'utiliser des trames dont la taille n'est pas standard entraîne un échec de transport, et une réémission qui sera de nouveau un échec, etc... Autre possibilité, un MTU incohérent sur les équipements réseau ou les interfaces (1500 pour ethernet). A vérifier Jacques
  10. Bon, c'est en route en ce cas. Le disque 1 peut être réutilisé (provisoirement) pour archiver des données (après reformatage) présentes sur le NAS dans l'attente du transfert sur le raid reconstruit ; idem pour le disque 3 ensuite, ce qui fait tout de même 4To pour récupérer les données non encore sauvegardées. Avec un peu de chance (pas de panne critique avant le re-transfert des données vers le NAS et son nouveau raid), ça devrait permettre de tout récupérer sans trop de mal. On peut insérer le disque dans un boîtier USB (ou un adaptateur) ou en l'ajoutant provisoiremen
  11. À l'exception des disques B / E / F et D malgré une erreur de lecture, les autres disques présentent des signes d'erreur : sda : secteurs réalloués = 6 sdc : secteurs réalloués = 1 Ce n'est pas encore critique, on est loin du seuil, mais ça correspond justement à la position des disques "mal positionnés" dans le raid logiciel (mdadm n'a pas de disque 0 et 2 pour le périphérique md2, qui est volume1). Je n'ai pas trouvé sur le Syno un fichier de configuration pour mdadm, le scan doit être refait à chaque démarrage. Je suppose que tu as déjà redémarré le NAS,
  12. Ça ressemble plus à une incohérence du DSM qu'à une panne réelle... Dans l'état des disques LVM, je ne vois aucune erreur. Et dans l'état du raid, les 3 volumes sont vus en état clean (l'indication degraded pour md0 (DSM) et md1 (swap) est normal, le raid étant prévu pour prendre en compte tous les disques "gérables" dans la NS émulé par Xpenology (soit 12 disques dans ce cas). Il y en a donc 6 qui sont absents. La seule anomalie que je vois est la numérotation des disques du raid md2 (accessible via LVM via vg1000 est monté dans /volume1. Les disques 0 et 2 (partitions sda
  13. Bonjour, J'ajouterai à la demande de Nicoueron le contenu du fichier mdstat (résultat de la commande en SSH 'cat /proc/mdstat') puisqu'il s'agit d'un raid SHR (donc raid Soft sur LVM) ainsi que l'état des volumes logiques (commandes lvm suivies des options lvscan / pvscan / vgscan / vgdisplay) soit pour la 2ème commande : lvm pvscan. Ça permettra de savoir (peut-être) ce qui est vu en faute. Tu peux aussi ajouter le résultat de la commande mdadm --detail /dev/md* (toutes les commandes sont à lancer sous le compte root). Merci
  14. Bonjour, Tout à fait d'accord avec Nicoueron, en Gb/s les 8 fils sont utilisés (2x2 dans chaque sens). L'avantage du Gb est qu'on peut connecter directement les 2 machines avec un câble droit ou croisé peu importe, l'interface s'adapte. Comme tu semble avoir un routeur entre, il y a au moins 1 câble qui devrait marcher pour faire un test en direct sans passer par le switch. Ensuite, tu pourras aviser selon les résultats. Jacques
  15. Bonjour, Pas vraiment testé, mais j'ai déjà installé MacOS sous VirtualBox, donc en principe ça peut se faire en VMM. En fait, depuis que Apple utilise des processeurs Intel, la virtualisation est envisageable. Mais comme le dit Nicoueron, la gestion du clavier sera une émulation mais les touches Win devaient pouvoir se configurer en touches spécifiques MAC. Reste la souris qui est différente aussi... Ça vaut le coup de tenter de toute façon. Jacques