Toutes les discussions

C’est bon, les MAJ PHP sont maintenant proposées sur mon NAS (DSM 7.3.2 update 5).

Tu peux télécharger les paquets mis à jour dans le centre de téléchargements de Synology (fichiers .spk) et faire une installation manuelle dans le centre de paquets sur le NAS

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.

Me concernant DSM (7.3.2) ne m’indique rien. Ni pour php 8.2 ou php 8.4 🥺 Pour l’instant j’ai coupé Synology Calendar et Mail Station (seuls paquets utilisant php sur mon DS418).

Merci , MAJ faite

Synology vient de sortir une mise à jour pour php 8.2 la 8.2.35-0171

Bonjour Merci pour l'info mais comment savoir quels services ou applications utilisent php ?

Bonjour, Des vulnérabilités critiques de PHP ont été découvertes et révélées hier, affectant peut-être 70% du Web mondial. Pas mal de sites gouvernementaux ont été mis à l'arrêt dans l'attente de correctifs. Je n'ai pas vu de correctif de sécurité pour les paquets PHP de Synology dans DSM. Doit-on aussi mettre ses sites web en pause? Merci pour vos avis et informations.

Bonjour à tous, Je suis étonné de ne rien voir à ce sujet, mais une faille extrêmement critique concernant PHP (php2shell) a été révélée. Synology utilise activement PHP pour l'ensemble de ses services. Tant que Synology ne publie pas une version patchée de leur paquet PHP, il est hautement recommandé de s'assurer que vos services ne sont pas directement accessibles depuis Internet. Même chose pour vos conteneurs docker s'ils utilisent PHP et qu'ils sont exposés sur le net. Je ne trouve pas de communication officielle (de la part de Synology) concernant ce sujet à mettre en source, mais c'est réel.

Bonjour, Si c'est bien Home Assistant OS qui tourne dans la VM, le plus simple est le module complémentaire officiel "Samba share" : Paramètres > Modules complémentaires > Boutique des modules complémentaires. Dans son onglet Configuration, il faut renseigner un identifiant et un mot de passe, puis le démarrer. Ensuite dans le Finder, Cmd+K puis smb://homeassistant.local (ou smb:// suivi de l'IP de la VM, pas celle du DS218+). On y retrouve les partages config, backup, media, share, etc., le dossier config contenant configuration.yaml et toute l'arborescence HA. Si le Mac se connecte depuis un autre sous-réseau (par exemple à travers le tunnel OpenVPN), il faut l'ajouter dans la liste allow_hosts du module, sinon la connexion est refusée.

Bonjour, Je fais tourner HomeAssistant sur une VM hébergée sur un DS218+. Tout fonctionne. Je cherche toutefois à accéder aux fichiers de l’arborescence HA depuis le Finder de mon Mac, en SMB. Comment faire ? Merci !

AURORA est une médiathèque personnelle auto-hébergée sur Synology DSM 7, accompagnée de lecteurs Android TV et macOS natifs. Aucun service cloud, abonnement ou compte externe n'est requis pour utiliser la médiathèque . bibliothèques films/séries par dossier, collections, favoris et liste à voir ; indexation incrémentale, métadonnées TMDB et affiches mises en cache ; profils, contrôle parental, progression et reprise multi-appareils ; Direct Play prioritaire, remux, puis conversion H.264/HLS si nécessaire ; pistes audio, sous-titres, chapitres et épisode suivant ; association d'un appareil par code sur http://<nas>:8890/link; administration, diagnostics, sauvegarde et restauration sur le NAS. c'est open source: https://github.com/Charly2B/AURORA Vos avis sont les bienvenues pour améliorer mon application. Merci

Bonjour, Lotte Jansen, 33 ans, dispose de plusieurs NAS Synology (918+ et 1821+) pour un usage personnel et professionnel, qu'il utilise notamment pour la vidéosurveillance avec Surveillance Station, les sauvegardes et diverses autres fonctions.

