JacquesF

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 fichier de log ceci permettra de savoir où est exécuté le script, et tant qu'on y est la commande "mount" redirigée comme les autres dans le log pour voir quels sont les systèmes de fichiers disponibles à ce moment. Solution 2 (nettement préférable car c'est prévu pour ça) : Les scripts d'exécution suivent plus ou moins le mode de fonctionnement de SystemV, et l'idéal est d'utiliser le script /etc/rc.local pour y placer les commandes à lancer au boot, ou les scripts à appeler. Ce script est le dernier à être exécuté dans le processus de démarrage du système, donc tout est opérationnel et accessible. Voici un exemple chez moi qui me permet de monter un partage réseau situé sur un autre serveur du LAN : root@Maison:~# cat /etc/rc.local #/bin/sh # Montage du partage Media du serveur if ping -c 1 -w 1 nom.du.serveur >/dev/null 2>&1 ; then mount -t nfs nom.du.serveur:/partage /volume1/serveur/ fi root@Maison:~# Celui-ci fait un test ping d'un paquet (-c 1) avec une attente d'un maximum d'une seconde (-w 1), si la réponse est correcte, alors on monte le partage NFS distant dans le volume1. Jacques

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

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, mon NAS le sert à stocker des sauvegardes, donc pas trop critique, des livres et BD au format électronique, des photos et des films. Les 3 dernières catégories sont des doublons (ou pratiquement) des données présentes sur mon PC (j'ai pas mal de stockage au final). Pas à l'abri d'un incendie, mais d'une casse de disque en grande partie en principe. Les données vraiments critiques sont aussi dans le cloud. Bonne fin de journée Jacques

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

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/resultat-boot.$$ exit 0 En fonction du résultat dans le fichier ($$ à la fin permet d'avoir le numéro de process en cours, ce qui rend le fichier le plus souvent unique, au moins dans le même démarrage), ça permettra d'adapter le script. Jacques

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 lien série # Le code MODE="0666" ne fonctionne pas # Contenu du script /etc/udev/rules.d/99-obpm.rules : # KERNEL=="hidraw*", ATTRS{idVendor}=="0590", ATTRS{idProduct}=="0090", MODE="0666", RUN+="/home/jacques/bin/UpdateUsbOBPM.sh" # /usr/bin/chmod 0666 /dev/usb/hiddev* 2>/dev/null exit 0 Tu peux peut-être contourner ça de la même façon, en mettant ce que devrait faire la règle dans un script. Pour savoir s'il est appelé, il suffit de créer un fichier via ce script. S'il est présent après l'insertion du périphérique, (s'il n'existait pas avant bien sur), alors le script fonctionne. Reste juste à y placer les bonnes commandes. Jacques

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 pour "sortir" les disques de la gestion mdadm. Ensuite, retente la modification avec la commande mdadm. Voir la réponse 6 de ce lien https://ubuntuplace.info/questions/311088/how-to-change-filesystem-uuid-2-same-uuid qui devrait correspondre à ton problème. Jacques

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 006: ID 046d:0825 Logitech, Inc. Webcam C270 Bus 003 Device 004: ID 05e3:0608 Genesys Logic, Inc. Hub Bus 003 Device 003: ID 0b05:17cf ASUSTek Computer, Inc. Bus 003 Device 002: ID 174c:2074 ASMedia Technology Inc. Bus 003 Device 008: ID 2101:020f ActionStar Bus 003 Device 007: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 003 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub [jacques@jacques ~]$ J'ai un port série sur un adaptateur USB qui est identifié par 067b:2303 et par exemple une webcam Logitech c270 identifiée 046d:0825. Avec ces codes, le noyau sait quels drivers il doit charger pour mettre en service les périphériques. J'ai eu un problème avec un matériel utilisant un port série USB dont le périphérique créé dans /dev n'avait pas les bons droits. Pour corriger ça, j'ai créé une règle udev qui défini pour le périphérique 0590:0090 des droits d'accès sur le device et appelle un script pour exécuter des commandes nécessaires avant de mettre en service le port. Ceci est placé dans une règle nommée 99-obpm.rules et située dans le dossier /etc/udev/rules.d/ À titre d'exemple, voici cette règle : [jacques@jacques ~]$ cat /etc/udev/rules.d/99-obpm.rules KERNEL=="hidraw*", ATTRS{idVendor}=="0590", ATTRS{idProduct}=="0090", MODE="0666", RUN+="/home/jacques/bin/UpdateUsbOBPM.sh" [jacques@jacques ~]$ Il y a de bons tutos sur les règles udev, mais je n'ai pas gardé les liens quand j'ai du régler mon problème. À partir du moment où le device est créé avec le bon nom et les bons droits, et que le pilote correct est chargé, il n'y a pas de raison de ne pas pouvoir y accéder ensuite. Bons tests Jacques

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

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) Sauvegarder au maximum les données accessibles 2) Prendre son temps 3) Si on est fatigué, remettre à plus tard les opérations critiques, une simple faute de frappe peut détruire un système raid En principe, même si le superbloc a été effacé par accident, les données ne sont pas modifiées sur le disque, mais un disque rajouté peut avoir un superbloc à jour (il fait partie du raid) mais ne pas avoir été reconstruit et donc ne pas contenir les données. Normalement, un raid SHR supporte 1 disque perdu, pas 2 (à moins d'avoir choisi la double redondance à la création, en DSM 6 uniquement). Donc le raid md2 me parait très mal en point (sauf si le disque d'origine déclaré en faut est encore lisible). Bon courage et patience surtout Jacques

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

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 raid1 sde3[0] 971940544 blocks super 1.2 [1/1] [U] md1 : active raid1 sda2[0] sdb2[1] sdc2[2] sdd2[3] sde2[4] 2097088 blocks [12/5] [UUUUU_______] md0 : active raid1 sda1[0] sdb1[1] sdc1[2] sdd1[3] sde1[4] 2490176 blocks [12/5] [UUUUU_______] unused devices: <none> md0 représente le système XPenology (réparti dans la partition 1 de chacun des disques durs md1 est le swap réparti sur la partition 2 de tous les disques durs md2 est un raid SHR réparti sur la partition 5 des 4 disques principaux (4T0) md3 est un raid SHR (sans sécurisation) sur un disque unique Le montage peut être vu avec la commande mount (mount | grep ^/dev pour ne voir que les partitions physiques ou presque) # mount | grep ^/dev /dev/md0 on / type ext4 (rw,relatime,journal_checksum,barrier,data=ordered) /dev/shm on /dev/shm type tmpfs (rw,nosuid,nodev,relatime) /dev/md3 on /volume2 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) /dev/mapper/vg1-volume_1 on /volume1 type btrfs (rw,relatime,synoacl,nospace_cache,metadata_ratio=50) Dans un raid SHR, il y a un raid Soft (mdadm) et une couche d'abstration supportée par LVM (Logical Volume Manager). La commande lvm permet d'afficher ou de gérer le tout (résultat pour le seul volume LVM présent dans mon NAS (/dev/mapper/vg1-volume) : lvm vgdisplay --- Volume group --- VG Name vg1 System ID Format lvm2 Metadata Areas 1 Metadata Sequence No 3 VG Access read/write VG Status resizable MAX LV 0 Cur LV 2 Open LV 1 Max PV 0 Cur PV 1 Act PV 1 VG Size 10.90 TiB PE Size 4.00 MiB Total PE 2858047 Alloc PE / Size 2858047 / 10.90 TiB Free PE / Size 0 / 0 VG UUID rdtKYh-nE8n-xLRq-CVPW-VXLE-LTDS-cBEMrK Ça devrait te permettre de t'y retrouver un peu plus facilement dans la configuration de tes disques. Jacques

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

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

@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

La connexion distante ne peut se faire que par un nom de domaine externe, ou une adresse IP externe, donc un compte dyndns par exemple. La Livebox ne sait pas faire de loopback, il faut donc utiliser une connexion depuis un autre PC relié à internet en dehors du réseau local (partage USB avec la connexion Data d'un portable par exemple). Ensuite, vérifier que le firewall du NAS est bien ouvert sur ces 2 ports, tout comme la box (en principe, si la redirection est faite ça devrait être autorisé, mais chez Orange rien n'est vraiment logique). Jacques

Bonsoir, Ou tout simplement FTP... ou FTPS, voire SFTP. C'est possible de passer un firewall, dans ce cas d'ailleurs SFTP (transfert de fichier via SSH) est le plus simple des 3). Une authentification par clef privée/publique étant la plus sécurisée. L'accès à un site distant internet peut se faire via l'explorateur (même si on n'aura pas en ce cas, et probablement idem en WebDav, l'affichage des miniatures et autres informations comme les tags). Jacques

