AlPri

Bon, je vois que cela n'inspire pas. Je viens d'avoir la réponse, il suffit de passer en DSM7.1.

Bonjour Firlin, Merci ! Pour éviter la commande mdadm, j'ai pris une autre option : mauvaise idée apparemment car j'ai cassé les deux disques. Voici la manip pour éviter à d'autre de faire : - J'ai éteint diskstation et retiré le disque 2 - Je l'ai ensuite connecté en eSata externe et rallumé. - Il s'est mis en sdc, et il était bien failed sur l'IHM - J'ai lancé la commande badblocks sur sdc avec le plannificateur - J'ai dû ajouté le f de forçage, et j'ai pu voir les 2 premières lignes du log, - Puis j'ai perdu ssh et l'IHM haut de quelque minutes j'ai pu éteindre proprement au bouton - Au redémarrage, j'ai eu pour chaque disque séparément l'écran de réinstallation ! Je suis donc reparti de mon ancien disque + quelques restaurations et tout est à nouveau en route. Ensuite, j'ai lancé le seatools sur les deux 16T et aucune anomalie. Par contre, je soupçonne maintenant un pb de filesystem sur les disques d'origine. En effet, lors de la récupération du disque d'origine, il avait créé un nouveau Dossier partagé qui doublonnait un d'origine avec un "_1" au bout du nom du dossier, aussi tous les fichiers se trouvant dans dans la corbeille d'un seul dossier partagé (pas le même) ont un sens interdit comme ceux-ci : Lorsque je vide la corbeille, la plupart des fichiers sont bien supprimés mais un certain nombre ne s'effacent pas. Lorsque je tente de supprimer en SSH root, j'ai l'erreur suivante : rm: cannot remove 'ES/ImportExport/Data/@eaDir/expFiles_91': Input/output error Donc, le e2fsck semble indispensable. Je viens de trouver un post sur @DavFromRouen qui a eu en 2021 exactement le même pb que moi je vais mis accrocher si besoin : Merci à tous !

Bon après quelques jours pour réaliser une sauvegarde complémentaire de sécurité, me voilà prêt à lancer badblocks. Pour passer un disque en fail, dans le tuto de @firlin ici, il est nécessaire de lancer la série de commandes "mdadm /dev/md0 --fail /dev/sdx1" sur les partitions 0, 1 et 2. Ce qui m'intrigue c'est que j'ai 6 partitions (/dev/md0 à /dev/md5). Faut-il passer les 3 commandes sur les 6 partitions ? Voici les sdb : Et les md supplémentaires : Merci d'avance, Bonne soirée

Bonjour, Est-il possible de sauvegarder toutes les tâches de Hyper Backup en cas de reconstruction d'un Nas ? Pour moi, les seules applications qui apparaissent dans une tâche ne contiennent pas Hyper Backup. Si impossible avec une tâche Hyper Backup, y aura-t-il un moyen en ligne de commande ? En effet, j'ai pas mal de tâches avec plusieurs destinations et la seule méthode que j'ai trouvé c'est de faire des copies d'écran de chaque onglet de toutes les tâches, pour pouvoir les recréer à la main. Un import/export serait le bien venu. Merci d'avance !

Merci Niklos0 ! Est-ce que ces outils sont dispo sur synology (pas trouvé dans les packages), ou dois-je sortir les disques pour les analyser ? Merci Lelolo ! Comment fait-on pour ouvrir un ticket ?

Bon, les tests complets des deux disques ne révèlent aucune anomalie. Les deux disques sont taggés sain. Si je relance l'extension du volume, même résultat passage en avertissement, et un redémarrage avec vérification de fichiers remets tout en sain. Donc impossible d'étendre pour utiliser tout l'espace. Quelqu'un aurait-il une idée ?

Merci Firlin pour ce retour. Oui, c'est tout à fait exact, impossible d'étendre. J'ai lancé les smart tests après avoir installés les 2 disques et après avoir rencontrés ces pb car j'ai fait la même conclusion : pb disques. Mais avec ces tailles de disques, c'est très long, donc c'est toujours en cours. Je vais donc attendre la fin et revenir dans j'espère moins de 24h. Pour info, j'ai réussi à trouver des logs système, mais cela ne semble pas aider : 2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: volume_lib.cpp:2013 Fail to set auto fsck file: [/dev/vg1000/lv] 2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: VolumeManager.cpp:2001 Failed to ExpandVolumeUnalloc due to filesystem issue 2022-11-27T14:41:12+01:00 DiskStation synoscgi_SYNO.Storage.CGI.Volume_1_expand_unallocated[13468]: VolumeManagerApi.cpp:623 Fail to expand volume unalloc

Bonjour, Je viens de changer les deux disques de mon DS216+II (2x8To par 2x16To) avec DSM6.1. Habituellement, à l'installation du second disque je pouvais demander une extension en même temps et c'était terminé. En DSM 6.1, impossible de retrouver ou réaliser l'extension, donc je suis passé en DSM 6.2, et j'y suis toujours en rédigeant ce post. Maintenant, j'ai bien le bouton étendre : Mais lorsque je l'utilise, il génère une erreur qui met mon volume en Avertissement : Après avoir fait Ok, voici l'état du volume : Je lance donc la procédure de vérification sachant que le journal ne contient aucune erreur, et tout redevient normal : Si je relance l'action Etendre, de nouveau Avertissement, et un check redevient normal. J'ai fait cette manip 5 fois sans succès (en changement des détails sans succès). Voici mon Groupe de stockage où l'on voit que je pourrais étendre : J'ai des Smart Test complet en cours, mais je n'ai pas beaucoup d'espoir. Existerait-il des journaux plus détaillés qui permettrait de comprendre pourquoi j'ai un passage en Avertissement au moment de l'extension ? Je ne pense pas qu'un passage en DSM7 ai une influence. Est-ce que quelqu'un aurait une idée ? Merci d'avance. Bien à vous, Alex