Bonsoir, merci pour le retour sur mes questions réseau initiales => voilà où j'en suis: 1) trame jumbo: parmi les ordis sur mon réseau j'ai un très vieil appareil, que je suis obligé de conserver à cause de certains logiciels qui ne fonctionnent pas sous des versions récentes (et qui malgré leur âge me rendent encore beaucoup de services). Comme le MTU maxi de la carte réseau de cet appareil est limité à 7000, tous mes autres appareils sont configurés avec cette valeur, qui n'a jamais posé de problème auparavant et n'en pose pas actuellement aux autres appareils, y compris le 425+, auquel ils accèdent sans problème. 2) ports réseau du 415+: un seul est branché; j'ai essayé d'utiliser l'autre à la place mais ça n'a rien changé au problème. Par contre en comparant écran par écran (du moins pour ceux qui se retrouvent à l'identique sur le 415+ et sur le 425+) les paramètres réseau, j'ai constaté que sur le 415+ la case "Activer par défaut" de l'item "IP V6" était cochée. Je ne sais pas pourquoi, car je ne suis pas concerné par cette adressage => je l'ai dé-cochée (comme c'est le cas sur le 425+), mais je n'ai pas l'impression que ça change grand chose puisque j'ai quand même eu un freeze d'accès à ce serveur depuis. 3) contrôle de flux: là, avant de tester, j'ai quelques questions: - si je le désactive sur le vieil ordi, cela ne risque-t-il pas de masquer certaines erreurs qui pourraient survenir pendant le transfert de fichiers avec le 415+ comme avec le 425+? - le réseau fonctionnera-t-il normalement si ce paramètre est désactivé sur le vieil ordi mais reste activé sur tous les autres?

Bonjour, Pour ta question du 7 octobre sur le panneau Réseau, que j'avais laissée de côté : dans Panneau de configuration > Réseau > Interface réseau, je modifierais LAN 1 (et LAN 2) pour vérifier deux choses. La trame Jumbo d'abord. La config venant du 411+II, le MTU est peut-être à 9000 alors que ton switch ou ton ordi sont à 1500. Ce genre de décalage donne justement des transferts qui se figent quelques secondes, plus en écriture qu'en lecture. Dans le doute, repasse à 1500 pour le test. Ensuite, si les deux ports du 415+ sont câblés sans agrégation, ils ont chacun une IP sur le même réseau, et certains switchs ou ordis s'y perdent. Pour le test, je ne laisserais qu'un seul câble branché. Enfin, comme internet ralentit aussi pendant ces gels, ça peut venir du contrôle de flux (trames pause) que certains switchs non administrables appliquent à tous les ports. Il se désactive dans les propriétés avancées de la carte réseau de l'ordi concerné.

@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 !

Bonjour, Puisque vous n'avez que 2,7 To de données, il y a peut-être une option intermédiaire avant de changer de NAS : sauvegarder le tout sur un disque USB externe avec Hyper Backup, mettre directement les quatre 14 To, puis recréer un groupe de stockage neuf en choisissant l'option qui autorise plusieurs volumes. En SHR, ça donne un peu plus de 38 To utiles dans DSM, que vous pouvez découper en trois volumes (16 + 16 + le reste). Vous dépassez ainsi vos 30 To sans buter sur la limite par volume, et il ne reste qu'à restaurer depuis le disque USB. Ça évite aussi quatre reconstructions successives sur des disques de 14 To, qui prendraient plusieurs jours chacune avec ce processeur. Le revers, c'est que vos dossiers partagés seront répartis sur plusieurs volumes, et la remarque de Mic13710 sur l'âge du NAS reste valable : ça repousse le remplacement, ça ne l'évite pas.

Merci @jeremyc pour ces explications. N'étant pas programmeur ou développeur je n'aurais pas trouvé tout seul.

Bonjour, Pour les lignes du log, rien d'inquiétant. Elles viennent de la boucle de renouvellement d'acme.sh, qui parcourt le contenu de /acme.sh avec deux motifs, *.* et *:*, et ignore tout ce qui n'est pas un dossier de certificat. account.conf, acme.sh.log ou http.header correspondent à *.*, d'où les « Not a directory, skipping ». Le *:* est voulu : il sert aux certificats émis pour une adresse IPv6, dont le nom de dossier contient des deux-points. Quand il n'y en a aucun, le shell laisse le motif tel quel et le script l'ignore aussi. Quant à errorlevel='3' setlevel='2', ça veut dire que tous les certificats ont été sautés parce qu'ils ne sont pas encore à renouveler (niveau 3), et que les notifications d'acme.sh ne partent qu'en cas de renouvellement ou d'erreur (niveau 2). Donc rien n'est envoyé de ce côté, et ça n'a rien à voir avec l'arrêt quotidien du conteneur.

Merci pour votre retour et vos conseils. J’ai justement effectué ces vérifications depuis mon dernier message : Conseiller en sécurité : analyse complète effectuée. Tous les contrôles de sécurité sont au vert, aucun logiciel malveillant ni anomalie détectés. Seules quelques mises à jour de paquets étaient signalées. Utilisateurs DSM : liste vérifiée, aucun compte inconnu. Les comptes admin et guest sont désactivés, et mon compte principal est protégé par la double authentification. Planificateur de tâches : vérifié également. Il ne contient que deux tâches Hyper Backup connues, dont une désactivée. Paquets, conteneurs et processus : vérifiés, rien de manifestement suspect. Connexions actives : uniquement des connexions locales lors du contrôle.

Bonjour, Content de voir que ça tient depuis neuf jours. Vu le volume de tentatives, je ferais quand même une vérification avant de rouvrir quoi que ce soit : un scan complet avec le Conseiller en sécurité, puis un coup d'œil à la liste des utilisateurs et au Planificateur de tâches pour repérer un compte ou une tâche que vous n'auriez pas créés. Le journal ne garde pas tout indéfiniment, donc "aucune connexion réussie" ne vaut que pour les événements encore conservés. Ensuite, si vous avez besoin d'accéder au NAS à distance, passer par un VPN (VPN Server sur le NAS ou Tailscale) permet de laisser toutes les redirections de la Livebox fermées.

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.

Au 17/10/26 le NAS affiche plus de neuf jours de fonctionnement continu, sans le moindre blocage depuis qu'il est isolé de l’extérieur En examinant les journaux DSM, j'ai découvert un nombre très important de tentatives de connexion provenant d'Internet. L'export CSV du journal de connexion contient 8960 événements : 8 926 tentatives extérieures refusées ; 1 281 adresses IP publiques distinctes ; aucune connexion extérieure réussie détectée dans les événements conservés. Les tentatives utilisaient de nombreux identifiants différents Le volume était particulièrement important les 5 et 6 octobre, avec respectivement environ 2 700 et 4 600 tentatives refusées. Depuis la fermeture des accès extérieurs le 8 octobre, les connexions visibles dans les journaux proviennent uniquement du réseau local. Actuellement Comptes admin et guest désactivés. Compte administrateur temporaire utilisé pour les investigations SSH à nouveau désactivé. Double authentification active sur mon compte principal. Service SSH désactivé Voila le pourquoi du comment je suppose .... Misère ça fait peur 😨 Donc je vais relire et appliquer le tuto de sham comme me l'a dit Mic13710 https://www.nas-forum.com/forum/topic/77493-tuto-pas-%C3%A0-pas-s%C3%A9curisation-du-nas-pour-dsm-7/page/9/#comment-1319530999 A votre avis je dois faire quelque chose d'autre ? merci encore pour vos conseils

Je viens de remplacer la pile : aucun changement (clignotement bleu sans rien ensuite) J'ai tenté par hasard une barrette de RAM : aucun changement non plus... ...et j'ai du coup retiré le microcontrôleur (DS1512-R1 DSM4.1 2660)... et c'est un USBest, sans surprise ! ;) Bref, je peux farfouiller ebay et autres, haha ! (sauf si quelqu'un en vend par ici) EDIT : du coup, question bête, mais quelqu'un a le matériel et peut faire le fameux changement de USBest UT165-L48 ? :D

Bonjour, Avant de le mettre de côté, un test qui ne demande aucune soudure : débranche tout, retire la pile bouton de la carte mère une dizaine de minutes, puis remets-la et redémarre sans disque. Après une coupure de courant, un BIOS mal réinitialisé peut donner exactement ce clignotement bleu sans que la LED status s'allume. Si ça ne change rien, ce serait plutôt la puce flash qui contient le système de démarrage, et là ça devient vite compliqué sans outils. Une carte mère de 1512+ d'occasion resterait alors l'option la plus simple pour en refaire un NAS de backup.