Toutes les discussions

En effet, mais c'était une autre solution au cas où vu qu'il n'arrivais pas à se mettre en mode 2. A l'avenir, je vais laisse le SSH activé au cas où

Là d'accord, le NAS est bien accessible et la réinstallation est en cours. C'est déjà mieux que de monter les disques sur un PC pour récupérer les données.

Justement, depuis find.synology.me je vois bien le NAS mais il était en "prêt" alors que je ne pouvais pas y accéder. La il était bien en mode réinstallation Je pensais qu'il faisait une réinstallation juste en le mettant en mode 2, mais en faite il fallait le lancer depuis find ou l'assistant (chez moi il ne fonctionne pas)

Le mode 2 c'est la réinstallation de DSM. Si vous n'arrivez pas à le joindre avec synology assistant ou find.synology.me, vous ne pouvez pas réinstaller DSM, ce qui signifie que vous pouvez attendre encore très longtemps sans que ça bouge 😉

Je pense que je vais faire comme ça. Je vais le laisser tourner au cas où il réussi à finaliser le mode 2, si c'est le cas tant mieux, sinon je ferais une récupération des données + formatage des disque pour ensuite les réinstaller pour repartir sur une base saine et ne surtout plus installer ce package ! ^^ Merci en tout cas pour votre aide

Oui, c'est possible en passant par une distribution linux type ubuntu. Voici la kb de synology à ce sujet : https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC

Même avec cette version le NAS n'est pas détecté. Est-il possible de brancher mes disques sur mon PC pour récupérer mes données, les formater et les remettre dans le NAS pour faire une réinstallation ? Il me semble qu'il était en SHR sur le NAS. Ah, le voyant status clignote en orange, je vais le laisse faire. Il doit être vraiment saturé s'il a pris en compte le mode 2 que maintenant

Effectivement, synology assistant peut avoir un problème de détection des nas plus anciens. Essayez avec une version plus ancienne, celle ci par exemple : https://web.archive.org/web/20230602141748/https://global.synologydownload.com/download/Utility/Assistant/5.2-5566/Windows/SynologyAssistantSetup-5.2-5566.exe P.S. : merci de ne pas citer inutilement et dans son intégralité la réponse précédente. J'ai supprimé les citations dans vos réponses.

Synology Assistant ne trouve rien et sur l'interface web il le trouve mais quand je clique sur connecter il indique que le site a mis trop de temps pour répondre. L'IP local du NAS répond

Ne brulez pas les étapes. Avant le test mémoire (qui ne peut se faire que si le nas est accessible) il y a la tentative d'arrêt par le bouton en façade. Je vois que vous êtes directement passé au mode 2. Normalement, vous devez joindre le NAS par find.synology.me. Si ça ne passe pas, essayez avec Synology Assistant (à télécharger sur le site synology) qui fonctionne souvent mieux que l'interface web.

Mode vieux con => ON Attention tout de même à ne pas réduire le problème à notre cas relativement favorable p1=8 Gio → md0=2,3 Gio. Le cas de @Mic13710 montre déjà qu'il existe des géométries historiques différentes, celui de @Pascalou59 montre qu'un système peut avoir été modifié hors des chemins prévus par Synology, et il doit exister quantité d'autres héritages issus des migrations, remplacements successifs et configurations RAID/SHR. Depuis notre canapé, le grow paraît presque trivial. Pour Synology, le vrai problème est probablement de déterminer avec une certitude suffisante quand il est sûr de le faire, et surtout quand il ne faut pas le faire. C'est finalement pour cela que la réponse à la question laissée sous le coude à @Pascalou59 m'intéresse davantage que nos spéculations sur le déclencheur : savoir si Synology travaille sur un mécanisme officiel de migration qualifiée de ces anciens md0, ou si le Mode 2 restera définitivement la seule voie supportée.

