thetib

Merci pour votre retour et vos conseils. J’ai justement effectué ces vérifications depuis mon dernier message : Conseiller en sécurité : analyse complète effectuée. Tous les contrôles de sécurité sont au vert, aucun logiciel malveillant ni anomalie détectés. Seules quelques mises à jour de paquets étaient signalées. Utilisateurs DSM : liste vérifiée, aucun compte inconnu. Les comptes admin et guest sont désactivés, et mon compte principal est protégé par la double authentification. Planificateur de tâches : vérifié également. Il ne contient que deux tâches Hyper Backup connues, dont une désactivée. Paquets, conteneurs et processus : vérifiés, rien de manifestement suspect. Connexions actives : uniquement des connexions locales lors du contrôle.

Au 17/10/26 le NAS affiche plus de neuf jours de fonctionnement continu, sans le moindre blocage depuis qu'il est isolé de l’extérieur En examinant les journaux DSM, j'ai découvert un nombre très important de tentatives de connexion provenant d'Internet. L'export CSV du journal de connexion contient 8960 événements : 8 926 tentatives extérieures refusées ; 1 281 adresses IP publiques distinctes ; aucune connexion extérieure réussie détectée dans les événements conservés. Les tentatives utilisaient de nombreux identifiants différents Le volume était particulièrement important les 5 et 6 octobre, avec respectivement environ 2 700 et 4 600 tentatives refusées. Depuis la fermeture des accès extérieurs le 8 octobre, les connexions visibles dans les journaux proviennent uniquement du réseau local. Actuellement Comptes admin et guest désactivés. Compte administrateur temporaire utilisé pour les investigations SSH à nouveau désactivé. Double authentification active sur mon compte principal. Service SSH désactivé Voila le pourquoi du comment je suppose .... Misère ça fait peur 😨 Donc je vais relire et appliquer le tuto de sham comme me l'a dit Mic13710 https://www.nas-forum.com/forum/topic/77493-tuto-pas-%C3%A0-pas-s%C3%A9curisation-du-nas-pour-dsm-7/page/9/#comment-1319530999 A votre avis je dois faire quelque chose d'autre ? merci encore pour vos conseils

👍 Merci pour votre réponse Cela reste un mystère … depuis que j’ai isolé mon de l’extérieur plus aucun problème 🤔 Je vais remettre à plat tous mes paramètres de sécurité comme dans votre tuto, et puis on verra bien …

Ok merci beaucoup je vais suivre ce tuto à la lettre Et vous pensez que c’est la cause du dysfonctionnement que je subis ? Merci encore Guillaume

Salut Mic, Si j’avais suivi le tutoriel pas à pas il y a qq années. Mon nas comprend un compte administrateur ( qui ne s’appelle pas admin ) qui est désactivé Identification à deux facteurs etc. etc. Mais Il est vrai que j’utilise QuickConnect

Bonjour à tous, Je reviens vous donner quelques nouvelles de mon DS416play. Suite à vos conseils, j’ai décidé d’isoler complètement le NAS des accès extérieurs afin de vérifier si cela pouvait avoir un rapport avec les blocages. Le 8 octobre, j’ai donc : désactivé QuickConnect ; désactivé toutes les redirections de ports de ma Livebox vers le NAS ; activé le pare-feu DSM en autorisant uniquement les connexions depuis mon réseau local. J’ai ensuite effectué un redémarrage propre du NAS le 8 octobre à 11 h 29. Résultat : cela fait maintenant trois jours que le NAS fonctionne sans aucun plantage. Pour rappel, les blocages avaient commencé brutalement le 2 octobre, alors que le NAS fonctionnait parfaitement auparavant. Une idée ? Merci encore pour vos conseils. Je vous tiendrai informés de la suite.

Salut Merci pour ta réponse Pourquoi ? edit : j'ai fait ces modifications : Le pare-feu DSM est désormais activé, avec une règle autorisant uniquement mon réseau local, suivie d'une règle refusant les autres connexions. J'ai également désactivé QuickConnect et les six redirections NAT/PAT qui existaient sur ma Livebox (FTP, HTTP, DSM 5000/5001, WebDAV et un autre service). La DMZ est vide, aucune redirection UPnP ne concerne le NAS, et aucune ouverture de port ou de protocole IPv6 n'est configurée. Le pare-feu de la Livebox est sur « Moyen ».

