PiwiLAbruti

Les logs ne sont effectivement pas très explicites 😕 Essaye de voir directement avec le support Synology : https://www.synology.com/company/contact_us Ils prendront probablement la main à distance pour résoudre le problème.

Rien d'anormal, la partition /dev/root a suffisamment d'espace disponible pour installer la mise à jour. Les logs peuvent être affichés avec la commande : cat /var/log/synoupdate.log Essaye aussi en arrêtant tous les paquets avant de lancer la mise à jour.

Ouvre une session SSH sur le DS214se, et poste ici le résultat de la commande suivante pour voir le taux remplissage des différentes partitions. df -h

Pour les lister la taille des dossiers partagés de chaque volume, la commande du sera plus précise : sudo du -hd1 --exclude=@* /volume* 4.0M /volume1/web 12G /volume1/homes 8.1G /volume1/sync 1.7T /volume1/backup 1.7T /volume1

Dans ce cas, il ne reste plus qu'à ouvrir un ticket auprès du support Synology : https://www.synology.com/fr-fr/company/contact_us

Le problème est bien visible à la ligne Advertised link modes qui indique que le 1000BaseT/Full n'est pas annoncé alors qu'il est bien supporté (Supported link modes). Pour comparaison, voici ce que retourne un DS213j : $ sudo ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: No Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Half 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yes Il y a aussi la ligne Advertised auto-negociation qui est différente. ⚠️ Je n'ai pas testé ce qui est indiqué ci-dessous, à tester à vos risques et périls. À voir s'il est possible de modifier la configuration avec la commande suivante (le mot de passe admin sera demandé) : sudo ethtool -s eth0 advertise 0x02f Vérifie le résultat avec la commande précédente (ethtool eth0). Manuel de la commande ethtool : https://linux.die.net/man/8/ethtool Explication de la valeur 0x02f (ajout du 1000BaseT/Full) : https://serverfault.com/questions/1076124/linux-link-speed-advertise

La commande est juste ethtool eth0

Peux-tu poster le résultat de la commande suivante ? (après avoir ouvert une session SSH sur le NAS) user@DiskStation:~$ ethtool eth0

Vérifie aussi que les 8 pattes à l'intérieur du port RJ45 du NAS sont correctement placées. Il suffit qu'une seule ne fasse pas contact pour que la connexion soit négociée à 100Mbit/s.

Les adresse 169.254.0.0/16 sont des adresses que les machines s'attribuent automatiquement en cas d'absence de serveur DHCP sur le réseau (comme le fe80::/10 en IPv6, sauf que la méthode de négociation est différente). Cela ne pose aucun problème. D'après tous les tests qui ont été faits, le problème viendrait du NAS Synology. Quelques autres tests : As-tu à disposition un box pour y connecter à la fois le NAS et un PC ? Le problème pourrait aussi venir du mode d'économie d'énergie des cartes réseau (802.3az), mais je ne pense pas que ce puisse être modifié depuis DSM. Sur un PC on le trouve dans les paramètres matériels de la carte réseau (Gestionnaire de périphériques sous Windows) et/ou dans les options d'alimentation. Essaye aussi en utilisant un câble plus long (ça peut sembler paradoxal mais ça peut modifier la puissance d'émission de la carte).

Oui. À voir si ton hébergeur permet d'en définir plusieurs, sinon il faudra en créer un avec un autres service (Synology en fourni un directement dans DSM). Ce n'est pas obligatoire. Il faut préciser dans la tâche de sauvegarde que le certificat ne doit pas être vérifié. En théorie oui, mais ça dépend des possibilités fournies par ton hébergeur.

Quels sont le(s) processus qui consomment du processeur ?

Avec Hyper Backup (source) et Hyper Backup Vault (destination). Ça dépend de ton fournisseur d'accès à internet (FAI). Avec le pare-feu (port tcp/6281 pour Hyper Backup Vault), en activant le chiffrement des connexions dans les tâches de sauvegarde, et en créant un compte dédié aux sauvegarde côté destination. C'est inutile si les conseils de la réponse précédente sont appliqués. https://kb.synology.com/fr-fr/DSM/tutorial/How_to_back_up_your_data_to_a_remote_Synology_NAS_or_file_server_with_Hyper_Backup

@alfoudam Si un serveur NTP est configuré, l'heure se règle automatiquement.

Pour relancer ce sujet concernant la reconnaissance d'objets, Synology a fait une mise à jour de Synology Photos le 25/07/2023 dont la notes de mise à jour pourrait laisser espérer une amélioration : La mise à jour n'est pas encore proposée en automatique sur mon NAS. Il existe aussi une version 1.5.0.0489 publiée aujourd'hui. Pour les plus pressés, vous pouvez l'installer manuellement. La fonctionnalité n'est pas activée par défaut, il faut l'activer dans Paramètres > Albums créés automatiquement > Activer l'album Sujets dans mon espace personnel. Attention : S'agissant d'une ré-indexation de toutes les photos, cela peut prendre beaucoup de temps et de ressources selon le nombre de photos et de la puissance du NAS.

Qu'indique le Moniteur de performances concernant la consommation de ressources du NAS ? Y a-t-il d'autres paquets qui consommeraient des ressources ?

Certains disent que Free attend que 100% des abonnements clients soient en IPv6 natif pour réactiver le rDNS aux clients ayant une adresse IP full-stack. Cependant je ne vois pas pourquoi ce ne serait pas possible dès maintenant. De toute façon il faudrait aussi une délégation de zone pour l'IPv6, et là on ne la verra pas de notre vivant.

Le DS115j (et plus exactement l'architecture armada370) était supporté jusqu'à la version 3.3.0-16975 (01/06/2021). La version suivante (3.4.0-18333 du 06/04/2022) indique clairement que l'architecture armada370 n'est plus supportée : Synology a fait du ménage fin mai 2023 et a supprimé toutes les anciennes versions des logiciels 🙄 Cependant, il existe encore un moyen de télécharger les anciennes versions : https://web.archive.org/web/20230117050711/https://archive.synology.com/download/Package/Spreadsheet/3.3.0-16975

Dans l'absolu ça ne me dérange pas qu'un constructeur utilise des technologies éprouvées bénéficiant souvent d'un support à long terme (LTS), c'est toujours plus stable que des technologies récentes. Mais il ne faut pas que ce soit au détriment de la sécurité comme dans le cas présent.

Je leur ai déjà fait un ticket sur les versions totalement obsolètes de PHP utilisées dans DSM et certains paquets. Je pense qu'il n'y a pas de QA chez Synology, ou alors ils sont sourds et aveugles.

Si seulement Synology pouvait utiliser des processeurs plus récents qu'un Celeron J4125 de fin 2019 (comme un Celeron J6412 de 2021 par exemple), ça permettrait de doubler la bande passante mémoire et d'avoir un contrôleur ethernet intégré 2,5GbE. https://ark.intel.com/content/www/us/en/ark/compare.html?productIds=197305,214758

Non, tu ne dis pas de bêtise :

Oui.

Pour information, le chemin /usr/local/bin contenant ffmpeg6 est déjà présent dans la variable $PATH : /sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin

PHP 7 est également obsolète : https://www.php.net/supported-versions.php