Mic13710

En fait, les cas de figures en opération sont assez simples : uniquement lorsque le nas démarre automatiquement pour lancer des sauvegardes, la surveillance est inutile est doit être arrêtée. Pour tous les autres cas (démarrage manuel ou au travers du wol), surveillance station doit rester actif. Si je souhaite travailler sur le DSM, je peux très bien démarrer le nas par le wol et désactiver SS si besoin. Le seul petit bémol que je vois avec le démarrage auto c'est lors des changements d'horaires hiver/été qui risquent de perturber les sauvegardes du fait des décalages d'une heure entre les deux nas. Mais ce n'est que deux fois par an et je peux éventuellement lancer les sauvegardes manuellement si besoin. A ce propos, je crois avoir vu dans les fichiers que le nas procèdait à la mise à jour de l'horloge au démarrage. Est-ce exact ? Le deuxième volet de ce que je souhaite faire concerne l'arrêt du nas secondaire une fois les opérations de sauvegardes terminées. Pour le moment, les cron de mes 7 sauvegardes sont dans le nas principal. Le secondaire est complètement aveugle et ne fait que faire des enregistrements en fonction des requêtes du nas principal. Il faudrait qu'il puisse savoir si toutes les sauvegardes sont terminées pour pouvoir initier un signal d'arrêt. L'arrêt du nas serait alors conditionné par le status de surveillance station : si actif, l'arrêt est retardé jusqu'à ce que la surveillance soit désactivée. Si désactivé, arrêt immédiat. La encore, je ne suis pas capable de dire si c'est réalisable et encore moins comment le faire. Mais ce sujet, bien qu'il corresponde à mon "plus si affinité", sort un petit peu du cadre de ce fil et fera je pense l'objet d'une autre discussion. Voila, je pense n'avoir rien oublié. Reste à mettre tout ça en musique et c'est là tout mon problème. Merci à toi si tu peux m'aider à mettre le ou les scripts en place.

Pour les mise à jour, pour éviter de charger le mauvais fichier, le mieux et d'utiliser la fonction de mise à jour du DSM du panneau de configuration. Tout d'abord, cette mise à jour sera faite de manière chronologique parce qu'il n'est pas du tout certain que vous puissiez passer directement de la 4.1 à la 4.3. Le NAS ne vous proposera que la version que vous pouvez télécharger en fonction de celle installée dans le NAS. Par contre, je vous déconseille fortement de mettre la 5.0 pour le moment, surtout si c'est un NAS qui tourne dans un environnement professionnel. Pour ne charger que les versions critiques, vous avec un choix à faire dans le menu de mise à jour. Pour cela vous cliquez sur "Options de mise à jour" et vous choisissez "Mises à jour importantes". La 5.0 n'étant pas une mise à jour importante, elle ne vous sera pas proposée, donc pas de risque de la télécharger par mégarde. Avec cette option, vous devriez vous arrêter à la 4.3-3827 Update 1 qui comporte la correction de la faille de sécurité. Mais à la vue de vos remarques, je ne crois pas que vous soyez affecté. Et comme le dit domlas, vous avez sûrement une solution de sauvegarde mise en place, surtout si ce sont des données professionnelles dont la perte serait dommageable pour l'entreprise. Même s'il y a toujours un risque que la maj ne se passe pas bien, il est malgré tout très limité dans la mesure où vous évoluez de la 4.1 vers la 4.3, donc dans une même version du DSM. Ce sont des évolutions et non des révolutions. Dans le cours ou à la suite à vos mises à jour, il est possible que vous ayez à remettre à jour des paquets. Là encore, les risques sont limités.