Bonjour, Coupure électrique et paramètres implicites dans le bios... pile du bios à vérifier peut-être. Jacques

Donc, tu as un volume (le 1) monté sur un raid logiciel (SHR) supporté par 2 disques physiques (le 4 et le 6). Tu peux ajouter des disques par la suite, les insérer ou non dans ce volume, ou en créer un autre. Tu as plutôt intérêt à ajouter des disques dans le même volume pour augmenter la capacité, actuellement cela correspond à un raid miroir (la capacité d'un disque) mais avec la redondance des données sur l'autre. https://www.synology.com/fr-fr/support/RAID_calculator?hdds=2 TB|2 TB Jacques

Si tu ne vois qu'un disque dans le gestionnaire de stockage, il y a un problème (driver manquant, disque en panne, nombre de disques déclaré incohérent dans la clef usb). Selon ta configuration physique, et tes choix, tu peux créer un ou plusieurs volumes répartis sur un seul ou plusieurs disques, si tu vas dans Gestionnaire de stockage ==> HDD/SSD tu dois retrouver tous les disques physiques connectés à ton serveur. Jacques

Bonsoir, Le DSM s'installe sur une partition en RAId répartie sur tous les disques présents (ou rajoutés par la suite). Ceci permet de démarrer le DSM dans le cas de panne d'un ou de plusieurs disques (il faut tout de même qu'il en reste au moins un !). Donc, la réponse à ta question est "Non il n'est pas possible de choisir". Jacques

Bonjour, Si ESXi n'est pas installé sur ce SSD, il suffit de le connecter et de le déclarer comme nouveau datastore. Ensuite, déménager chaque VM sur ce nouveau datastore, supprimer l'ancien datastore une fois celui-ci vidé. Arrêter ESXi et desplacer le nouveau DS sur la connexion de l'ancien, redémarrer. Les DS sont identifiés par un UUID, donc au redémarrage le DS devrait être retrouvé sans soucis. Si l'ESXi est installé sur le SSD, alors il est possible de réaliser une copie de disque via un LiveCD avec un linux (genre RescueCD) et agrandir ensuite la partition de DS (plus risqué). Sinon, réinstaller ESXi sur le nouveau SSD, créer un DS dessus, arrêter le serveur, connecter l'ancien DS et le faire reconnaître par ESXi. Déplacer les VM sur le nouveau SSD et arrêter le serveur pour retirer le disque (comme dans le cas 1). C'est ce qui me paraît le plus simple. Jacques

Bonjour, Désolé, mais quelle est la question ? Sur quoi rencontres tu un problème ? Jacques

Bonsoir, je ne comprends pas clairement la phrase, je suppose que ce doit être "que procure le wifi". Le wifi étant fourni par la box dans la très grande majorité des cas (ce n'est pas le cas chez moi), le PC est donc sur le LAN de la box, et le NAS l'est lui aussi. Donc il doit être visible dans le voisinage réseau ou accessible via upnp selon les applications installées (videostation et/ou partage Samba (SMB)). Comme je l'ai écrit, le VPN n'est à activer que lorsqu'on se trouve en dehors du réseau de la maison, chez un ami par exemple. Comme se rendre chez une autre personne pour les tests n'est pas évident en ce moment, une façon simple de tester est d'utiliser le partage réseau via USB d'un téléphone portable (en désactivant le Wifi sur celui-ci pour forcer à venir de l'extérieur du réseau via l'opérateur mobile). En connectant le mobile au PC portable, en activant le partage sur le smartphone, internet doit être accessible (désactiver le wifi et débrancher le câble réseau éventuel sur le PC) pur forcer la route via le téléphone. OpenVpn est aussi disponible pour android, ce qui permet d'utiliser les applications comme DSvideo, DSfiles, DSaudio, etc... sur le mobile. Jacques

Bonjour, Un VPN permet d'accéder depuis un site (généralement externe) à un autre (situé en principe dans un réseau qui n'est pas ouvert à l'extérieur) et ce de manière sécurisée. Concernant le PC professionnel utilisé sur le réseau Wifi du domicile, OpenVPN n'a pas lieu d'être si c'est pour accéder au NAS depuis justement ce réseau Wifi (qui est sur le même LAN que le NAS en principe). En revanche, il est très probable que ce dit PC utilise lui-même un VPN pour accéder au réseau professionnel, ce qui peut poser un problème d'accès au LAN du domicile quand la connexion est active (tout dépend du client VPN et de sa manière de gérer la couche réseau et son routage, soit il fait passer toutes les requêtes réseau par le VPN (et dans ce cas le NAS sera inaccessible) soit il ne route que les requêtes concernant le réseau distant (pro) via l'interface VPN). seuls les tests permettront de vérifier le mode de fonctionnement. Sur le PC Pro, installer OpenVPN (si l'installation est autorisée par l'admin réseau au niveau du PC) ne sera utile que pour accéder au LAN du domicile lorsque le PC sera "en déplacement" et peut-être non connecté au LAN de l'entreprise (selon les explications ci-dessus). L'accès au réseau du domicile via OpenVPN depuis le réseau professionnel (et donc en ouvrant un VPN pro via le client de l'entreprise, puis un VPN perso via OpenVPN à travers ce second réseau) est probablement bloqué par le pare-feu de l'entreprise et ne serait du plus pas très performant. Jacques