Mic13710

Aucune idée sur ce fichier. A mon avis, il n'a rien à faire ici. Le déplacer ne devrait pas avoir d'incidence, ce n'est pas un fichier système. L'agrandissement de la partition système en conservant la partition des données suppose qu'on remplace les disques par des plus gros sous dsm 7.x. Les partitions mises en places sont alors en 7.9Go mais pour les exploiter, il faut réinitialiser DSM.

@jeremyc , ce n'est pas un problème de date de version. La branche 7.0.1 a beau être plus ancienne que le dernier update de la 6.2.4, la 7.0.1 reste la version la plus récente. Les updates ne sont que des patchs, pas des versions complètes. D'ailleurs Synology donne bien la 7.0.1-42218 comme première version de mise à jour de la 6.2.4-25556. L'update 7 n'a aucune incidence car c'est sur la version de base de la branche que se fait la mise à jour. Et le passage direct à la 7.2 (ou la 7.3 ou 7.4) est impossible sans passer d'abord par la 7.0.1. Par contre, je suis d'accord pour dire que la partition système est probablement chargée et qu'il faut faire du nettoyage avant de lancer la mise à jour.

Directement dans le centre des paquets, ça marche aussi 😉

J'ai été écouté 😄 Les mises à jour des versions plus anciennes arrivent. Je viens de faire une maj de PHP7.4 sur un DS214+

Sur le site php, les mises à jour ne commencent qu'à la 8.2. Les versions inférieures n'ont pas de mise à jour. Peut-être un jour ...

Il y a bien une nouvelle version Synology MailPlus 4.1.1-22335 du 20/10/2026 qui est proposée en téléchargement décalé alors que les versions de PHP et de calendar l'ont été en (quasi) immédiat. La note pour l'avertissement de sécurité Synology-SA-26:14 PHP2Shell ne liste pas MailPlus : https://www.synology.com/fr-fr/security/advisory/Synology_SA_26_14 Ce qui m'inquiète plus ce sont les versions PHP des NAS plus anciens (séries 13 à 15) sous DSM 7.x qui n'ont pas de maj. S'agissant de vulnérabilités critiques, j'espère que synology va proposer des mises à jour pour ces NAS, y compris pour les versions PHP obsolètes qui tournent encore sur ces NAS.

Merci pour l'info. Après avoir écrit mon message, je me suis rendu compte que je faisais fausse route. Pourquoi diable je suis allé sur le lien php ? Mystère. Je viens de me reconnecter et les mises à jour des php sont maintenant proposées dans le centre des paquets ainsi que synology calendar. Maj des php effectuées mais impossible de télécharger synology calendar dans le centre des paquets. Trop de téléchargements peut-être ? J'ai téléchargé via le site et c'est passé.

Pas seulement php8.2. Il y a aussi la 8.3 et la 8.4 qui ont une mise à jour en ligne aujourd'hui. Par contre, ces maj n’apparaissent pas encore dans mon centre des paquets et je ne sais pas quel fichier télécharger. Le lien Synology renvoie vers la page Php : https://www.php.net/ChangeLog-8.php#8.2.35 Il y a deux fichiers possibles et quand on ouvre l'un ou l'autre, on tombe sur une page pas très clair pour un néophyte et qui ne comporte aucun téléchargement pour une installation manuelle. Je n'ai pas non plus trouvé la marche à suivre chez Synology. Si quelqu'un peut me dire comment mettre à jour php sur un NAS Synology à partir du site php, ce serait sympa et ça pourrait aider d'autres membres.

@jeremyc , certes, mais le fait de monter des 14To et de créer plusieurs volumes dans le 814 ne va pas dans le bon sens. Augmenter le stockage ne fera que compliquer un peu plus la migration des données vers un nouveau NAS du fait de l'augmentation des données. La gestion de multi volumes n'est pas non plus très facile (gestion et répartition des dossiers partagés entre volumes) Autre point critique, DSM n'est plus mis à jour, idem pour les applications. Selon l'utilisation qui est faite de ce NAS et son degré d'exposition vers l'extérieur il deviendra vulnérable. Je pense que quitte à investir dans des disques de 14To qui coûtent déjà une blinde, on peut y rajouter un NAS et repartir sur un ensemble à jour. Après, on peut se poser la question d'un basculement soudain d'un groupe en 1To vers une groupe en 14To. Passer de 3To à 42To, ce n'est pas anodin. Pourquoi une telle augmentation ? Même si le stockage existant est arrivé en bout de course au fil du temps, il faut avoir un sacré volume de données nouvelles à stocker d'un coup pour multiplier le groupe par 14 !

