JacquesF

Members
  • Content Count

    286
  • Joined

  • Last visited

  • Days Won

    10

JacquesF last won the day on February 23

JacquesF had the most liked content!

Community Reputation

33 Excellent

About JacquesF

  • Rank
    Super Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bizarre... mais comme ce script est appelé au boot, il est possible que tous les disques ne soient pas montés et que le raid ne soit pas accessible... Solution 1 (pas propre) : Éventuellement, mettre une copie du fichier autossh (avec un chmod 755 sur le fichier pour assurer ses droits d'exécution) dans le même dossier que le script et modifier le chemin de la commande pour l'adapter à l'emplacement du script, ou le placer le programme dans /bin ou /sbin qui sont toujours disponibles au boot. On peut rajouter dans le script la commande "pwd" redirigée (avec >>) vers le fic
  2. Bonjour, La commande "which autossh" devrait retourner le chemin. Si elle ne renvoie rien, c'est que le programme n'est pas dans le PATH. Dans ce cas, une commande comme find retournera la réponse : find / -type f -name autossh C'est toujours le même problème avec les scripts appelés par cron ou au démarrage, il est toujours préférable d'indiquer le chemin complet pour limiter à la fois les problèmes de sécurité et les soucis de ce genre. Bonne journée Jacques
  3. Bonsoir, Si les données pouvaient être perdues... dans ce cas ce n'est pas trop risqué. A voir une fois la reconstruction terminée, mais je serai surpris qu'on puisse y accéder. Une fois le raid reconstruit, il 'y a plus rien à faire en principe, à part planifier des sauvegardes automatiquement pour les fichiers sensibles... J'ai des erreurs d'écriture qui apparaissent sur un de mes 4 disques de 4To... je ne vais pas tarder à tester la reconstruction je crois. On en revient toujours au même point, les sauvegardes sont essentielles. Personnellement, m
  4. Bonsoir, Effectivement, avec 2 disques manquants (le fait de ne pas être à jour est similaire), pas moyen de reconstruire un raid. Dans le lien donné, la commande est donné pour md127, c'est à dire un raid "sans disque" pour le moment. En mettant md2, on force à insérer le disque dans une grappe existante, ce qui échoue à priori et l'ID n'est pas mis à jour. J'essaierai avec md127, pour permettre la mise à jour de l'ID, puis ensuite de le réinsérer dans la grappe (stop du md127 et assemble sur md2 de tête). Jacques
  5. Bonsoir, Le plus souvent, c'est un problème de PATH ou de droits lors du lancement d'une commande dans un script. L'environnement d'exécution n'est pas le même que celui de l'utilisateur (il est souvent très restreint), et il est préférable de mettre le chemin complet du programme (/bin, /usr/bin, etc... selon l'emplacement de autossh). Et vérifier que le script est bien appelé, en créant un fichier par exemple dans /tmp (avec le résultat de la commande echo $PATH) : #!/bin/bash # Test de l'environnement au démarrage echo $PATH > /tmp/resultat-boot.$$ env >> /tmp/re
  6. Bonsoir, C'est difficile de savoir ce qui est réellement utilisé dans Xpenology par rapport à un linux classique. En principe, si le démon udev est lancé au boot, alors les règles devraient être traitées. Sur mon NAS il est actif, donc je pense qu'il faut fouiller encore un peu dans l'écriture des règles. Le lancement d'un script via udev permet de faire ce qu'on veut, dans mon cas, le mode 0666 n'était pas appliqué par la règle, j'ai donc créé ce script qui fait ça : #!/bin/bash # # Script appelé par une règle udev pour corriger les droits du port USB utilisé par le li
  7. Bonsoir, Je n'ai jamais eu à jour avec les UUID pour un raid, mais c'est vrai que ça peut se tenter sans grand risque. /dev/md127 est un périphérique raid créé lorsqu'on ne peut pas identifier le numéro du raid dans les données du disques (dans ton cas, tu dois avoir les autres qui ont été détectés correctement, et le disque sdd qui ne peut être rattaché au raid probablement suite à son UUID. Le process qui occupe le disque est très probablement la gestion du raid par mdadm. Il faut donc démonter les partitions /dev/mdX, désassembler le raid avec la commande qui va bien pou
  8. Bonjour, Un périphérique USB est identifié par un numéro d'identifiant unique en 2 partie, la première identifiant le constructeur, la seconde le produit. Exemple d'un lsusb sur ma machine linux perso : [jacques@jacques ~]$ lsusb Bus 002 Device 002: ID 8087:8000 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 002: ID 8087:8008 Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 002: ID 174c:3074 ASMedia Technology Inc. Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 003 Device 00
  9. Bonsoir, Je ne connais pas ce type d'installation, et de clef, mais les affectations de ressources aux périphériques se font (en principe) avec les règles udev. Il est possible de configurer udev pour affecter un port, une adresse, un nom, etc... à un périphérique plug & play. Ça vaut peut-être le coup de suivre cette piste. Jacques
  10. Bonjour, Effectivement, il semble manquer sda et sdc au niveau des raids md2 et md3 (et pour md3 c'est un seul disque, ce qui semble indiquer que les informations du raid inscrites dans le superblock (en fin de disque) ne sont pas à jour. Les commandes mdadm permettent de reconstruire un raid et d'ajouter manuellement (ou de retirer) un disque d'un grouê raid. Je n'ai pas assez de pratique pour te guider de mémoire, les tutos ne manquent pas, entre autres celuici : https://www.linuxpedia.fr/doku.php/expert/mdadm Les règles de base sur ce genre de problème sont : 1) Sau
  11. Juste un complément sur ma réponse : Dans le fichier /proc/mdstat, on voit la structure des différents raids et les disques concernés. Pour mémoire, un disque Up est noté U, un disque absent _ Pour md0, le système, il est prévu sur tous les disques possibles (8), donc les infos d'état des disques sont : [UUUUU_______] soit 4 Up et 4 manquants Pour md1, le swap, c'est la même configuration : [UUUUU_______] Pour md2, le volume1 via LVM, il y a 4 disques déclarés, donc on retrouve l'état ainsi : [UUUU] Pour md3, un seul disque, l'état est noté : [U] Jacques
  12. Bonjour, /dev/mdX représente un groupe raid (0 pour le premier, 1 pour le 2ème, etc...). Ces groupes sont répartis sur un certain nombre de disques ou de partitions et on peut voir la structure (et les manquants dans le fichier /proc/mdstat (commande cat /proc/mdstat pour lire le contenu). Résultat de la commande "cat /proc/mdstat" sur mon NAS : Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [raidF1] md2 : active raid5 sda5[0] sdd5[3] sdc5[2] sdb5[1] 11706562368 blocks super 1.2 level 5, 64k chunk, algorithm 2 [4/4] [UUUU] md3 : active rai
  13. Bonjour, Pour récupérer les données, l'idéal est d'utiliser un live-cd Linux et de monter (si ce n'est as fait automatiquement) les différentes couches (LVM et mdadm). Il y a un article sur le site de Synology pour accéder aux disques à partir d'un linux (CD ou USB). Regarde les messages d'erreur enregistrés dans le bios éventuellement (NMI), ça peut aider si c'est un problème hard c'est parfois enregistré. Jacques
  14. Bonsoir, Pas évident comme problème, mais un plantage brutal est possible aussi en cas de surchauffe du proc ou du chipset (et éventuellement de la RAM). Selon les bios, la machine peut s'arrêter brutalement si la température est surveillée, ou rester figée dans le cas contraire. La reconstruction d'un disque en raid soft consomme pas mal de CPU je suppose, donc la surchauffe pourrait être une piste à exploiter. Bons tests et bon courage Jacques
  15. @nicoueron : Oui, mais en faisant cela on ne teste pas la connexion externe, ce qui semble être son besoin. Maintenant à titre perso, pour un serveur accessible de l'extérieur, je préfère une authentification par clef via SFTP (ou SSHFS mais je ne sais pas s'il existe un outil dans le monde Windows pour ça) qu'une simple identification par login/password (ftp/ftps/WebDav). Mais on est libre de choisir ce qu'on veut, et si le mot de passe est robuste, ça reste fiable. Jacques