Bonjour, Suite à de nombreux problèmes avec la 4.2, j'ai tenté un double reset. Tout s'est bien passé, et j'attends de voir si le système est plus stable. Cependant, je rencontre un problème lors de la reconfiguration de Time Backup. Lorsqu'il a redémarré, il a créé un nouveau répertoire horaire complet à la suite des existants mais il est tout neuf (sans hard link), donc une duplication complète. Et le second problème, c'est qu'il n'a pas reconstruit sa base de gestion rendant impossible les opérations suivantes : - la navigation dans Time Backup avec les anciennes sauvegardes n'est pas possible, - mais le plus gênant c'est que Smart Cycle ne fonctionne plus sur les anciens répertoires (actif depuis octobre 2012 donc il y a du monde à gérer) Quelqu'un saurait-il s'il est possible de reconstruire la base Time Backup à partir des dossiers existants ? Merci d'avance,

Bonjour, Depuis la mise à jour de la 4.2 en prod fin mars, c'est devenu extrêmement pénible d'utiliser mes NAS. Je dois rebooter tous les 2 ou 3 jours pour les raisons suivantes : - Fort ralentissement dans l'explorateur windows, - perte des contenus des lecteurs partagés (seulement sous windows, heureusement) - Lock de fichiers impossibles à relacher même en éteignant toutes les machines connectées En prod ca devient délire ! Un reboot résoud tous les pb d'un coup. Un passage en 3211 n'a rien résolu. J'utilise la 4.1 depuis le début, et je n'avais qu'un seul pb, c'est que sous certains logiciel (coreldraw par exemple) les dossiers apparaissent aléatoirement, et la nouvelle version de Samba en 4.2 a bien résolu le pb. Mais, les pb ci-dessus ne valent pas la peine d'avoir cette évolution. Donc, oui, si un retour arrière était possible même en reformattant tout, je suis preneur car là ca fait plus d'un mois que c'est une vraie galère pour les utilisateurs ! Je peux aussi apporter des éléments complémentaires pour tenter de résoudre, mais ca devient urgent. Merci d'avance,

Le NAS ne s'éteint pas; il se met en sécurité, et là le courant peut être coupé. Et effectivement, lorsque le NAS passe en mode sécurité, c'est-à-dire qu'il n'est plus accessible, et si l'onduleur n'est pas encore arrêté car il lui reste des batteries, je n'ai pas vérifié si à cet instant le courant revient, le NAS repasse hors sécurité pour redevenir accessible. C'est surement la raison pour laquelle il y a l'option d'extinction de l'onduleur (c'est donc le NAS qui éteint l'onduleur) dès que le NAS est en sécurité. Le hasard pour que le courant revienne entre le moment où le NAS est en sécurité, et le moment où le NAS demande l'extinction de l'onduleur, c'est-à-dire quelques secondes, il sera très rare et même exceptionnel que le NAS ne redémarre pas. Ceci dit il faudrait tout de même vérifier si le NAS ne saurait pas ressortir du mode sécurité à la remise sous tension. Pour l'avoir vu fonctionné, c'est quand même très abouti le truc, et il ne m'étonnerait pas que cela fonctionne très bien.

Je dispose d'un onduleur EATON 650 USB lequel communique directement au DS le temps restant, et le DS se coupe dès que les batteries sont presque épuisées et le DS peut commander l'extinction finale de l'onduleur dès qu'il est prêt. Lors du retour de l'alimentation, l'onduleur se rallume, ainsi que le DS automatiquement. Le tout se fait suivant différents paramétrages mais c'est très simple avec le DSM4.1.

Ca semble très alléchant et facile, mais impossible de confirmer la source après quelques recherches sur le net. J'ai du mal à comprendre pourquoi passer par le gestionnaire de paquet du DS pour installer un autre gestionnaire de paquets qui lui même doit être utilisé via ssh. D'autre part, il ne sert à rien d'installer ipkg tant que les binaires des utilitaires comme lftp ou autre ne sont pas dispos. Enfin, il me semblerait plus utile de packager directement les utilitaires tels que lftp et autres pour le gestionnaire de paquets standards que de le faire pour ipkg. En conclusion, je n'installerai pas cet ipkg !

Bon, devant toutes les questions, j'ai donc testé pour être sur. Mon paramétrage : - Serveur (où est connecté l'UPS) : * Délai avant passage en safe mode : Jusqu'à ce que la batterie faiblisse * Arrêt de l'onduleur : Oui - Esclave : Délai avant Safe Mode : Comme le serveur. J'ai déconnecté et attendu l'arrêt complet (du train)... Quelques secondes avant l'arrêt, j'ai vu les led Status s'éteindre et plus aucun accès possible, puis l'UPS s'est éteint sur ordre du Syno... jusque là tout va bien. Rebranchement de l'UPS, tout se remet en marche, et lecture des 2 journaux identiques à quelques secondes près : - 21:30 Server on battery - 21:39 Server going on Safe Mode - Apple File service was stopped - Windows file service was stopped - 21:42 System started to boot up (je viens de reconnecter l'UPS) - Local UPS was plugged in - Windows file service was started - Apple File service was started Et tout roule sur les deux synos... Pfiou... j'aime pas trop jouer en prod ! Bonne soirée!

Bonjour, je dispose donc de deux NAS DS213+ sur un seul onduleur. J'ai l'onduleur connecté sur l'un des deux NAS qui le reconnait parfaitement. Comment demander au second NAS (non relier à l'onduleur) de s'éteindre aussi sur détection d'arrêt de courant ? Je suppose que ce genre de config doit être courante.