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.

Modifié dimanche à 09:233 j par thetib

Bonjour,

Le schema ping OK + TCP 5000/5001 qui acceptent la connexion sans renvoyer d'octet, avec DSM et SMB morts, evoque un gel partiel: le noyau repond encore un peu, les services DSM non. Plusieurs LED disques orange alors que SMART/RAID etaient sains juste avant colle mieux avec alim, backplane ou controleur SATA qu'avec trois ou quatre disques qui tombent d'un coup.

Des que DSM est de nouveau accessible, activez SSH (Panneau de configuration > Terminal et SNMP). Au prochain blocage, avant l'arret force, tentez une connexion SSH et relevez `dmesg | tail -100` (erreurs SATA, reset, I/O). Des resets SATA a repetition font du chassis le suspect n°1. La sauvegarde que vous avez deja faite est le bon reflexe en attendant.

ok je fait ça et je reviens vers vous

Merci

guillaume

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_thread

Premier 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.