Foksadure

On trouve sur LBC des référence Crucial en ECC qui fonctionnent. J'ai pris une unique 16Go, laquelle est bien suffisante combinée aux 8Go d'origine du DS1522+ pour faire un peu de virtualisation.

La question est surtout de savoir quelle est la qualité du lien uplink entre les deux RT6600ax, s'ils sont connecté en Wi-Fi. Et combien de clients sont connectés sur le second RT6600ax lorsque l'anomalie de débit survient. Tout cela à voir dans Wi-Fi Connect -> Point d'accès Wi-Fi. Je trouve que le Wi-Fi fonctionne beaucoup moins bien sous SRM 1.3, en tout cas sur la génération précédente (RT2600ac et MR2200ac). L'uplink n'utilise plus le réseau 5 GHz-2 dédié, mais partage celui - le 5 GHz-1 - également utilisé par les clients compatibles. Et en plus on a perdu le fonction de test de performance qui était intégrée au SRM 1.2 justement pour identifier les soucis à ce niveau : https://kb.synology.com/fr-fr/SRM/help/SRM/WiFiConnect/wifi_mesh?version=1_2#t3 J'espère qu'ils vont corriger le tir.

Bonjour, Je ravive ce fil pour confirmer que les IronWolf "grattent" comme des disques d'il y a 10 ans, ce qui peut s'avérer gênant dans un environnement domestique. J'utilise un DS412+ avec un panachage de disques 4To Seagate et WD, lié aux augmentation successives de capacité. Les WD40EFRX et WD40EFZX sont inaudibles. Les ST4000VN008 vibrent nettement plus et leur activité d'I/O sont très nettement remarquables en comparaison, surtout parce qu'elle provoquent des résonances du boitier (découplage très partiel des disques à cause de la platine SATA arrière). Par curiosité, l'idée m'a pris de remplacer un des Seagate VN008 par le nouveau modèle ST4000VN006, qu'on trouve à moins de 100 euros (5400tr/mn, 256Mo de cache, 2 plateaux, hauteur 20,20mm). https://www.seagate.com/www-content/product-content/ironwolf/en-us/docs/100807039m.pdf Avec les 256Mo de cache et l'augmentation de la densité, on pouvait craindre que Seagate nous ait fait un produit "de crise" en SMR déguisé, mais il n'y a pas de problème lors de la reconstruction de la grappe RAID contrairement aux WD40EFAX. Il semble bien être CMR (tel qu'indiqué ici et dans la liste de compatibilité Synology). Cependant, le ST4000VN006 n'est hélas pas plus silencieux que le ST4000VN008 tout en chauffant plus : 31°C vs 24°C en idle. Il n'est pas non plus reconnu par le test de santé Seagate IronWolf intégré dans DSM depuis la v6.1. Donc en conclusion, AMHA, le petit gain en performance et en consommation ne vaut pas la chandelle tant qu'on trouve encore des ST4000VN008, qui sont vendus sensiblement au même prix.

Pour la petite histoire, le support WD m'a échangé les deux WD40EFAX que j'avais achetés avant l'annonce de Synology, par des WD40EFRX recertifiés. L'opération a nécessité 2 demandes de RMA anticipés successives, pour disposer d'un disque de rechange en tuilage. Ceci afin de de procéder à la reconstruction de la grappe SHR et d'effacer l'ancien disque avec l'outil de diagnostic DLGDIAG avant de le leur renvoyer. Le contact par chat en français fonctionne très bien pour préciser qu'il s'agit d'une demande de changement de référence, et ils sont manifestement au courant de la problématique DM-SMR vs CMR. 🤫

Personnellement, acquéreur de 2 x WD40EFAX début avril 2020 (oui, le timing était juste parfait !), et devant l'incompatibilité annoncée par Synology depuis, je suis en train de tenter de me les faire remplacer par le SAV WD. Je viens de lancer un premier RMA anticipé, plus un message au support. En effet, le délai de rétractation étant échu, le marchand ne me propose qu'un retour avec remboursement par avoir, sans vouloir me fournir deux disques 4To d'une autre référence en "tuilage" pour que je puisse préalablement transférer mes données. Ceci alors qu'ils ont du Seagate IronWolf exactement au même prix, mais soi-disant "moins performant". Bref. Cela dit, le NAS ne signale pas d'erreurs, et les données ne sont pas critiques. Mais outre la lenteur des opérations d'écriture remarquée lors de la double reconstruction du volume unique SHR, je trouve que les disques EFAX sont trop bruyants par rapport aux WD30EFRX et IronWolf ST3000VN007 avec lesquels ils cohabitent. On entend clairement l'activité disque, même si c'est moins pire que les vieux et increvables Samsung au son si caverneux qu'ils remplacent.

Question bête si le sujet est encore d'actualité : est-ce que DS412+ a été passé à 2Go de RAM ? Après avoir un peu galéré pour trouver une barrette compatible, le mien est devenu nettement plus réactif avec une Samsung M471B5773CHS-CH9 achetée €8 sur LBC. Bon moyen de faire encore durer une excellente machine.

Je ne sais pas si mi-2019 DownloadStation a été corrigé, mais pour info la limite de vitesse globale fonctionne très bien avec le package Transmission du site SynoCommunity. https://synocommunity.com/package/transmission

Aux dernières nouvelles, les arnaqueurs sont sur le point de disparaître dans la nature, non sans monnayer la base contenant les clés non encore réclamées : http://www.theregister.co.uk/2014/08/14/synolocker_trojan_closing_down_sale/ http://www.f-secure.com/weblog/archives/00002733.html Notons l'existence d'un service support (sic) et de la possibilité contre paiement de récupérer les fichiers même après mise à jour du DSM (custom decryption tool). On peut cependant raisonnablement supposer que Synology a porté plainte, et que des investigations sont en cours.

