Pascalou59

Bonjour @Lelolo @RAHAN-31 Après beaucoup de cafouillages avec le support qui ne m'a meme pas proposé la béta , je me suis résigné a l'installer cette VM 2.8.0-12322 (bêta) et ça refonctionne , j'ai du repartir de 0 refaire une Win10 ....DSM 4.1 apporte aussi son lot de problème dans la migration

Bonjour @RAHAN-31 Le support m' a demandé l'accés ce matin a suivre

Bonjour @Lelolo oups une version béta !!!!! le passage a DSM 4.1 a été très laborieux , je pense que je vais attendre la version finale ou le support en retour

Bonjour à tous, Je rencontre un problème sur mon DS723+ depuis le passage à DSM 7.4.1 (build 90080). Le paquet Virtual Machine Manager (Virtualization 2.7.0-12229) ne fonctionne plus correctement, et ma VM Windows 10 a perdu toute connectivité réseau. Symptômes : Le commutateur virtuel "Default VM Network" affiche Avertissement (Pas d'interfaces réseau), alors que LAN2 (mon interface active, 1000 Mbps) est bien détectée mais reste sur Prise en charge : Non. Le pool de stockage VM affiche le statut "Sain" mais Capacité : "-" et 0 octet alloué, alors que le volume sous-jacent est parfaitement sain avec plusieurs To disponibles. Ce que j'ai déjà testé (sans succès) : Suppression et recréation manuelle du commutateur virtuel en sélectionnant explicitement LAN2 → même résultat. Désinstallation complète du paquet (confirmé aucun résidu dans /var/packages/Virtualization), reboot complet du NAS, puis réinstallation propre → les binaires (libvirtd, virtqemud, virtnetworkd, qemu-system-x86_64...) sont bien présents cette fois. sudo virsh net-list --all → le réseau default existe mais reste inactif. sudo virsh net-start default → erreur : error: Failed to start network default error: internal error: Failed to initialize a valid firewall backendVérification des binaires firewall disponibles : iptables : présent et fonctionnel ip6tables : présent nft (nftables) : absent ebtables : totalement absent du système, confirmé via find / -iname "ebtables*" Ajout de firewall_backend = "iptables" dans /etc/libvirt/virtnetworkd.conf + redémarrage du paquet → erreur identique, persiste. sudo virsh pool-list --all → aucun pool de stockage créé, même pas inactif — même symptôme que le réseau. Côté support Synology : J'ai ouvert un ticket. Leur première réponse évoque une possible incompatibilité de version (branche 2.8.0 nécessaire pour DSM 7.4), mais mon Centre de paquets ne propose aucune mise à jour — version installée et version en ligne affichent toutes deux 2.7.0-12229. J'ai transmis un journal de diagnostic (debug.dat), en attente de leur retour. Question pour la communauté : Est-ce que d'autres utilisateurs de DS7xx/DS9xx+ ont constaté ce même souci après le passage à DSM 7.4.1 ? Merci d'avance pour vos retours.

Hello @RAHAN-31 et @Mic13710 Après le passage en de DSM en 4.1 ma VM Win10 ne fonctionne plus , plus de passerelle , le paquet Virtual Machine Manager a du etre réparé mais rien a faire la passerelle par Defaut network ne fait plus le lien , j'ai tout supprimé meme les vm et Virtual Manager , fait un redemarrage propre du NAS ......je vais devoir ouvrir encore un ticket Voici le retour du support c'est la confirmation formelle qu'on attendait — le point important est bien confirmé noir sur blanc : "A Mode 2 reset does not affect the existing storage pool, volume, or user data." Le pool, le volume et les données utilisateur sont bien préservés, seule la config système part. Ce qui est effacé (rien de nouveau par rapport à ce qu'on savait déjà) : Toutes les configs système (réseau, tâches planifiées, utilisateurs, paquets) Le mot de passe admin Le coffre de clés de chiffrement (si vous chiffrez des dossiers partagés — à vérifier si c'est votre cas) DSM entier à réinstaller depuis zéro Ce que ça implique concrètement pour vous si vous décidez de le faire un jour : Immich, Container Manager, MariaDB, Surveillance Station, etc. → tous à réinstaller et reconfigurer manuellement Votre export .dss habituel → utile pour restaurer une partie de la config plus vite

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

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

Je viens de jeter un oeil sur mon 718 qui est en DSM 7.3-81180 j' y vais très tres rarement c'est un disque de 8 To , la partition est déja a 8 go , je vais le mettre en DSM 4.1 Edit je viens de mettre le 718 en 4.1 aucun problème c' était une installation neuve a l'origine de 2025 , donc la partition était déja prête pour le 8 Go . On traine bien bien des casseroles avec les versions plus anciennes sudo mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Sun Jan 19 13:01:53 2025 Raid Level : raid1 Array Size : 8388544 (8.00 GiB 8.59 GB) Used Dev Size : 8388544 (8.00 GiB 8.59 GB)

j'ai aussi mon 718 qui me sert de backup ,je n'ai qu'un seul disque dessus de 8 to ! ? ça vaux le coup de tenter ??

bonjour @RAHAN-31 Effectivement, en regardant mes propres relevés que j'ai postés plus haut : mes deux IronWolf ont bien chacun une p1 de 8388608 blocs = 8 GiB, exactement comme tes disques neufs. Donc le nouveau partitionnement physique est déjà là chez moi aussi, sans que md0 (toujours à 2,37 GiB, créé le 03/01/2020 d'après mdadm --detail) en profite. De mon côté, en parallèle, j'ai identifié et corrigé une partie du problème : un environnement Python installé manuellement (pip install en root pour un script maison) occupait ~190 Mo dans /usr/lib/python3.8/site-packages sur la partition système. Je l'ai déplacé vers un environnement virtuel sur mon volume de données, ce qui devrait libérer assez de marge pour tenter la mise à jour même sans agrandir md0 — mais ta piste sur le redimensionnement reste bien plus intéressante à long terme, vu qu'on va sinon rejouer ce même scénario à chaque mise à jour majeure future. J' ai poser ta question exactement comme tu l'as formulée Espace récupéré jusqu'ici : 454 Mo disponibles (cache pip vidé), en attente de nettoyer /usr/lib/python3.8/site-packages (~190 Mo de plus) une fois le feu vert du technicien reçu Script énergie : migré et fonctionnel sur le venv /volume1/scripts/energie_venv, tâche planifiée mise à jour En cours : session support avec le technicien Taiwan ce matin À suivre avec le technicien ! j'attend son feu vert pour la suite