Mise à jour après une nouvelle récidive et analyse des logs par chat : Le problème s'est reproduit. Cette fois j'avais activé SSH afin d'essayer de récupérer des informations avant de redémarrer. Pendant le blocage : le NAS répondait toujours parfaitement au ping ; les ports SSH (22), DSM (5000) et SMB (445) acceptaient toujours les connexions TCP ; mais SSH restait bloqué avant même l'affichage de la bannière (kex_exchange_identification ... timeout) ; une requête HTTP sur le port 5000 établissait la connexion mais ne recevait aucun octet ; SMB ne répondait plus non plus ; même un arrêt normal demandé avec le bouton POWER est resté bloqué plus de 10 minutes, ce qui m'a finalement obligé à l'éteindre de force. Après redémarrage, SSH et DSM fonctionnent immédiatement et le RAID est toujours sain (4/4). Analyse des logs persistants du noyau Sur deux incidents différents, le noyau signale des kworker bloqués pendant plus de 120 secondes avec pratiquement la même pile : schedule_timeout wait_for_completion kthread_create_on_node create_worker manage_workers worker_threadPremier incident : apparition environ 36 minutes après le boot. Deuxième incident, après un autre redémarrage : apparition environ 2 h 06 après le boot. Dans le premier cas, le même worker reste bloqué et d'autres tâches finissent ensuite par se bloquer également (systemd-journal, autres kworker, puis plus tard dockerd et certaines opérations Btrfs). J'ai en parallèle recherché dans les logs : erreurs SATA / hard resetting link / failed command / I/O error : aucune trouvée ; erreurs ou dégradation RAID : aucune ; erreur/abort Btrfs : aucune ; OOM / manque de mémoire : aucune ; machine check / watchdog / soft-hard lockup : aucun ; erreurs réseau CRC/drop/timeout : compteurs à zéro. Les quatre disques continuent par ailleurs d'être reconnus normalement après reboot et le RAID reste 4/4. Un autre élément intéressant : pendant un des blocages, les logs DSM ont temporairement considéré les quatre disques comme "Abnormal", puis immédiatement "Normal", avec également des échecs temporaires de lecture de leurs numéros de série, alors que le RAID md restait bien à 4/4. Cela pourrait expliquer les voyants orange sans forcément indiquer une panne simultanée de plusieurs disques. À ce stade je n'ai trouvé aucune erreur SATA explicite permettant de l'étayer. Le point reproductible le plus net est actuellement ce blocage noyau/workqueue autour de : wait_for_completion -> kthread_create_on_node -> create_worker -> manage_workers Je ne sais pas si c'est la cause initiale ou la conséquence d'un autre problème noyau. Le SysRq fonctionne sur ce NAS. Au prochain blocage, si j'arrive encore à ouvrir une session SSH suffisamment tôt, je tenterai de récupérer immédiatement les tâches bloquées avec SysRq-w et dmesg avant tout redémarrage. Si quelqu'un connaît ce type de blocage kthread_create_on_node/create_worker sous DSM 7.2.2, ou a une idée de ce qui pourrait empêcher ainsi la progression/création des threads noyau, je suis preneur.

ok je fait ça et je reviens vers vous Merci guillaume