Bonjour à tous, La dernière communication de Synology au sujet de Synolocker précise bien qu'il est impossible de déchiffrer les fichiers sans la clé : http://www.wegotserved.com/2014/08/06/synology-confirms-decyrption-help-available-synolocker-victims/ (les versions concernées du DSM sont la 4.1, certaines 4.0, 4.2 et 4.3) Et via le site ci-dessus, on trouve un lien vers l'analyse du ransomware sur le site de F-Secure : http://www.f-secure.com/weblog/archives/00002730.html A compléter avec ce lien chez Symantec : http://www.symantec.com/security_response/earthlink_writeup.jsp?docid=2014-080708-1950-99 Seules certaines extensions sont ciblées, ce qui explique la rapidité du processus, ajouté au fait que le message de racket n'apparaît qu'après le chiffrement d'un certains nombre de fichiers en tâche de fond pendant quelques temps, et que le hack est fort opportunément lancé durant le mois d'août pour retarder d'autant plus sa détection avant qu'il ne soit trop tard. Définitivement très astucieux, malheureusement pour les victimes.

Ce qui me gêne avec eux, c'est qu'ils insistent un peu lourdement : Encore moins envie, du coup.

Bon bah fin de la partie. Avoir eu gratuitement Internet Guide - et accessoirement un nom de domaine dynamique - aussi longtemps, c'était quand même chouette, même si finalement je me passerai sans pb des deux. Merci à eux quand même.

Merci mais euh, comme d'autres, je suis absolument sûr que cela fonctionnait auparavant, et de façon globale. Je vois mal la finalité de pouvoir laisser le système télécharger en parallèle plusieurs fichiers, dont le nombre maxi est variable selon la puissance du NAS, tout en devant faire un calcul d'apothicaire pour déterminer la limite totale à ne pas dépasser en fonction de la bande passante maximale de la connection.

Bonjour, Nouveau déterrage de ce topic zombie Car chez moi, les limites d'UL et de DL ne fonctionnent plus depuis quelques temps : pour peu que les torrent en file d'attente aient beaucoup de sources et se téléchargent donc vite, Download Station sature la bande passante de la connexion ADSL, notamment l'upload, ce qui ralentit considérablement tout autre activité sur le net. Cela dure depuis un petit moment (peut-être depuis le DSM 3.2), avec donc plusieurs mises à jour du DSM et du package, et même une migration pour cause de changement de NAS (DS211 vers DS412+). Il suffit de constater la discordance entre les valeurs de débit affichées dans Download Station et ce qui apparaît dans le Moniteur de ressources, sans autre activité réseau si ce n'est celle nécessaire à affichage de l'interface du DSM dans le navigateur. J'ai tout essayé : désinstallation / réinstallation du package, y compris en supprimant physiquement le cache de l'application et ses paramètres sur le volume via WinSCP modification à la main du fichier settings.conf dans /var/packages/DownloadStation/etc application d'une QoS sur les ports BT dans le Panneau de configuration (ne gère pas les débit asymétriques) RAS sur mon routeur, configuration NAT ou mon réseau, c'est vraiment un problème dû à Download Station. J'ai l'impression qu'il y a des griefs similaires sur le forum Syno officiel, mais pas de réponses. Merci de votre aide.

Si je comprends bien, les dossiers partagés sont accédés depuis des machines Windows via internet ? Via un VPN ou bien ? Au cas présent, il faut à mon avis éviter toute ambiguïté dans les couples noms de comptes / mot de passe sur le NAS, qui ne doivent pas être identiques aux noms de session utilisateur sur les PC distants. Comme en général, les ports des partages Windows (ex : TCP 137) sont la première chose que bloque le pare-feu d'un routeur ou d'une box, le cas d'utilisation me dépasse un peu, surtout que Syno a mis en place des outils de partage du NAS qui en général passent par le Web (webdav, FileStation) ou via des applis dédiées pour les terminaux nomades. Pour la pagaille après la ligne de commande, c'est normal : toutes les sessions actives de connexion à un partage réseau ont été fermées. Rien de surprenant donc.

Bonjour, Sous Windows, ce message d'erreur est un classique. Pour faire simple, il faut créer sur le NAS les mêmes comptes d'utilisateurs avec les mêmes mots de passe que sur les postes Windows, et affecter les droits sur les dossiers souhaités en conséquence, selon ce que l'on veut faire. Ainsi, depuis une session utilisateur sur le PC Windows, l'accès à ces dossiers partagés sera immédiat, sans demande d'authentification. Bien entendu, rien n'empêche de déclarer d'autres utilisateurs sur le NAS (ou d'utiliser le compte admin) et de restreindre l'accès à certains dossiers à cet utilisateur. Typiquement : dossiers videos, photos, music : admin & comptes utilisateurs = lecture/écriture dossiers de sauvegarde ou de travail : admin = lecture/écriture, comptes utilisateurs = pas d'accès Ainsi, dès qu'on est loggué sur un dossier protégé avec les identifiants admin, on accède de facto à tous les dossiers du NAS. A contrario, si on accède d'abord à un dossier "ouvert" ou qu'un lecteur réseau est mappé sur un tel dossier, l'accès au dossier protégé va provoquer le message plus haut puisque d'autres connexions seront ouvertes avec des identifiants et mot de passe différents, ce que Windows gère mal. Auquel cas utiliser la ligne de commande pour "nettoyer" les connexions persistantes à des ressources réseau, réinitialisera le tout y compris les lecteurs réseau : net use * /delete /yes Ou fermer et réouvrir la session...