JacquesF

Bonjour, Pour la récupération des données des disques Synology, il y a u sujet expliquant la procédure à tenir sur leur site : https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC Le principe est de démarrer le PC avec un mini système Linux (RescueCD offre tous les outils nécessaires pour ça) et de monter la structure des disques ensuite. Après, le partage des disques peut se faire pour récupérer les données via le réseau, ou les transférer via le réseau sur un autre serveur, ou vers un disque USB. Jacques

Bonjour, Pas certain que ce soit la clef du problème, étant donné que je ne transcode pas sur mon installation, mais il me semble que pour activer le transcodage il fallait un numéro de série valide et un hardware adapté. On doit pouvoir retrouver des discussions sur ce sujet en faisant une recherche avec ces mots clefs dans le forum. Maintenant, en utilisant un player comme VLC sur les mobiles, il doit être possible de lire les fichiers nativement et donc de se passer du transcodage je pense. Jacques

Bonjour, Pas vu le message plus tôt, mais voici un lien de partage perso où je laisserai les fichiers quelques temps. Provenance direct de Synology, non modifiés. Le fichier de version et le patch v3. https://u.pcloud.link/publink/show?code=kZcArAVZOWKY1zIuOU71do3BXUu1EFjeUHB7

Juste pour info, *.* c'est pour Windows, sous Unix et dérivés (dont VMFS) c'est * simplement. Je ne sais pas si c'est le dossier FAC qui doit être supprimé, auquel cas en se plaçant un cran au-dessus (probablement la racine du datastore) dans l'arborescence ce serait la commande rm -rf FAC qui serait à faire. Mais vue la réponse, ça semble plutôt être un problème dans le système de fichiers, l'erreur étant sur un fichier non présent (à priori). Si le datastore est vide, on peut le recréer facilement ou le reformater (commande vmfs). Sinon, faire un tour dans la base de connaissance VMware pour y trouver l'équivalent d'un fsck pour vérifier le système de fichiers. Ceci pourrait peut-être être utile : https://www.settlersoman.com/how-to-check-and-fix-vmfs-metadata-using-vsphere-on-disk-metadata-analyzer-voma/ https://hardforum.com/threads/esxi-chkdsk-equivalent.1720684/ Jacques

Si la connexion se fait sur le NAS, le dossier doit pourvoir être effacé avec les commandes Linux de base, sauf dégâts dans le système de fichiers. Pour voir les fichiers ou dossiers cachés sous Linux (via Putty), faire un "ls -la" dans le dossier qui n'est pas "vide" (ls = lister -l = mode long -a = all). Si quelque chose apparaît, hormis les dossiers . et .. classiques, soit l'effacer s'il n'a plus d'importance, soit le récupérer avant. Si c'est un dossier, on peut recommencer la méthode dans chaque sous-dossier trouvé mais ça peut être long. Pour effacer le dossier récalcitrant d'un seul coup (pas de récupération possible), se placer dans le dossier parent et faire : rm -rf LeNomDuDossier (rm = remove -r = récursif -f = force) Attention à ne pas faire cette commande n'importe où, si on est connecté avec les droits root, on peut effacer quasiment tout le disque en la lançant au mauvais endroit. Jacques

Petit raccourci vi pour quitter en sauvegardant : Esc + ZZ (en majuscules)

Merci pour tous. Même si c'est peut-être peu, cela peut guider vers une piste profitable à d'autres. Bonne journée aussi Jacques

Bonsoir, Ce qui serait sympa ce serait de partager ces informations justement, pour que le prochain qui cherche trouve plus facilement... Bonne fin de soirée. Jacques

Ce lien dans l'aide de Synology devrait aider : Comment récupérer des données sur un PC en cas de dysfonctionnement du Synology NAS | Synology Inc. Jacques

Bonjour, Dans le log, il y a des erreurs disques sur les sdb / sdc / sdd et sdg. Entre autre le compteur Raw_Read_Error_Rate et le disque sdg semble cumuler plusieurs types d'erreurs. Donc, réparer le système de fichiers comme le propose le DSM serait une bonne idée, en faire une sauvegarde très rapidement ce serait encore mieux. Les disques B, C et D ne me semblent pas dans un état critique, une erreur ou deux en lecture ça arrive, mais ça suffit pour provoquer une alerte sur un système RAID. En revanche le disque G (WD-WMC4N2705741) présente 44 erreurs pour Raw_Read_Error_Rate et 1 erreur Multi_Zone_Error_Rate. Et le nombre d'heures de fonctionnement est très important aussi pour tous les disques (plus de 70 000 h, ce qui donne plus de 8 ans en principe). Je commencerais sérieusement à prévoir le remplacement personnellement. Et une sauvegarde urgente aussi... Jacques

