Mic13710

Surtout nécessaire avec des disques neufs ! @Oliver-05 vous pouvez toujours faire une écriture de zéro. C'est d'ailleurs le seul test que je fais à titre perso et je le trouve suffisant. La marche à suivre ici : https://www.nas-forum.com/forum/topic/42318-pr/#comment-1319260020

Je ne vois pas où est le blème. Pour partager une photo ou un dossier photo, il faut d'abord avoir les droits sur synology photo. Vous sélectionnez l'élément à partager (un clic orange apparait sur l'élément sélectionné), en bas dans le panneau qui s'affiche, vous cliquez sur les 3 points à droite, Configurer les autorisations de dossier, vous choisissez la manière d'y accéder, avec ou sans mdp et vous copiez le lien à transmettre. Vous validez. Si vous utilisez un partage public avec mdp (ce que je fais avec les invités) vous n'avez même pas besoin du lien. Lorsque vous vous connectez à Synology Photo, la page d'accueil affiche tous les dossiers publics. En cliquant sur celui qui vous intéresse, vous donnez le mdp et l'élément s'affiche.

@CyberFr, nos amis belges, @.Shad. en tête, apprécieront ☹️

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

A partir du centre de paquets, bouton installation manuelle. Il faut le charger mais ne pas le lancer car il faut d'abord faire le paramétrage. Et il me semble par ailleurs que pour 7.2 il faille redémarrer le NAS pour que le spk soit acté.

@MixxEmpalaa Oulala, voila un bô déterrage type tractopelle et belle arrivée sur le forum ! Fallait le chercher loin celui là. J'espère que depuis 2012, bolcho à résolu son problème. @PiwiLAbruti Voila une excellente entrée dans le guiness des records

C'est en tout cas le nom que lui a donné Synology, mais ce n'est en aucun cas une invention Synology. C'est simplement un gestionnaire de RAID linux classique (mdadm) auquel on a ajouté une surcouche (lvm2) qui permet de gérer du multiraid.

Oui, mais, depuis le début on parle bien du NAS ? Alors pourquoi posez vous la question ? Le ou les clients n'ont rien à voir avec la saturation du dossier caché.

Commencer par poster dans la bonne section. Je déplace.

Déjà commencer par poster dans la bonne section. "Nos membres racontent" n'est pas là pour demander de l'aide. Je déplace. Que dit le centre des journaux pour avoir quelques premières informations ? Rien dans les logs ? Quelles sont les données smart étendu des disques ?

Tuto en ligne https://www.nas-forum.com/forum/topic/77094-tutodocker-linuxserverwireguard-wireguard-ui/

Vous avez la possibilité de sauvegarder les paramètres de deux manières : Dans DSM, Mise à jour et Restauration/Sauvegarde de configuration Dans les sauvegardes Hyperbackup où ils sont automatiquement sauvegardés

Impossible de conserver les données, ni le volume ni le groupe actuels. Il faut : Tout sauvegarder (Hyperbackup est le meilleur choix), Supprimer le ou les volume(s) Supprimer le groupe, Reconstruire le groupe en choisissant le RAID0, Créer un nouveau volume (ou plusieurs selon ce que vous aviez précédemment) Restaurer les sauvegardes.

Vu ce qui précède, il ne pouvait en être autrement. Et il fallait bien cela pour pouvoir bénéficier du btrfs (votre autre discussion)

Lorsque vous créez un lien partagé dans file station, vous accédez directement aux dossiers et/ou fichiers contenu dans le NAS. Pour ce qui est des photos (et en général tout ce qui est du multimedia) il faut passer par l'application dédiée qui pourra exploiter les miniatures qui ont été crées par le service d'indexation. En l’occurrence, il faut que vous créiez un lien de partage dans Synology Photos qui enverra vos parents dans l'application où ils pourront visionner les miniatures.

Pas vraiment puisque tu as remplacé ton 8To par un plus gros. Ma question concernait seulement le remplacement par un disque de même capacité. Mais je pense avoir compris le principe (voir mon message ci-dessus) A l'évidence, oui puisque si ton groupe avait été créé sous DSM7, tu aurais eu d'entrée une partition système en 8.5Go, tout comme sur ton 218+ ou sur mon 220+, et comme l'a confirmé @Einsteinium. C'est la configuration standard à partir de DSM7.

Bon, après analyse, il est clair que la partition système ne peut pas évoluer si le disque est de même capacité. En regardant simplement mon message ci-dessus : Mes deux NAS sont montés avec des 4To quasi identiques, et en tout cas de mêmes capacités. Les deux partitions de données font respectivement 3996Go sur le 718+ avec une partition système à 2550Mo, et 3990Go sur le 220+ avec une partition système à 8590Mo. On voit bien que la partition des données du 220+ à été amputée de 6Go au profit de la partition système. Il est bien évident qu'on ne peut pas associer une partition de données à un groupe existant s'il manque de l'espace. Et donc, la seule possibilité c'est de reconstruire une partition système de 2550Mo sur un disque de même taille que le ou les disques d'un groupe existant pour avoir une partition des données qui puisse être associée à celle du groupe. Ma conclusion c'est que si on associe un disque de même capacité sous DSM7, la partition système reste inchangée. Si par contre, on change ou on ajoute un disque plus gros à un groupe existant, alors la partition système de ce disque passe à 7.9Go. C'est très exactement ce qu'on voit sur le disque de 12To de @Jeff777 : La partition 5 est bien de la même taille que la partition 5 de son 8To ainsi que la partition 3 de mon 718+, les start/end sont simplement décalés des 6Go qui ont été rajoutés à la partition 1. Ainsi, cette partition 5 a pu être associées avec celle existante sur le 8To. La partition 6 est identique en taille à la partition 6 de son disque de 8To, elle aussi décalée des mêmes 6Go. Et quand le disque 8 sera remplacé par un 12To, la partition système devrait passer à 7.9Go et la nouvelle partition 7 qui sera créée à l'occasion occupera le restant de capacité non utilisée, je présume 4001-6 = 3995Go. Voili voulou.

Là, j'en suis moins sûr. Si le RAID est existant, je pense que la reconstruction d'un disque sorti du groupe, formaté et réinitialisé se fera sur les mêmes partitions que l'existant pour la raison que j'évoquais plus haut. Mais encore une fois, il faudrait le retour d'un membre du forum qui a fait l'opération pour le savoir. Le swap ne bouge pas. Il fait toujours 2147Mo. C'est la partition système qui est passée de 2550Mo à 8590Mo, soit une augmentation de 6040Mo.

@Einsteinium Tu confirmes que c'est bien une nouveauté DSM7. La taille de cette partition n'a en effet aucun lien avec la taille du disque. Il s'agit de la partition système allouée par Syno pour DSM. La partition donnée est construite avec ce qui reste après md0 et md1. Ma question était de savoir comment se comportait DSM lorsqu'on remplace ou ajoute un disque de même taille dans un groupe existant avec une md0 à 2.3Go. Je suppose qu'elle n'augmente pas, sinon ça risque de poser un problème pour construire la partition de donnée qui manquerait de Go pour être associée au RAID existant. Si quelqu'un a fait cette opération récemment, ce serait bien de vérifier par curiosité.

@Jeff777 s'il est plein, ça fait cher le 12To 😄

Ah oui, je n'avais pas regardé tes relevés en détail car je ne pensais pas que cette partition pouvait être modifiée lors de l'augmentation de groupe ! Au temps pour moi. Ca veut dire qu'il est très probable qu'elle augmentera lorsque tu changeras ton 8 par un 12. C'est une bonne chose. Reste à savoir si c'est DSM7 qui fait ça à chaque changement de disque quelle que soit sa taille ou seulement lors du remplacement ou ajout d'un disque par un plus gros. J'aurais tendance à penser que c'est uniquement lors d'un passage à une taille supérieure puisqu'il y a de la place pour décaler les partitions, ce qui n'est pas possible si le disque est remplacé par un autre de taille identique. Il serait intéressant d'avoir un retour de quelqu'un qui a remplacé (ou ajouté à un groupe existant) un disque de même taille sous DSM7.x pour en avoir le coeur net.

Attention aux crampes car il va falloir patienter un peu, le temps que les modos donnent leur feu vert ! J'ai donné mon avis. Si c'est OK pour d'autres, je publie.

Non. Elle restera telle qu'elle est sur le disque existant. En augmentant la taille du disque, tu n'augmente que la taille de la partition de données. Ou je dirais plutôt, tu crées une nouvelle partition de données qui vient s'ajouter aux existantes. Dans ton cas, je vois que tu as commencé par des 4To que tu as remplacé par des 8To. Au remplacement de ton 8To par un 12To, tu auras une nouvelle partition numéro 7 qui fera 4To. Si c'est les erreurs sur les md2 et md3, rien d'anormal. Tu fais bien. C'est DSM qui gère cette partition, mieux vaut ne pas y toucher.

A ma connaissance, la seule possibilité c'est de supprimer CloudStation, d'attendre que le fichier caché soit vidé (ça peut prendre un certain temps) et de le réinstaller pour qu'il reparte sur un dossier neuf. Cette opération ne détruit pas les données, seulement le dossier caché. Mais Cloudstation n'est plus dispo pour DSM6.x et le client Synology Drive n'est plus compatible avec Cloudstation depuis la version 3. Il vous faut basculer sur Synology Drive.

Ils sont en général peu bavards sur ce genre d'information technique qui est propre au fonctionnement de DSM. On peut ensuite se poser la question pour les évolutions futures de DSM sur des NAS avec seulement 2.3G. Parce que augmenter la partition alors qu'elle est contiguë avec le swap, va falloir repousser des blocs et ça, c'est pas une opération qui se fait en 10 minutes, ni 20. parted -list sur mon 718 : Number Start End Size File system Name Flags 1 1049kB 2551MB 2550MB ext4 raid 2 2551MB 4699MB 2147MB linux-swap(v1) raid 3 4832MB 4001GB 3996GB raid Pas de place entre la 1 et la 2. Par contre, y'a un peu d'espace entre la 2 et la 3, mais c'est dérisoire. parted --list sur mon 220 : Number Start End Size File system Name Flags 1 4194kB 8594MB 8590MB ext4 raid 2 8594MB 10.7GB 2147MB linux-swap(v1) raid 5 10.9GB 4001GB 3990GB raid On voit nettement l'augmentation de la partition 1. Il y a 4 Mo entre 1 et 2 et 200Mo entre 2 et 3.