Si ces attaques proviennent de sources étrangères (Russie principalement mais pas que...), vous pouvez faire un blocage géographique dans le pare feu. Si vous ne vous connectez qu'à partir de la France, vous pouvez n'autoriser que les seules connexions venant de France. Attention toutefois de ne pas tout bloquer. Les USA (bien qu'ils soient devenus un état voyou de mon point de vue) doivent être conservés si vous avez un nom de domaine en propre pour le renouvellement du certificat chez Let's Encrypt. Vous pouvez dans ce cas, n'ouvrir l'accès que lors de la période de renouvellement mais ça va vite devenir fastidieux. Vous n'empêcherez pas les tentatives de connexion qui persisteront jusqu'à épuisement du bot à l'origine des attaques. Il est difficile de ne pas connecter un NAS sur l'extérieur pour des raisons évidentes d'utilisation à distance. Cependant, les outils proposés par DSM permettent une bonne protection contre les tentatives malveillantes. L'analyse de l'origine des attaques vous permettra de mieux cibler ce qu'il faut bloquer. Une excellente manière de protéger son réseau c'est d'installer un routeur digne de ce nom. Les protections intégrés sont alors plus complètes que celles proposées par les box des opérateurs où elles sont quasi inexistantes. Le filtrage se fait alors en amont du réseau et donc du NAS sans pour autant abandonner les moyens de protection de ce dernier qui doivent continuer de protéger le NAS (pare feu, blocage des tentatives de connexions échouées, DOS, etc..). Par exemple, mon routeur (voir ma signature) bloque la grande majorité des IP malveillantes dès leurs tentatives ce qui soulage le NAS. Le nombre de blocages du routeur par minute est absolument impressionnant. Un toutes les deux à trois secondes venant de tous pays : USA, Bulgarie, Canada, France, Russie, Roumanie, Pays-Bas, Pakistan, Philippines, Allemagne, Argentine, Angleterre, Brésil juste pour les deux dernières minutes. Ce sont pour la grande majorité des bots qui balayent le web à la recherche de cibles.

Pour l'alim, c'est peut-être une capacité HS. Voir cette vidéo : https://www.youtube.com/watch?v=sJsAgQtfoVo Autre solution avec une alimentation atx sur un 1815+. Le gars n'est pas très clair mais ça semble fonctionner : https://www.youtube.com/watch?v=NWH0ZOCyW8s&t=182s Il y avait aussi un sujet assez ancien sur le forum avec une alim ATX mais je ne le retrouve pas.

La seule migration envisageable vers un modèle récent serait de partir sur un ensemble NAS disques neuf et de procéder au transfert des données via hyperbackup. Surtout pas de migration des disques qui importerait toutes les limitations de votre groupe actuel et notamment la limite des 16To par volume. Si vous trouvez une unité d'extension RX 4 baies compatible d'occasion à bon prix, pourquoi pas l'envisager mais votre NAS est ancien (12 ans) et ne peut plus recevoir de mises à jour de DSM. Rajouter une extension ne ferait que retarder le remplacement à plus ou moins brève échéance.

Si vous avez suivi le tuto à la lettre, c'est normal. Avec cette tâche planifiée, docker acme est stoppé, supprimé puis recréé. docker pull neilpang/acme.sh:latest docker stop Acme docker rm Acme docker image prune -f docker volume ls -qf dangling=true | xargs -r docker volume rm docker run -d --cpu-shares=10 --memory=134217728 --name=Acme -v /volume1/docker/Acme:/acme.sh:rw --restart unless-stopped neilpang/acme.sh:latest daemonCette tâche est à mon avis totalement inutile, surtout avec container manager où la mise à jour du docker se fait beaucoup plus simplement que par le passé. Si vous n'avez pas Container Manager, vous pouvez toutefois le conserver mais supprimez le lancement quotidien. Vous le lancez manuellement une fois par mois par exemple, c'est largement suffisant. Je rappelle que ce renouvellement quotidien ne sert qu'à la mise à jour du container, pas du script acme.sh qui lui est vérifié tous les jours par le script lui-même et mis à jour automatiquement.

@PiwiLAbruti Un très beau déterrage ! Il a fallu allez le chercher trèèès loin dans le forum pour l'exhumer. Oui, volume maxi 16To par volume mais la spec parle aussi de 256 volumes internes. Pour que ce soit possible il faut que le groupe soit construit en multi volume. Selon votre version de DSM et surtout si le montage du groupe est monté en SHR, il est possible de le faire à posteriori et sous certaines conditions et pour certains modèles de NAS sans détruire le groupe existant. Si c'est un RAID 5, ce n'est pas possible sans tout reconstruire. Conversion d'un volume en groupe de disques | DSM - Synol...Le Centre de connaissances de Synology offre une assistance complète, fournit des réponses aux questions fréquemment posées, des étapes de dépannage, des tutoriels logiciels et toute la documentationVotre problème c'est que tous les rack de votre NAS sont utilisés, ce qui ne permet pas une augmentation du stockage par ajout de disque. Je ne sais pas s'il est possible de le faire en procédant au changement de 2 disques et plus. Et je ne peux pas vous dire si le RS414 autorise le passage de volume unique en multi volume sans reconstruction du groupe.

Je ne pense pas non. Vos problèmes de disques ne sont pas liés à la sécurité mais ça vous permettra de vous affranchir de quickconnect et de remettre à plat vos paramétrages.