De plus, une distribution linux permettrait aussi de sauvegarder les données. Voir cette procédure sur le site de Synology : https://kb.synology.com/fr-fr/DSM/tutorial/How_can_I_recover_data_from_my_DiskStation_using_a_PC Jacques

Bonsoir, Si le NAS est accessible depuis l'extérieur, il st logique qu'une tentative de connexion arrive régulièrement. Des robots fonctionnent H24 en scannant toutes les adresses IP publiques pour trouver des serveurs vulnérables à des failles connues, ou des serveurs mal protégés avec des mots de passe connus. Rien d'étonnant à ce que ça se produise, personnellement des tentatives de connexion avec l'utilisateur root j'en ai eu 41454 depuis une semaine sur un serveur accessible sur le net (ce n'est pas un NAS, mais le principe est le même). grep -c "Failed password for root" /var/log/auth.log 41454 Bonne fin d'année Jacques

Bonjour, Je n'ai plus le post en tête, mais il y a une idée que j'avais lancé il y a 2 ou 3 ans dans le forum concernant le fait de multiplier des instances et Surveillance Station via des VM et d'avoir une application qui permettait de regrouper les 2 caméras gratuites de chaque instance dans une interface commune. Et si je ne m'abuse, c'est Nicoueron qui avait réalisé quelque chose là-dessus et partagé la solution. Rechercher ça pourrait faire gagner pas mal de temps pour mettre en place une solution relativement simple et fiable. Jacques

Le SHR est un raid tout à fait standard (raid logiciel linux) monté sur une couche LVM, elle-même tout à fait standard. Cela ne pose aucun problème à mon sens d'utiliser le SHR, avec la souplesse de gestion des volumes en plus.

Ça offre aussi (et c'est un plus sérieux) la sécurité de pouvoir utiliser des outils Linux standards pour récupérer un volume DSM planté. Le raid matériel est généralement plus efficace que le raid logiciel (dans le cas de la virtualisation l'ajout de la couche Huper-V entre la VM et le Raid devant influer) mais reste lié physiquement au type de contrôleur raid utilisé. S'il est en panne, il faut le même pour avoir une chance de récupérer ses données. Jacques

Bonjour, Les scripts de démarrage ont l'air d'être dans /etc/init. En fait, les fichiers de lancement sont les *.conf, et un fichier *.override permet de désactiver le lancement automatique à priori. Dans mon cas (je suis en 6.2), le fichier telnetd.override contient l'information "manual" car ce service n'est pas activé sur mon NAS. Dans le fichier telnetd.conf, on lance le démon via le script "/usr/syno/etc/rc.sysv/inetd.sh" avec l'option prestart_telnetd le script inetd.sh doit reproduire plus ou moins le démon inetd traditionnel. En renommant le fichier *.conf concerné (peut-être en enlevant le droit "x" cela suffirait), on devrait pouvoir désactiver le démarrage du service. Il est aussi possible que pour telnetd.override, le fait de manual dans le fichier concerné suffise. Jacques