En fait, je ne suis pas du tout certain que le démarrage ou l'arrêt du paquet dans le DSM soit la solution car il y a du même coup la perte des paramètres. En fait, quand on arrête le paquet, tous les paramètres de connexion qui ont été mis dans le portail des applications sont perdus, ce qui du même coup interdit toute connexion directe par le DSM ou DSCam. C'est absurde mais c'est comme ça que ça fonctionne, ou plutôt que ça ne fonctionne pas. Je crois que le seul moyen accessible sans trop se prendre la tête c'est d'utiliser le start-stop-status qui assure l'activation/désactivation de SS tout en laissant le paquet en opération. Seulement voilà, si je vois bien maintenant ce qu'il faut faire, je ne sais malheureusement ni lire ni écrire des partitions Linux. Tout d'abord, je ne sais pas s'il est possible de capturer le mode de démarrage (manuel, par WOL ou bien automatique) Ensuite, je ne sais pas comment se comporte le démarrage automatique si le nas est déjà allumé. Est-ce que le démarrage auto est inhibé ? Si le démarrage auto peut-être capturé et si et seulement s'il a effectivement démarré le NAS, alors il s'agit dans mon cas d'un démarrage pour faire la sauvegarde et SS est inutile. On peut donc envoyer un stop pour arrêter SS juste après son démarrage. Pour ce script, on peut peut-être utiliser le start-stop-status status, mais je n'ai aucune idée de ce qu'il renvoit, ou bien encore vérifier la présence du fichier temporaire /var/tmp/ssrunning qui lui n'existe que si SS est actif. Si c'est un démarrage manuel ou par le WOL, c'est que je souhaite faire de la surveillance et on laisse donc SS en opération. Si entre temps le démarrage auto est arrivé à échéance pour effectuer les sauvegardes programmées, il ne faut pas bien entendu que SS soit arrêté. Voilà comment je vois les choses. Est-ce que c'est faisable et comment, c'est toute la question.

Oui bien sûr. Surveillance Station ne redémarre pas. Enabled c'est apparemment la mémorisation du choix utilisateur pour le paquet SS. S'il est présent, SS démarre avec le NAS, sinon SS reste à l'arrêt. Comme Surveillance Switch semble agir autrement et se contrefiche de la présence ou non du enabled, de même qu'il n'utilise pas le start-stop-status pour démarrer ou arrêter la surveillance, je ne vois qu'une seule issue, c'est de laisser SS démarrer avec le NAS et de faire un arrêt de SS suivant critères comme j'en ai parlé dans mon message #15. Qu'en penses-tu ?

