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.

Et moi de même, mais pour ce faire je dois lire la doc. @Diaoul : je suppose que c'est toi qui maintient le spksrc, non ? Si oui, tu parlais d'un tuto à compléter, avant je voudrais le lire, mais à quel tuto fais-tu référence, est-ce le readme.rst sur https://github.com/SynoCommunity/spksrc ou y a-t-il quelque chose de plus complet ? J'ai parcouru rapidement la doc de création des spk et autre par Synology, mais cela ne parle pas du tout du spksrc.

C'est exact. Par contre, j'ai bien retenté la cross-compil sur ma virtualBox mais je me suis battu quelques heures sur comment installer le Guest applications, sans succès ! L'objectif était de pouvoir utiliser le partage de clipboard pour pouvoir copier-coller les milliers! de paramètres des aides en ligne ou de fichier windows vers la virtualBox. Pour le moment, je vais devoir tout mettre en stanby, mais j'aimerais bien finaliser cette Virtual pour attaquer sérieusement les cross-compil. Je poste dès que j'avance...

Je ne comprend pas le lien que tu fais entre ssh et wget. Est-ce que wget peut être utilisé avec ssh ? Autant je vois comment faire du http ou ftp avec wget, autant avec ssh je ne vois pas. Ne penserais-tu pas encore à rsync ?

Bon, je vois que vous êtes lancé, je vais tenter aussi. @CoolRaoul: Par rapport à ta question sur le besoin de ftp, il est exact que ma solution ne s'applique pas au serveur ayant seulement du ftp et pas de ssh. Mais j'ai le ssh donc cela me va très bien. De plus, comme je le disait, over ssh est bien sûr davantage sécurisé...

@Sp@r0 : malheureusement ipkg n'existe pas encore pour le DS213+ @CoolRaoul : merci pour la cross-compil, je vais garder ça sous la main pour une prochaine fois car j'ai trouvé mieux que wget pour le moment. (cf. ci-dessous). J'avais la semaine dernière tenter une cross-compil de lftp avec une VirtualBox sous debian, et la cross-compil a planté durant le configure et impossible de trouver la raison, donc j'ai abandonné car je n'étais pas sur d'avoir le bon cross-compilateur mais au regard de ton message j'avais bien le bon. Donc pas encourageant pour l'instant, mais je suis persévérant et je retenterais car il serait vraiment bien que ceux qui vont passer sur les nouveaux processeurs puissent en bénéficier. Cela dit, il y a surement plus équipé et plus compétent que moi... @tous: J'ai trouvé beaucoup mieux que wget pour réaliser des transferts, d'abord c'est sécurisé (wget n'a pas de sftp), c'est basé sur rsync qui est très très efficace, et ce n'est pas très compliqué à mettre en œuvre grâce à ce tuto vraiment génial !

Bonjour, Je souhaite utiliser wget pour rapatrier des fichiers d'une taille supérieure à 10 Mo en mode mirroir, malheureusement la version de wget 1.10 est buggée et ne sait pas comparer correctement les tailles supérieures à 10M. Résultat j'ai un download systématique de l'ensemble des fichiers à chaque déclenchement au lieu de ne récupérer que les nouveaux. Quelqu'un aurait-il une idée comment mettre à jour cette version assez ancienne (2005) de wget ? Merci d'avance,

Non malheureusement je n'ai pas réussi la cross-compilation de lftp, et il ne sert à rien de cross-compiler ipkg dans ce cas car il faut aussi cross-compiler tous les programmes pour ce nouveau processeur. A moins que quelqu'un trouve une équivalence avec des processeurs existants, ce que je n'ai pas su trouver bien que j'y ai passé un temps dingue ! J'imagine qu'un jour sortiront ces compilations, peut-être que ikeke pourrait retrouvé cela comme il l'avait déniché pour la génération précédente.

Si le transfert a été fait avec File Station, je ne m'explique pas ces différences.

Pour info, j'ai lancé une copie de 600Go d'un NAS D-link DNS-323 (ext3) vers un DS213+ (ext4) via le réseau interne en gigabit, et j'observe exactement le même délai avec FileStation de l'ordre de 48h. Par contre, j'ai noté qu'une copie avec rsync (lorsque applicable) était très nettement plus rapide, au moins 2 fois voire 4 fois plus rapide. A tester...

Merci cricx. Effectivement, je souhaitais utiliser ce qu'il y avait de base, mais impossible de paramétrer correctement. J'ai poursuivi un autre post de catimini ce weekend et nous avons fini par trouver l'anomalie avec CoolRaoul. Le post est pour ceux qui chercheraient la même chose...