Bonjour, J'ai essayé de faire un test de mémoire, mais Synology Assistant ne vois pas mon NAS, pourtant il répond bien au ping. Je le vois bien dans https://finds.synology.com/ et est en statut prêt et lorsque je clique sur se connecter, il met qu'il a mis trop de temps à répondre. Le problème est survenue après avoir installé le paquet qBittorrent, qui je pense prend toute les ressources du NAS du coup je suis coincé J'ai également essayé de faire un reset Mode 2 : Débrancher le NAS Rebrancher le NAS Attendre qu'il démarre une fois démarré, appuyer sur le bouton reset jusqu'au premier bip Relacher le bouton reset Appuyer de nouveau sur le bouton reset jusqu'à entendre les 3 bip il y a bien les 3 bip, mais mon voyant status reste vert fixe alors que normalement il devrait être orange.

Ce serait pourtant si simple.... Sinon, en lignes de commande ça devrait pouvoir se faire. Je suis entièrement d'accord avec vous : ce n'est vraiment pas professionnel de la part de Synology non seulement de ne pas avertir clairement la cause d'un problème qui est connu seulement des initiés, mais aussi de ne pas proposer de solution simple autre que le mode 2 (dont on n'est pas sur quelle fonctionne) pour augmenter automatiquement une partition quand les critères pour le faire sont réunis. Cela fait tout de même plus de 2 ans que ce problème existe. Qu'il soit laissé en l'état de gestation depuis tant de temps, qu'il n'y ait aucun communication à ce sujet me surprend. Il serait quelque part logique d'aller au bout du processus, sinon pourquoi augmenter l'espace p1 si au final on ne peut pas l'exploiter sans passer par des opérations qui dépassent largement les connaissances de la grande majorité des usagers.