Premiers retours. Tout d'abord quelques relevés dans le fichier /var/log/surveillance.log Arrêt du paquet SS à partir du centre des paquets de DSM Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:46:42 ssd.cpp:170:main(): Cam[1]: Signal! Stop retry init(). Apr 19 13:46:42 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:46:42 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:46:47 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:46:47 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:46:48 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:46:49 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:46:49 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled est supprimé Démarrage du paquet SS à partir du centre des paquets de DSM Apr 19 13:48:12 sscored.cpp:109:main(): Start sscored. Apr 19 13:48:13 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:48:13 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:48:13 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:48:13 services.cpp:530:StartAllSsd(): Try to start cam[4]. Le fichier /var/packages/SurveillanceStation/enabled est créé Arrêt de la surveillance à partir de l'appli android Surveillance Switch Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:40:00 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[1]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:40:00 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:40:05 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:40:06 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:40:07 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:40:08 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:40:08 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled n'est pas supprimé Démarrage de la surveillance à partir de l'appli android Surveillance Switch Apr 19 13:44:49 sscored.cpp:109:main(): Start sscored. Apr 19 13:44:51 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:44:51 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:44:51 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:44:51 services.cpp:530:StartAllSsd(): Try to start cam[4]. Arrêt dans PuTTY par /var/packages/SurveillanceStation/scripts/start-stop-status stop Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[1]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[2]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[3]. Apr 19 13:50:41 services.cpp:573:StopAllSsd(): Try to stop cam[4]. Apr 19 13:50:41 ssd.cpp:187:main(): Cam[2]: Signal! Stop ssd. Apr 19 13:50:41 ssd.cpp:187:main(): Cam[4]: Signal! Stop ssd. Apr 19 13:50:41 ssd.cpp:170:main(): Cam[1]: Signal! Stop retry init(). Apr 19 13:50:41 ssd.cpp:187:main(): Cam[3]: Signal! Stop ssd. Apr 19 13:50:44 vsctrld.cpp:109:main(): Stop vsctrld. Apr 19 13:50:45 ssrotated.cpp:695:main(): Stop ssrotated. Apr 19 13:50:46 ssfindhostd.cpp:49:SSFHOSTDExit(): Stop ssfindhostd. Apr 19 13:50:47 services.cpp:655:Kill(): [sscmshostd] is not running. Apr 19 13:50:47 sscored.cpp:167:main(): Stop sscored. Le fichier /var/packages/SurveillanceStation/enabled n'est pas supprimé Démarrage dans PuTTY par /var/packages/SurveillanceStation/scripts/start-stop-status start Apr 19 13:52:44 sscored.cpp:109:main(): Start sscored. Apr 19 13:52:45 ssrotated.cpp:658:main(): Start ssrotated. Apr 19 13:52:45 ssfindhostd.cpp:266:main(): Start ssfindhostd. Apr 19 13:52:45 vsctrld.cpp:48:main(): Start vsctrld. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[1]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[2]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[3]. Apr 19 13:52:45 services.cpp:530:StartAllSsd(): Try to start cam[4]. Conclusion : exception faite du /var/packages/SurveillanceStation/enabled qui n'est modifié qu'à partir du paquet, les logs sont identiques quel que soit le mode d'activation ou de désactivation de la surveillance. A noter toutefois une légère difficulté à arrêter la cam 1. C'est simplement dû à un problème de connexion sur cette caméra que je dois encore régler. Les logs étant identiques, je me suis dit qu'il suffisait alors de modifier le script start-stop-status pour y intégrer la suppression ou la création du /var/packages/SurveillanceStation/enabled En me servant des instructions proposées par Fravadona, j'ai rajouté les lignes suivantes : start() { if [ ! -f $PACKAGE_ENABLED ]; then exit 0; fi # Lignes rajoutées pour restitution du Enabled /bin/touch /var/packages/SurveillanceStation/enabled /bin/chmod 3377 /var/packages/SurveillanceStation/enabled stop() { RemoveWebapiLink # stop services ${SCRIPTS_DIR}/S82surveillance.sh stop # remove index and help entry ${DSM_INDEX_DEL} ${PKG_APP_PATH}/index.conf ${PKG_INDEXDB_PATH}/appindexdb # Lignes rajoutées pour suppression du Enabled /bin/rm /var/packages/SurveillanceStation/enabled En passant par PuTTY, /var/packages/SurveillanceStation/scripts/start-stop-status stop supprime bien /var/packages/SurveillanceStation/enabled mais malheureusement /var/packages/SurveillanceStation/scripts/start-stop-status start ne fonctionne pas et ne recréé pas le fichier enabled. Et en passant par Surveillance Switch, l'activation et la désactivation fonctionnent, mais contrairement à ce que je pensais au départ, cette appli n'utilise pas /var/packages/SurveillanceStation/scripts/start-stop-status pour activer ou désactiver la surveillance. Je n'arrive pas à comprendre comment cette appli fonctionne. Autre constatation très surprenante avec Surveillance Switch : quel que soit le status de Surveillance Station dans le DSM (activé ou arrêté), l'activation et la désactivation se fait sans problème, les caméras détectent les mouvements et enregistrent les séquences, et le NAS envoi les notifications comme si Surveillance Station était en opération alors qu'il est arrêté pour DSM et donc inaccessible ! Donc pour le moment, si je ne veux pas que Surveillance Station soit activé au démarrage du NAS, je doit arrêter le paquet dans le DSM. Dans ce cas, les sauvegardes automatiques peuvent se faire sans que Surveillance Station se lance. Si je veux lancer la surveillance, je peux utiliser le module de contrôle de l'alim du NAS dans Surveillance Switch pour démarrer le NAS, puis activer la surveillance. Les enregistrements se font, je reçois les notifications, mais je n'ai aucun accès possible à Surveillance Station soit par DSM et encore moins par DSCam pour pouvoir lire les enregistrements. Ce n'est pas vraiment satisfaisant comme mode de fonctionnement et certainement pas très orthodoxe, mais mes connaissances en Linux étant quasi inexistantes, je suis bloqué.