Bonjour @RAHAN-31 Voici les différentes info que j'ai récupéré et bonne nouvelle j'ai recu ce matin la demande d'accés du support et la notification de connexion de Taiwan est en cours root@NasServeur723:~# du -x --max-depth=1 -h / 4.0K /initrd 2.5M /etc.defaults 42M /.syno 3.0M /.log.junior 48K /.old_patch_info 11M /var.defaults 16K /opt 47M /etc 4.0K /lost+found 4.0K /mnt 18M /.syno_rbd 1.5G /usr 221M /var 4.0K /.system_info 60M /root 4.0K /volumeUSB1 1.9G / sudo cat /proc/partitions major minor #blocks name 1 0 655360 ram0 1 1 655360 ram1 1 2 655360 ram2 1 3 655360 ram3 1 4 655360 ram4 1 5 655360 ram5 1 6 655360 ram6 1 7 655360 ram7 1 8 655360 ram8 1 9 655360 ram9 1 10 655360 ram10 1 11 655360 ram11 1 12 655360 ram12 1 13 655360 ram13 1 14 655360 ram14 1 15 655360 ram15 259 0 488386584 nvme0n1 259 1 488383008 nvme0n1p1 259 2 488386584 nvme1n1 259 3 488383008 nvme1n1p1 8 0 7814026584 sata1 8 1 8388608 sata1p1 8 2 2097152 sata1p2 8 3 7803303248 sata1p3 8 16 7814026584 sata2 8 17 8388608 sata2p1 8 18 2097152 sata2p2 8 19 7803303248 sata2p3 9 0 2490176 md0 250 0 2490176 synorbd_system 252 0 17472 synofsbd_vm_system 7 0 32768 loop0 249 0 9852928 zram0 249 1 9852928 zram1 9 1 2097088 md1 8 32 976762584 usb1 8 33 976759904 usb1p1 135 240 122880 synoboot 135 241 32768 synoboot1 135 242 86016 synoboot2 9 3 488381952 md3 9 2 7803302208 md2 248 0 12288 dm-0 248 1 487587840 dm-1 248 2 7803302208 dm-2 250 1 7803302208 synorbd_1 252 1 60480 synofsbd_vm_1 sudo cat /proc/mdstat Personalities : [raid1] md2 : active raid1 sata1p3[2] sata2p3[3] 7803302208 blocks super 1.2 [2/2] [UU] md3 : active raid1 nvme0n1p1[0] nvme1n1p1[1] 488381952 blocks super 1.2 [2/2] [UU] md1 : active raid1 sata1p2[0] sata2p2[1] 2097088 blocks [2/2] [UU] md0 : active raid1 sata1p1[0] sata2p1[1] 2490176 blocks [2/2] [UU] unused devices: <none> 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 : Mon Aug 3 08:31:23 2026 State : clean Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 UUID : 2df02df8:2494f7f0:3017a5a8:c86610be Events : 0.1239 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sata1p1 1 8 17 1 active sync /dev/sata2p1

