Classement

Je n'en ai aucune idée. Je vois bien que vos 3 partitions sont bien en 7.9Go ce qui les prédisposent à passer sur cette capacité. Maintenant, pourquoi le grow ne s'est pas fait automatiquement, tout simplement je pense parce qu'aucun mécanisme n'est là pour le lancer. Si DSM fonctionne correctement sur la partition d'origine, inutile de l'agrandir. Dès lors, on peut effectivement supposer qu'une nouvelle version va détecter l'espace potentiellement dispo et déclencher l'augmentation du RAID1 sinon ça n'aurait pas de sens. Attendons la réponse du support pour mieux comprendre le mécanisme. De mon côté, je vais tenter (pas tout de suite) une opération qui consiste à sortir un des disques de mon 718 pour le formater et reconstruire le groupe. L'idée est de voir si DSM qui s'installe sur le disque partitionne en 7.9Go ou s'il conserve 2.2Go.

Voilà l'attendu une fois le NAS réinstallé :

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 @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

Voici un lien vers un des sujets qui traite de ce problème : https://www.nas-forum.com/forum/topic/77086-version-72-64570-disponible/page/2/#comment-1319491043

On n'est pas (encore) obligé de tout refaire. Comme je l'ai dit, il y a des solutions que tu trouveras dans la section firmware. Tu peux aussi voir avec l'assistance. Le problème d'espace va probablement être plus critique pour les prochaines versions car s'ils ont augmenté l'espace de la partition système c'est pour pouvoir à terme l'utiliser ce qui obligera tôt à tard à passer par la case réinstallation pour pouvoir continuer à utiliser son NAS dans le futur.

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

DSM est installé sur une partition dédiée non-visible dans DSM. Tu peux la voir avec la commande suivante : sudo df -h