Merci Fravadonna pour ces éléments de réponses. Je vais regarder tout ça. J'ai bien vu le enabled dans le suveillance station et en le supprimant, SS ne peut pas démarrer. Mais le problème, c'est que Surveillance Switch est alors incapable de démarrer SS et reçoit même des infos contradictoires du nas qui lui dit que les caméras sont activées alors que le paquet SS n'est pas démarré ! Pour que Suveillance Switch puisse fonctionner, il faut que SS soit démarré. Il doit ensuite probablement utiliser /var/packages/SurveillanceStation/scripts/start-stop-status pour arrêter ou démarrer SS. Mon idée, c'était de laisser démarrer SS et de lui envoyer un cron dépendant du jour et de l'heure et de la condition du démarrage (soit auto, soit manuel ou wol) et du temps d'activité (si le nas était en opération avant le cron de démarrage auto pour la sauvegarde, c'est que Surveillance Station est en opération) pour arrêter ou non SS. Je vais étudier tes propositions (pas tout de suite car je suis occupé) et je reviens vers toi dès que possible.

Personne n'a une petite idée ?

A quoi bon avoir un réseau Gb pour le freiner avec du wifi. Les liaisons wifi sont très loin d'offrir des débits suffisants pour permettre des transferts convaincants. Mais vous jugerez par vous-même.

Si vous montez vos disque en basic, l'onduleur n'est pas indispensable. Pour le switch Gb, tout dépend de votre installation mais il vous faut un réseau Gb pour ne pas brider les échanges NAS - PC. Si votre box est en Gb, nul besoin d'un switch supplémentaire, sauf pour étendre votre réseau. Avec un box en 100Mb, je vous conseille vivement de mettre un switch Gb. Vous pouvez créer des raccourcis et/ou des favoris dans DSM à partir de file station. Une fois que vous aurez mappé vos disques, vous pourrez aussi créer tous les raccourcis que vous voudrez sur votre PC ou MAC.

Syno confirme bien que le NAS a un défaut. Leur réponse ne me surprend pas. Il est normal de se tourner vers le revendeur plutôt que le constructeur. Normal aussi que le constructeur prenne le pas et assure le remplacement en cas de défaillance du revendeur.

Pour le Raid 0 ou JBOD vous avez raison : si un disque lâche, vous perdez tout. En raid1 si un disque lâche, les données sont toujours dispos sur le disque sain. Il suffit de remplacer le disque défectueux par un neuf de capacité au moins équivalente, puis de reconstruire le raid pour retrouver un raid opérationnel. Pour le basic, je ne comprends pas bien votre question. Si vous créez deux disques en basic, vous perdez toutes les données contenues dans le disque qui tombe en panne. Si vous ne montez qu'un disque, vous pouvez choisir de le monter en basic mais ce n'est pas une obligation. Vous pouvez choisir de le monter en raid à un disque et vous construirez votre raid plus tard. Dans tous les cas de figure, il faut impérativement avoir une sauvegarde périodique des données les plus importantes soit sur un disque externe, soit sur vos pc, soit avec un autre nas, soit avec une solution externalisée. Edit : si votre choix est de faire un RAID0, alors oui vous ne pourrez pas le créer ultérieurement si vous ne mettez qu'un disque au départ.

Non, ce n'est pas applicable à toutes les box. Sur la Freebox V5 le switch est en 100Mb alors que nos nas et les PC actuels sont en Gb. Mais s'il y a d'anciens équipements en 100Mb, ils peuvent être connectés sur la Freebox puisqu'ils ne gagneront rien à être sur un switch Gb. La V6 (Freebox Revolution) est en Gb.

Décidément, cette 5.0 donne du fil à retordre à ceux qui ont eut la mauvaise idée de s'y aventurer. Avez-vous vérifié les droits ? Peut-être faudrait-il les redéfinir.

Si vous avez personnalisé votre NAS, la sauvegarde de configuration n'en tiendra pas compte. Quand à cloner le disque, je n'ai pas encore vu quelqu'un réussir à le faire. Mais comme vous le dites, attendez d'autres avis.

Je viens de comprendre pourquoi le paquet redémarre tout seul au démarrage du NAS. En fait, si SS est arrêté à partir de Surveillance Switch, il n'est pas vraiment arrêté en tant que paquet comme il le serait à partir de DSM. Il est toujours en opération dans le centre des paquets. Si bien que le redémarrage du NAS redémarre le paquet SS. Si par contre le paquet est stoppé dans le DSM, SS ne redémarre pas, ce qui est tout de même plus logique. Le hic c'est que Surveillance Switch est aveugle et peut donner une info "détection active" alors que le paquet est arrêté dans DSM. Il n'est pas capable de redémarrer SS. Il faut donc que SS soit en opération pour pouvoir avoir le contrôle depuis l'extérieur. D'où le besoin de pouvoir recréer la séquence d'arrêt une fois le NAS démarré et la positionner au bon endroit. Pas simple.

Dans ce cas, c'est plus compliqué. Vos disques sont donc 2 volumes en raid à 1 disque (pseudo basic à la mode Synology). Vous pourriez éventuellement construire votre raid en remplaçant le disque 2 par votre nouveau disque, mais je ne suis pas sûr ensuite que vous puissiez déplacer le disque 2 dans la baie 1 et ensuite étendre votre volume à 4To et recréer un raid à 1 disque. La seule solution qui me paraisse envisageable est la suivante : sauvegarde de la configuration mise en place du nouveau disque dans la baie 1, installation du DSM et création du volume restauration de la configuration et enfin transfert de vos données en 2 étapes : premier lot issu de votre volume 2 réinstallation de l'ancien disque dans la baie 1, nettoyage du volume 2 et copie des données non sauvegardée réinstallation du nouveau disque dans la baie 1 et copie des données restantes réinstallation de l'ancien disque dans la baie 1 et suppression du volume 1 réinstallation du nouveau disque dans la baie 1 et de l'ancien disque dans la baie 2 création du volume 2 et création de vos sauvegardes entre le volume 1 et le volume 2 Maintenant, vous aurez sûrement d'autres avis. Par exemple, il est peut-être possible de mettre votre volume 1 actuel dans la baie 2, de modifier son numéro et de recréer un volume 1 sur le nouveau disque installé dans la baie 1. Mais je n'en sais rien car je n'ai jamais fait ce genre de manip. Bonne chance et surtout beaucoup de patience.

On peut aussi voir les choses différemment, surtout si comme le souligne domlas on assure une sauvegarde irréprochable derrière. Le raid offre un gros avantage par rapport au basic c'est qu'en cas de perte d'un disque, on n'a pas à refaire tout de A à Z. Il suffit de remplacer le disque défectueux pour reconstruire le raid et tout ça sans que l'utilisateur n'ait eu d'interruption de service. Bien sûr, les disques sont beaucoup plus sollicités du fait des travaux de mirroring, mais déjà il ne faut pas prendre des disques type bête de course qui font plus de mal au portefeuille qu'ils ne font de bien au NAS (inutile un 7200tr alors qu'un 5900tr est largement suffisant). Et il faut faire un raid en toute connaissance de cause sur les possibles pannes qui peuvent résulter d'une hyper activité des disques. Pour moi, la facilité l'emporte sur l'économie. Et jusqu'à présent, je n'ai pas eu de problème avec mes raid.

A mon avis, le nas n'est pas en cause. C'est plutôt le joyeux mélange entre les 100Mb et les 1Gb qui pose problème. Déjà, le simple fait d'utiliser le switch de la FB vous fait perdre l'avantage du Gb, et notamment pour le PC3. Vous améliorerez sensiblement la qualité de votre réseau en ne connectant que votre switch sur la FB qui ne serait utilisée que comme passerelle internet et serveur DHCP, et le NAS et les PC sur le switch. La seule liaison qui fonctionne correctement sur votre réseau et celle qui est entièrement en Gb, NAS - PC1

Personne pour m'aider ? Mon problème actuel dans un premier temps est de savoir comment SS est démarré automatiquement au démarrage du NAS, par quelle séquence afin de pouvoir intervenir soit pour inhiber son démarrage, soit pour lancer un ordre d'arrêt.

Pour commencer, quel est le modèle de nas ? Qu'est-ce que vous appelez votre disque système, car le DSM est installé sur tous les disques du NAS. Question accès disque hors NAS, vous ne pourrez pas faire grand chose avec votre PC parce que le système du NAS est du Linux en ext4 qui est du charabia pour votre PC. Il faut passer par une distribution Linux comme par exemple Ubuntu que vous pouvez faire tourner sur votre PC avec un CD. Enfin, il est normal que vous trouviez 4 partitions puisque c'est le formatage normal des disques des Syno.

Ce n'est qu'un tout petit fichier qui ne sauvegarde rien d'autre que les paramètres du NAS. Issu de l'aide : Sauvegarde de configuration La page Sauvegarde de la configuration fournit des options pour sauvegarder immédiatement les configurations système sur un ordinateur local. Ceci permet de sauvegarder divers paramétrages (par ex. les utilisateurs, les groupes, les paramètres de service de fichiers, etc.) et de les restaurer à une date ultérieure. Les configurations système sont sauvegardées sous forme de fichier .dss.

Je ne crois pas que ce soit faisable. On peut créer des multivolumes sur un raid, mais on ne peut pas utiliser la zone inexploitée d'un disque d'une grappe raid pour y créer un volume. Le seule issue c'est de changer le deuxième disque par un 4To pour étendre le raid existant.

Merci pour le lien. Je m'en étais inspiré pour la seule et unique ligne de mon script. C'est un copier/coller de l'instruction qui m'intéressait. Comme je le disais, le script fonctionne bien une fois le NAS démarré, mais n'a aucune incidence pendant le démarrage parce que ce maudit SS démarre plus tard.

SS est un paquet à part, et s'agissant de sécurité, j'imagine que ce comportement est normal, même s'il n'arrange pas mes affaires. Merci d'avoir essayé de m'aider.

Et non StéphanH, sinon ce serait trop simple et je ne serais pas là à poser des questions ! Même si SS est désactivé, le redémarrage du NAS redémarre SS. Je n'ai pas vérifié pour les autres paquets, mais pour celui-là, c'est sûr. SS est activé par défaut, sa désactivation n'est que temporaire. Il faudrait que je trouve le moyen d'inhiber ce démarrage mais je n'ai pas découvert où sévir.