Bonjour à tous, Je sollicite votre aide pour un problème assez étrange sur mon Synology DS416play, qui fonctionnait normalement jusqu’à présent depuis plusieurs années. Je suis pas du tout un pro , j'ai demandé de l'aide à Chatgpt mais sans résultat Configuration : Synology DS416play DSM 7.2.2-72806 4 disques Seagate de 4 To RAID 5, capacité utile environ 10,9 To Volume Btrfs IP habituelle : 192.168.1.19 Début du problème : Le 2 octobre, je n’ai soudainement plus pu accéder à DSM. Sur la façade du NAS, les voyants des disques 3 et 4 étaient orange fixes, alors que les disques 1 et 2 étaient verts. Le NAS restait néanmoins parfaitement joignable sur le réseau : ping 192.168.1.19 : OK, 0 % de perte, <1 ms Synology Web Assistant trouvait le NAS à 192.168.1.19, avec le statut « Prêt » le port TCP 5000 répondait (Test-NetConnection ... -Port 5000 = True) idem pour le port 5001 En revanche, impossible d’obtenir DSM dans un navigateur. Un test avec : curl -v --max-time 30 http://192.168.1.19:5000/ donnait bien « Connected to 192.168.1.19 port 5000 », puis la requête GET était envoyée, mais le NAS ne renvoyait aucun octet, jusqu’au timeout : Operation timed out after 30015 milliseconds with 0 bytes received L’accès SMB (\\192.168.1.19) était également impossible. SSH n’était pas activé. Synology Assistant ne détectait plus le NAS, alors que le ping continuait à répondre. Pendant la nuit, j’ai reçu à plusieurs reprises des notifications indiquant que la connexion à mon DDNS —-synology.me était perdue puis parfois retrouvée. Redémarrages / manipulations : Après un premier arrêt forcé/redémarrage, les quatre voyants des disques sont redevenus verts, mais DSM restait inaccessible et les mêmes symptômes persistaient. J’ai également tenté le RESET Mode 1 (maintien du bouton RESET), mais aucun bip, malgré deux tentatives et vérification du bon bouton. Finalement, j’ai effectué un nouvel arrêt forcé, retiré les quatre disques, dépoussiéré soigneusement le NAS et remis les quatre disques dans leurs emplacements d’origine. Après cela, le NAS a redémarré normalement et DSM est redevenu immédiatement accessible. Contrôles effectués après ce redémarrage : Gestionnaire de stockage : Sain Groupe de stockage RAID 5 : Sain Volume : Sain Disques 1, 2, 3 et 4 : Sain Test SMART rapide effectué sur chacun des quatre disques : Sain pour les 4 Recherche dans les journaux sur disk, I/O et SATA : aucune erreur trouvée Pas de RAID dégradé ni de reconstruction en cours. Les seules anomalies visibles dans les journaux sont notamment les arrêts incorrects correspondant à mes arrêts forcés et quelques erreurs Failed to send email pendant les périodes où le NAS était bloqué. J’ai profité du retour à la normale pour effectuer/vérifier une sauvegarde complète des données importantes. Mais le problème vient de récidiver : Cette nuit (4 octobre), nouveau mail Synology : La connexion à -synology.me est perdue depuis 2026-10-04 01:30:08 +02:00 Cela survient donc après plusieurs heures de fonctionnement parfaitement normal. le NAS répond toujours parfaitement au ping (4/4, 0 % de perte, <1 ms), mais DSM est à nouveau totalement inaccessible. Sur la façade, STATUS reste vert et DISK 1 vert, tandis que DISK 2, DISK 3 et DISK 4 sont simultanément orange. La veille au soir, après redémarrage, ces quatre mêmes disques étaient tous déclarés « Sain » par DSM et leurs quatre tests SMART rapides étaient également « Sain ». Le RAID 5 et le volume étaient eux aussi « Sain ». Au vu du RAID et des quatre SMART sains, et surtout du fait que le problème avait disparu après retrait/remise en place des disques et dépoussiérage, je me demande maintenant si le problème pourrait venir du DS416play lui-même : alimentation, carte mère, contrôleur SATA/backplane, faux contact, problème thermique, etc. Le comportement qui m’étonne particulièrement est que la machine peut continuer à répondre parfaitement au ping, et même accepter une connexion TCP sur le port DSM, alors que DSM et les autres services ne répondent plus du tout. Avez-vous déjà rencontré ce type de panne sur un DS416play ? Pensez-vous plutôt à un problème d’alimentation, de carte mère/backplane, ou existe-t-il un problème connu sur cette génération qui pourrait provoquer ce type de blocage ? Y a-t-il des contrôles supplémentaires pertinents à effectuer maintenant que mes données sont sauvegardées ? Merci d’avance pour vos conseils.