Bonjour a tous ! Je réveille le sujet car je suis en version DSM 7.3.2-86009 Update 4 en raid avec 8 To , DS723+ et la mise a jour ne veux pas se faire pour DSM 4 . Avez vous du réinstallé DSM , c'est vraiment la dernière chose que je voudrais faire pas envie de faire une résinstall complète , il y les docker aussi pas de sauvegarde , j'ai Office qui rempli automatiquement par du code python un tableau excel qui enregistre toute la consommation electrique , surveillance station , avec Home assistant . contrôle du volumes des conteneurs Immich (server, postgres) susceptibles d'écrire massivement — tous les montages pointent correctement vers /volume1/docker/Immich/..., rien n'écrit sur la partition système. Avez vous solutionné le problème en supprimant certain paquet , j'ai fait un ticket au support , Filesystem Size Used Avail Use% Mounted on /dev/system-root 2.3G 1.9G 359M 84% /

Merci @Mic13710 Je n'avais vu ce post a ce sujet merci !!! malgré la recherche et le sujet date de 2023 .sur 6 pages . Grrrrr j'ai vraiment pas envie de faire une résinstall complète , il y les docker aussi pas de sauvegarde , j'ai Office qui rempli automatiquement par du code python un tableau qui enregistre toute la consommation electrique avec Home assistant .... je vous donnerai la suite que le support donnera je croise les doigts

Je vais attendre la réponse du support , il y a le robot qui m' a dit de voir coté immich mais apres controle Vérification des points de montage Container Manager/Docker : j'ai contrôlé les volumes des conteneurs Immich (server, postgres) susceptibles d'écrire massivement — tous les montages pointent correctement vers /volume1/docker/Immich/..., rien n'écrit sur la partition système.

Bonjour @Mic13710 Ha c'est vraiment pas sympa de la part de synology devoir tout réinstallé la totalité de DSM qui tourne comme une horloge . J'ai fait un ticket d'assistance devoir tout refaire ca me soule énormément

Bonjour !! voici le retour mais claude m'a dit que la partition de 2,3Go est insuffisante root@NasServeur723:~# sudo df -h Filesystem Size Used Avail Use% Mounted on /dev/system-root 2.3G 1.9G 359M 84% / devtmpfs 16G 0 16G 0% /dev tmpfs 16G 244K 16G 1% /dev/shm tmpfs 16G 36M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup tmpfs 16G 30M 16G 1% /tmp tmpfs 3.2G 0 3.2G 0% /run/user/196791 /dev/loop0 27M 767K 24M 4% /tmp/SynologyAuthService /dev/synorbd_1 7.0T 1.3T 5.8T 18% /volume1 /dev/usb1p1 916G 118G 799G 13% /volumeUSB1/usbshare tmpfs 1.0T 0 1.0T 0% /dev/virtualization /dev/synorbd_1 7.0T 1.3T 5.8T 18% /volume1/@appdata/ContainerManager/all_shares/ActiveBackupforBusiness /dev/synorbd_1 7.0T 1.3T 5.8T 18% /volume1/@appdata/ContainerManager/all_shares/activity /dev/synorbd_1 7.0T 1.3T 5.8T 18% /volume1/@appdata/ContainerManager/all_shares/Album Photo Prive etc etc