Bonjour à tous, Bonne nouvelle empirique pour la question de @Mic13710 : la mise à jour vers DSM 7.4.1 est passée chez moi ce midi (après libération d'espace via le venv Python + purge du snapshot au redémarrage). Résultat du mdadm --detail /dev/md0 après l'update : root@NasServeur723:~# cat /etc.defaults/VERSION majorversion="7" minorversion="4" major="7" minor="4" micro="1" root@NasServeur723:~# df -h / Filesystem Size Used Avail Use% Mounted on /dev/system-root 2.3G 1.6G 598M 74% / root@NasServeur723:~# sudo mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Fri Jan 3 10:25:56 2020 Raid Level : raid1 Array Size : 2490176 (2.37 GiB 2.55 GB) Used Dev Size : 2490176 (2.37 GiB 2.55 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Tue Aug 4 14:46:01 2026 Inchangé. Donc confirmé : une simple mise à jour DSM, même avec assez d'espace libéré pour passer, ne déclenche pas le grow automatique de md0 vers les 8 Gio pourtant déjà présents sur mes p1. Ça répond à votre interrogation — le Mode 2 reste bien le seul déclencheur connu à ce stade. Je garde le ticket ouvert et je poserai les deux questions de @RAHAN-31 (préservation du pool/volume en Mode 2, et existence d'un mécanisme de migration automatique prévu) si le technicien recontacte — sinon je les inclurai dans ma réponse de clôture du ticket. Mais je pense aussi à tous les autres utilisateurs qui tomberont sur ce même blocage sans avoir nos connaissances techniques ni la patience de creuser en SSH pendant deux jours. Pour un utilisateur lambda qui voit juste "espace disque insuffisant" sans comprendre pourquoi, avec un volume de données rempli à seulement 15-20%, c'est le genre de message qui peut mener directement à un ticket support, une réinstallation complète paniquée, voire un abandon de la mise à jour par peur de casser son NAS. et je ne vous parle pas de surveillance station aucune sauvegarde de configuration Ce qui manque cruellement, c'est ce que @RAHAN-31 évoquait plus haut : un message d'erreur DSM qui explique la vraie cause ("partition système ancienne, distincte de votre volume de données") plutôt que le message générique actuel qui laisse penser à un problème de stockage. DSM connaît pourtant parfaitement la taille de sa propre partition système — un diagnostic intégré à l'assistant de mise à jour, qui détecterait ce cas précis et proposerait directement les pistes de nettoyage (cache pip, modules Python manuels, etc.) ou orienterait vers le Mode 2 si nécessaire, éviterait à beaucoup de monde ces heures de recherche. Voila c'est résolu mais pas soigné complètement

Quelques pistes avant d'aller plus loin : https://kb.synology.com/fr-fr/DSM/tutorial/What_can_I_do_unresponsive_Synology_NAS

Bonjour, J'ai un DS214Play avec 2 disque de 4To chacun et suite à l'installation du paquet qBittorrent depuis le SynoCommunity, je n'ai plus accès à mon NAS depuis l'interface web de DSM. Je ne peux donc même pas désinstaller le paquet. SSH n'étant pas activé, je me retrouve bloqué avec un NAS inutilisable sur lequel je ne peux plus accéder ni faire quoi que ce soit. Pourriez-vous m'aider, si possible sans perdre les données mais la réinstallation de DSM (sans perdre les données des disques) me fait pas peur, je reconfigurerais de nouveau DSM ? Merci de votre aide

@Pascalou59 Une dernière réflexion issue de la réponse du support, que je te laisse simplement sous le coude si ton échange avec eux se poursuit. Finalement, au-delà de savoir si 7.4 déclenche ou non le passage de md0 de ~2,37 Gio à ~8 Gio, la question qui conditionne vraiment la stratégie à long terme serait de savoir si Synology prévoit un mécanisme officiel permettant un jour cette migration automatiquement, sans passer par un Mode 2. Car les conséquences sont complètement différentes : Mécanisme prévu ↓ rester en 2,37 Gio peut avoir du sens et attendre sa disponibilité Mécanisme non prévu ↓ autant envisager le Mode 2 au moment où les conditions sont les plus favorablesSi tu juges le moment opportun et que ton ticket est toujours ouvert, voilà la question que je poserais au support : Aucune urgence à la poser : je te la laisse simplement sous le coude si l'occasion se présente. 😉 Rassure-toi : dans la confrérie des « plus malins qui s'en sont mangé les doigts quelques années plus tard », tu es loin d'être seul. 😉 Et vu ce que je viens de découvrir sur mon propre NAS après des années d'évolution DSM… je vais soigneusement éviter de te jeter le premier secteur. 😇

Pas simple cette histoire de partition système. Attendons la réponse de @Pascalou59 pour en avoir le coeur net. Finalement, ça ne sera pas possible dans mon cas. Il faudrait pour ce faire que j'ai environ 5.6Go inutilisés en fin de disque. Or tout le disque est exploité. Si DSM crée un partition à 7.9Go, je ne pourrais pas reconstruire le groupe avec l'espace restant. La faute à une augmentation de l'espace de donnée que j'avais faite il y a bien longtemps pour exploiter tout le disque. A l'époque, il y avait quelques Go qui étaient non exploités après la création du groupe. J'ai joué au plus malin et du coup je n'ai plus cet espace qui avait probablement été laissé intentionnellement par Synology pour faire face à des modifications ultérieures. Il ne me reste plus qu'à tout reconstruire si je veux changer la taille de ma partition système.

@Mic13710 Tout à fait d'accord. C'est même désormais le test le plus intéressant et le moins intrusif : si @Pascalou59 récupère suffisamment d'espace après son reboot pour lancer normalement 7.4, un relevé df / proc/partitions / mdadm avant et après nous dira directement si l'upgrade constitue le fameux déclencheur. Le Mode 2 ne viendrait qu'ensuite si nécessaire... malheureusement 🤒, on vient de gagner au passage une migration Data mine de rien 🥳 Donc Wait and See la réponse du tech à notre question concernant la préservation du poo/volume Data et/ou celle de son upgrade...

Recourir à un reset mode 2 me semble un poil excessif. Il faudrait aussi savoir si une simple mise à jour de DSM vers une version ultérieure déclenche une augmentation automatique de la partition système de 2.3Go à 7.9Go si p1 est à 8Go.

Merci @Pascalou59 pour avoir complété la réponse du support, là c'est beaucoup plus clair ! Leur proposition confirme donc bien que, dans ton cas particulier : p1 physiques = 8 Gio md0 historique = ~2,37 Gio ↓ Mode 2 + réinstallation DSM ↓ partition système = 8 GoEt le fait qu'ils proposent ensuite de restaurer la configuration DSM laisse logiquement penser que le pool et le volume DATA existants sont conservés. Mais c'est justement le dernier point que j'aimerais verrouiller explicitement, car les conséquences ne sont évidemment pas les mêmes entre « réinstaller DSM » et « reconstruire le stockage ». Si ton ticket est toujours ouvert, pourrais-tu leur poser cette dernière question, idéalement en anglais pour éviter toute ambiguïté : Leur réponse permettrait de savoir précisément où se situe la frontière de l'opération. Ton retour concernant Surveillance Station illustre d'ailleurs parfaitement le problème suivant : préserver les DATA ne signifie pas nécessairement préserver l'ensemble de l'environnement applicatif. La configuration DSM, les configurations propres aux paquets et leurs interdépendances constituent également des actifs qu'il faut pouvoir restaurer. Merci encore de nous faire suivre les échanges avec le support.

On avait déjà eu le coup des périphériques USB non reconnus suite à une mise à jour de la branche 7.3, et qui empêchait surtout les communications avec les onduleurs. C'est surprenant que Synology ait refait la même bourde avec DSM 7.4… 🤦‍♂️

Bonjour a tous @RAHAN-31 Retour du support sur ta question (pas formulée exactement comme tu l'as demandée, mais ça y répond indirectement) : Donc a priori : pas de mécanisme de grow automatique de md0 malgré les p1 déjà à 8 Gio sur les disques. Seule la réinstallation complète (Mode 2) déclenche la réallocation. Ça confirme ta lecture initiale, malheureusement — la présence de l'espace physique ne suffit pas, il faut le déclencheur de réinstallation pour que DSM en profite. Autre découverte en creusant de mon côté, qui pourrait vous intéresser à tous les deux : en supprimant des paquets Python installés manuellement dans /usr/lib/python3.8/site-packages (190 Mo), l'espace ne s'est pas libéré immédiatement dans df -h. En creusant, j'ai trouvé un dossier /.syno_rbd/snapshot.dat de 126 Mo apparu au moment exact de la suppression — visiblement un mécanisme de snapshot/rollback de sécurité que DSM déclenche automatiquement lors de modifications importantes sur la partition système. L'espace ne sera vraisemblablement libéré qu'au prochain redémarrage propre. Je suis en pleine sauvegarde Active Backup (encore 4-5h), donc je testerai le redémarrage une fois terminée et je confirmerai si ça résout l'écart. Aute point important surveillance station n'a pas de sauvegarde meme les réglages pour toutes les caméras !! je trouve vraiment que synology n'apporte pas de solution et c'est vraiment abuser , a moins de tout refaire il y a beaucoup de temps a passer meme avec toutes les sauvegardes diverses A suivre

Bonjour, Existe t'il une comande pour reconnecter un disque dur USB externe, qui a été antérieurement ejecté, sans être obligé de le débrancher et rebrancher physiquement sur le NAS ?

Je privilégierais le VPN box car si le NAS est en rade, le réseau reste joignable et il sera possible de tenter de remettre le NAS en service à distance. Vous pouvez aussi garder en réserve celui du NAS, openVPN de préférence. Après tout dépend de la box. Si c'est une freebox (je ne sais pas pour les autres), vous avez wireguard (dont tailscale est un dérivé) qui est le VPN le plus rapide.