Bonjour, La désactivation d'un service semble possible via le fichier /etc/synoinfo.conf Dans le mien, j'ai la mention support_timebkp_server="yes" qui est présente, mais le paquet n'est pas installé. Il y a peut-être d'autres mentions dans le cas où celui-ci a été activé, à chercher dans les fichiers (un grep -Ri timebkp /etc/* devrait donner la liste des fichiers ayant une ligne de ce genre dans le dossier de configuration). La méthode de désactivation utilisée dans le fichier est de mettre la ligne en commentaire (# en début), mais je suppose que mettre "no" devrait aussi fonctionner. En principe, les paquets sont installés à la racine d'un des volumes (choix lors de l'installation) dans un dossier à leurs noms précédés d'un @. Renommer ce dossier devrait aussi empêcher de lancer le programme mais peut causer un soucis de fonctionnement du NAS (bon, si le programmeur a bien codé son truc, ça devrait provoquer la sortie directe du programme sans autre problème qu'une ligne de log...). Jacques

Si le problème est le message : "Booting the kernel." et rien d'autre, voir l'image jointe, alors c'est normal (avec le loader de Jun). La connexion n'est possible qu'en SSH avec un compte disposant des droits admin, faire un sudo -i suivi du mot de passe du compte pour passer en root. Pour info, les ports TCP actifs sur ma machine sont les suivants (DSM 6.3) : root@Maison:/var/log# netstat -lataupe | grep LISTEN tcp 0 0 0.0.0.0:netbios-ssn 0.0.0.0:* LISTEN root 23067 14041/smbd tcp 0 0 0.0.0.0:sunrpc 0.0.0.0:* LISTEN root 22676 13512/rpcbind tcp 0 0 0.0.0.0:http 0.0.0.0:* LISTEN root 21255 6280/nginx: worker tcp 0 0 nas.chez.moi:50001 0.0.0.0:* LISTEN root 34035 16141/dms tcp 0 0 nas.chez.moi:49170 0.0.0.0:* LISTEN AudioStation 35146 16485/synoaudiod tcp 0 0 0.0.0.0:50002 0.0.0.0:* LISTEN root 32456 16417/lighttpd tcp 0 0 0.0.0.0:33780 0.0.0.0:* LISTEN root 17835 - tcp 0 0 0.0.0.0:ssh 0.0.0.0:* LISTEN root 14057 10447/sshd tcp 0 0 localhost:postgresql 0.0.0.0:* LISTEN postgres 25188 14461/postgres tcp 0 0 0.0.0.0:53434 0.0.0.0:* LISTEN root 16121 13800/statd tcp 0 0 0.0.0.0:https 0.0.0.0:* LISTEN root 21257 6280/nginx: worker tcp 0 0 0.0.0.0:892 0.0.0.0:* LISTEN root 22124 13550/mountd tcp 0 0 0.0.0.0:microsoft-ds 0.0.0.0:* LISTEN root 23066 14041/smbd tcp 0 0 0.0.0.0:3262 0.0.0.0:* LISTEN root 25144 14025/iscsi_snapsho tcp 0 0 0.0.0.0:nfs 0.0.0.0:* LISTEN root 18087 - tcp 0 0 0.0.0.0:6690 0.0.0.0:* LISTEN root 33129 16535/syncd tcp 0 0 0.0.0.0:50373 0.0.0.0:* LISTEN root 21060 - tcp 0 0 0.0.0.0:DSM-http 0.0.0.0:* LISTEN root 21251 6280/nginx: worker tcp 0 0 0.0.0.0:DSM-https 0.0.0.0:* LISTEN root 21253 6280/nginx: worker tcp 0 0 0.0.0.0:svn 0.0.0.0:* LISTEN root 31075 15978/svnserve tcp6 0 0 [::]:netbios-ssn [::]:* LISTEN root 23065 14041/smbd tcp6 0 0 [::]:sunrpc [::]:* LISTEN root 22679 13512/rpcbind tcp6 0 0 [::]:http [::]:* LISTEN root 21256 6280/nginx: worker tcp6 0 0 [::]:ssh [::]:* LISTEN root 14059 10447/sshd tcp6 0 0 [::]:36087 [::]:* LISTEN root 17836 - tcp6 0 0 [::]:https [::]:* LISTEN root 21258 6280/nginx: worker tcp6 0 0 [::]:892 [::]:* LISTEN root 22128 13550/mountd tcp6 0 0 [::]:microsoft-ds [::]:* LISTEN root 23064 14041/smbd tcp6 0 0 [::]:3261 [::]:* LISTEN root 22783 - tcp6 0 0 [::]:3263 [::]:* LISTEN root 22782 - tcp6 0 0 [::]:8096 [::]:* LISTEN emby 390207334 10304/EmbyServer tcp6 0 0 [::]:3264 [::]:* LISTEN root 22784 - tcp6 0 0 [::]:nfs [::]:* LISTEN root 21050 - tcp6 0 0 [::]:6690 [::]:* LISTEN root 33130 16535/syncd tcp6 0 0 [::]:49379 [::]:* LISTEN root 21062 - tcp6 0 0 [::]:46599 [::]:* LISTEN root 16125 13800/statd tcp6 0 0 [::]:DSM-http [::]:* LISTEN root 21252 6280/nginx: worker tcp6 0 0 [::]:DSM-https [::]:* LISTEN root 21254 6280/nginx: worker Le nombre de ports ouverts est variable en fonction des applications lancées. Les 2 ports 5000 et 5001 (représentés ici avec DSM-http et DSM-https sont ceux permettant d'accéder à l'interface Web. Les logs intéressants sont dans le dossier /var/log (commande cd pour s'y rendre). La commande pour lire un fichier page par page est more NomDuFichier les fichiers intéressants sont nombreux, mais syslog.log et messages sont ceux qui contiennent les informations de lancement et d'arrêt des services entre autres. Des erreurs peuvent être normales ou sans conséquence, ne pas faire de fixation sur les mots error ou failed dans tous les cas, cela dépend de pas mal de choses et c'est difficile de décrire ce qui doit être présent ou non. Bonne recherche Jacques

Bonjour, à première vue, le volume contenant le dossier des utilisateurs est en faute (/var/services/home/Indie ou Indie devrait être l'utilisateur qui tente de se connecter en SSH). Si un autre compte existe, essayer de se connecter avec (ce serait le top s'il avait les droits admin) et voir ce qu'il en est. Autrement, tenter un démarrage sur un LiveCD (via USB ou une clef USB bootable d'un CD Linux) et monter les volumes comme indiqué sur le site de synology (récupération des disques en cas de panne). Ensuite, lancer un fsck du volume et croiser les doigts. Si le volume n'est pas opérationnel, sauvegarder les maximum est réinstaller le tout est probablement la solution la plus simple si on n'a pas d'expertise dans le monde Linux et récupération de disque. Il y aura sûrement d'autres avis dans le forum, aussi ne rien tenter d'irrémédiable avant d'avoir recueilli plusieurs avis (dans ce genre de soucis, la précipitation fait souvent plus de dégâts que la panne elle-même). Jacques

Bonjour, Je ne sais pas si cette carte est reconnue par le loader 1.03b, à vérifier dans le forum anglais ou sur celui indiquant le résultat des différentes loader avec le détail des configs. En revanche, pour que le DSM reconnaisse les cartes, il faut déclarer le nombre d'interfaces ETH et leurs adresses MAC dans le grub.cfg (à modifier dans la 1ere partition de la clef USB si je me souviens bien). Ceci est expliqué dans le forum aussi (partie installation). De plus, il est possible qu'il faille ajouter les drivers spécifiques à cette carte (si elle est prise en charge par le loader). Dans ce cas, la procédure à suivre est indiquée dans la partie consacrée à ce loader sur le forum. Tu auras peut-être une réponse plus précise si quelqu'un ici a déjà fait tourner son NAS avec cette carte, mais ces points sont à vérifier (surtout la modification du grub.cfg). Jacques

Les différences entre les liens physiques et symboliques : [jacques@jacques test]$ ls -li total 0 132252199 lrwxrwxrwx 1 jacques jacques 4 sept. 2 10:41 titi -> toto 132252192 -rw-r--r-- 2 jacques jacques 0 sept. 2 10:41 toto 132252192 -rw-r--r-- 2 jacques jacques 0 sept. 2 10:41 tutu Les 3 noms pointent vers le même fichier (vide) toto. titi est un lien symbolique (visible par le "l" qui précède les droits (en principe toujours 777, soit rwxrwxrwx, car ils sont vérifiés sur le fichier cible). tutu est un lien physique vers toto car le numéro d'inode 132252192 est identique pour les deux fichiers. La taille du fichier est la même (0 octet) dans ce cas. Dans le cas d'un lien symbolique, la taille du lien correspond en fait à la longueur de la chaîne de caractères qui contient le chemin vers le fichier (ici le lien est relatif, donc toto faisant 4 caractères, le lien en fait 4). Un lien physique ne peut être créé que dans un même système de fichiers (en fait chaque nom de fichier pointe vers le même emplacement indiqué par l'inode). Un lien symbolique pointe où l'on veut, même vers des montages réseau. La différence de fonctionnement est que pour un lien symbolique, si le fichier cible disparaît, le lien est mort, alors que pour un lien physique le fichier continue d'exister tant qu'il existe un nom (une référence) qui pointe vers lui (le nombre de lien est indiqué dans le 3ème champ dans mon exemple, ici 2). Dans ton cas, il faut vérifier que le programme lftp est bien soit la cible d'un lien symbolique (facilement visible avec "ls -l") ou celle d'un lien physique (infos à afficher pour chaque instance du programme), dans ce cas soit le n° d'inode est à vérifier (par "ls -li") soit le nombre de liens indiqué dans le 2ème ou 3ème champ de la commande "ls" selon qu'on utilise les options "-l" ou "-li". Jacques

La réponse à la commande semble indiquer que la cible et la destination sont les mêmes fichiers. La commande 'ls -li' indique dans le premier champ le n° d'inode associé au fichier, si ce sont les mêmes sur les 2 c'est effectivement un lien physique. Dans ce cas, renommer les 2 par sécurité et copie le nouveau programme aux deux emplacements sous le nom d'origine permettra au moins de faire un test, ceci sous réserve que le programme fonctionne effectivement dans l'environnement du NAS. Il faudra peut-être regarder les droits étendus qui peuvent être associés au fichier, mais je ne suis pas certain que ce soit utilisé pour les binaires. Ça l'est pour les dossiers partagés en tout cas. Jacques

Tu peux tester en renommant le fichier dans le même répertoire, ou en faisant un lien physique au lien d'un lien symbolique (mais dans ce cas, on doit être sur la même partition). Tester avant le binaire en ligne de commande pour voir s'il ne provoque pas un plantage (architecture ou dépendances incorrectes). J.

Dernier recours... Compiler le programme soi-même avec les options voulues en dur et remplacer (via un lien physique) le binaire fourni ??? Pas certain que le jeu en vaille la chandelle. Jacques

Pas évident à trouver, mais en principe les paquets (pour ce que j'en ai vu) placent leur config dans /var/package. Je tenterai ça : grep -R "ssl:verify-certificate" /var 2>/dev/null L'option -R suit les liens symboliques au cas où... Ça devrait te dire dans quel fichier se trouve cette option, et par là le modifier éventuellement. Jacques