Bonjour J' ai un stockage de 8 To le volume n'est a rempli qu' a 17% et impossible d'installer DSM 7.4 car j'ai le message "votre espace disque est insuffisant" sur mon DS723+ alors que l'espace libre est largement dispo J'ai 2 ssd en cache et 32 Go de mémoire , je ne vois pas pourquoi cette mise a jour ne passe pas . J'ai demandé a mon Claude il me dit que root@NasServeur723:~# du -x --max-depth=1 -h / 2>&1 | sort -rh 1.9G / 1.5G et sa réponse /usr à lui seul fait 1.5G sur les 1.9G utilisés — Sur un DS723+ sain, /usr dépasse rarement 700-900 Mo. À 1.5G, les causes les plus courantes sont : Claude Pas de dossier isolé énorme — c'est réparti entre les libs (539M), les paquets tiers (/usr/local, 400M) et les composants Synology (/usr/syno, 263M). Ça correspond simplement à un NAS avec beaucoup de paquets installés , j'ai immich en docker c'est assez lourd peut etre une cause ? Je n'ai pas de serveur Mail Plus Claude Non, ce n'est pas ça — et vous avez même la preuve dans votre propre df -h plus haut : tout ce qui touche Container Manager/Docker (/volume1/@appdata/ContainerManager/all_shares/...) est monté sur /dev/synorbd_1, c'est-à-dire volume1, pas la partition système. Synology stocke toujours les images Docker, les volumes de conteneurs et donc les données Immich (photos, base de données, modèles ML) sur le volume de données, jamais sur les 2.3G de la partition système. Immich peut être aussi lourd qu'il veut sur vos 7 To (dont seulement 18% utilisés, donc large marge là), ça n'a aucun impact sur le blocage de mise à jour DSM. Le vrai coupable, on l'a déjà identifié : c'est l'accumulation normale de composants système (/usr/lib, /usr/local, /usr/syno — MariaDB, CUPS, tous les hooks DSM) qui remplit progressivement les 2.3G au fil des années et des mises à jour successives. Pas un gros fichier isolé qu'on peut supprimer, juste un totale qui dépasse la marge nécessaire pour l'installateur. Claude Les deux seules options réelles restent : la migration install, ou attendre/contacter le support Synology pour voir s'ils ont un outil de nettoyage interne plus chirurgical que ce qu'on peut faire en SSH. Avez vous une idée Merçi

Bonjour @psmpa6816 J'ai aussi eu ce petit problème .....et c'est bien votre navigateur avec son plugin , les traductions sont meme un peu fantaisistes

C'est un avertissement a ceux qui veulent rajouter de la RAM , mais hélas c'est le porte monnaie qui va trinquer a notre place . Cette IA n'est pas prête de s’arrêter le patron du bar nous attend

Bonjour Le prix de la mémoire a flambé depuis le début de l'année. En février, j'avais acheté 32 GB pour 76 €, et maintenant, 11 mois plus tard, le prix est de 206 €, une augmentation de 200 % . La mémoire va bientôt coûter plus cher que la machine elle-même.

530€ ca devient cher pour un produit de ce type

Je vous fais le retour du support de Synology Il s'agit du comportement attendu dans ces circonstances, mais indésirable dans le sens ou la disparition ne fait pas suite à une action de votre part, mais à la mise à jour DSM 7.3 : le paquet Active Backup for Business n'est pour le moment pas disponible dans votre Centre de Paquets, car nous procédons à un déploiement progressif. Il est donc nécessaire de télécharger le paquet directement depuis le Centre de Téléchargement, j'inclus les deux liens au cas où vous en ayez besoin pour les deux : https://www.synology.com/support/download/DS718+?version=7.3#packages https://www.synology.com/support/download/DS723+?version=7.3#packages

Bonjour @Lelolo C'était juste pour signaler le lot de problème avec cette 7.3 sur les Nas avant la serie 25 . J'ai posé la question dans la section Active Backup Business

Bonjour Je n'arrive plus a connecter mon 2 eme Nas le 718+ qui sert de backup dans le meme réseau avec Active backup avec la version DSM 7.3 sur les 2 Nas . Je rentre l' IP locale uniquement . J 'ai le message suivant Vérifier votre connexion internet ...etc . , la connexion fonctionne parfaitement bien j'accède aux 2 nas par leur IP , je suspecte beaucoup le passage a la version 7.3 de DSM , j'ai désinstallé et réinstallé Active Backup sur les 2 NAS dans les 2 sens c'est pareil , mon reseau fonctionne très bien et avant cette mise a jour tout allait bien , j'avais eu le message de paquet obsolete Active backup qui ont été mis a jour avec ce passage a DSM 7.3 Petite précision avec hyper Backup la connexion fonctionne très bien donc les nas se voient Cette mise a jour 7.3 bof bof , les problèmes sont la

Bonjour Je n'arrive plus a connecter mon 2 eme Nas qui sert de backup dans le meme réseau avec Active backup avec la version DSM 7.3 sur les 2 Nas . Je rentre l' IP locale uniquement et j 'ai le message suivant Vérifier votre connexion internet ...etc . , la connexion fonctionne parfaitement bien j'accède aux 2 nas par leur IP , je suspecte beaucoup le passage a la version 7.3 de DSM , j'ai désinstallé et réinstallé Active Backup sur les 2 NAS dans les 2 sens c'est pareil , mon reseau fonctionne très bien et avant cette mise a jour tout allait bien , j'avais eu le message de paquet obsolete Active backup qui ont été mis a jour avec ce passage a DSM 7.3 Petite précision avec hyper Backup la connexion fonctionne très bien Une idée ??