CoolRaoul

Ok, ca s'éclaircit pour l'option modifiée j'imagine qu'il s'agit respectivement des options "follow symlinks", et "wide links" de smb.conf (cf: https://www.samba.org/samba/docs/using_samba/ch08.html) Mais, si il s'agit bien des symlinks unix, je ne comprend encore moins pourquoi le backup ne les gère pas quand qu'il existe une option de l'interface DSM pour en tenir compte au niveau du service de fichiers.

Je me demande bien a quoi sert cette option? (elle est dans panneau de configuration -> services de fichiers -> Win/Mac/NFS -> paramètres avancés) L'aide en ligne n'est pas beaucoup claire: Permettre les liens symboliques au sein de dossiers partagés : L'activation de cette option permet que les liens symboliques redirigent vers des fichiers ou des dossiers situés dans le même dossier partagé. Les liens symboliques peuvent être créés à l'aide d'un terminal DSM. Si, comme j'imagine, il s'agit de liens symboliques unix (crées par "ln -s"), que je sache, leur création a *toujours* été supportée en shell dans un terminal (je suppose que c'est à quoi l'expression "terminal DSM") fait référence. En plus, que cette option soit cochée ou pas, la sauvegarde continue à les ignorer (avec le message d'erreur "Local backup skip symbol link file").

Pareil pour moi sur DSVideo sur ma tablette Nexus10 (CTD systématique). Depuis le 20 juillet j'ai un dossier de support ouvert chez Syno à ce sujet Peu après, ils m'ont demandé des logs système (logcat, pour temporiser j’imagine). Le 28 juillet; je leur ai envoyé un stack dump ou ont voit clairement l'erreur: "java.Iang.RuntimeException: Canvas: trying to use a recycled bitmap" Ca été le dernier contact sur ce dossier, depuis c'est le black out de leur part. Pas top le support Syno pour les appli Android NB: J'avais déjà eu affaire à eux pour DSCloud. Ils avaient péniblement fini par reconnaître le dysfonctionnement, un trafic réseau entre le NAS et les clients Android toutes les 5 secondes (qu'il y ait eu des modifs ou pas!), avec pour effet de bord des accès réguliers au disque local. La réponse à mon étonnement qu'ait été utilisée une approche par polling plutôt quévénementielle, sachant qu'on dispose d'une connexion permanente bidirectionnelle entre client et serveur, a juste été que c'était une "amélioration" qui serait "suggérée" aux développeurs pour une version future. J'ai laissé tombé DSCloud depuis lors.

Je pense que c'est l'explorer Windows qui ouvre les .zip qu'il rencontre dans les dossier qu'il parcours. Une piste ici: http://www.sevenforums.com/tutorials/13619-zip-folders-enable-disable-windows-explorer-view.html (ça peut aussi être l'antivirus windows)

La dépendance au mkvmerge d'Optware ne risque-elle pas peut être problématique sur le long terme? Le projet me semble en voie d'abandon (cf ici), on ne note quasiment plus d'évolution dans le repository depuis 2010 En outre, de plus en plus de modèles de Syno ne sont pas supportés.

Non, cela ne concerne que la sauvegarde de *configuration*, pas les fichiers (pouquoi donc est-ce indiqué en chinois sur ton screenshot? tu aurais percuté sinon) Exemple en V5 (au look pres c'est pareil qu'en V4): Cela ne permet que de conserver un exemplaire de la dernière version d'un fichier *effacé*. Par contre la sauvegarde d'un fichier *modifié* écrasera sa version sauvegardée précédente

Ah ok, je comprend mieux. Mes filtres RSS ont tiltés a a cause des clés "Synlogy" et "Synlocker" présents dans l'article, et comme on m'attendais pour déjeuner je n'ai pas pris le temps d'approfondir. Désolé pour la fausse joie.

Ah ok alors, si il y a déjà des témoignages négatifs évidemment. Je croyais que c'était un nouveau service vu que la news venait juste d'être postée peu avant midi sur pcworld, ce qui m'a induit en erreur. **EDIT** En fait ca ne concerne meme pas le ransomware Syno, me suis fourvoyé! explications ici:

Scoop: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer

C'est ainsi que fonctionne le backup Syno, que ce soit en local ou de NAS à NAS, d'ou ma remarque. Pour conserver un historique nécessite faut soit utiliser un volume dédié en cible, soit utiliser Time Backup (dans les deux cas avec les problemes de volumétrie sur la cible lorsque tous les fichiers sources sont modifiés comme tu l'as fait remarquer) ***EDIT** Je viens de tomber sur cet article: Le ransomware CryptoLocker n'est plus une fatalité : un site Web pour connaître sa clé de déchiffrement sans payer Je sens qu'il y en a certains qui vont être soulagés!

Tu m’enlèves les mots du clavier: j'étais en train de composer peu ou prou la même réponse. Attention à la synchro ou au backups automatiques: pour peu que ce soit soient programmé assez fréquemment (ou pire en quasi temps réel) les données chiffrées se retrouveraient à l'identique sur le NAS de sauvegarde (même si ce dernier n'est pas touché directement).

Et pourquoi donc "surement pas"? Serait surprenant que Free supprime des les modèles plus récents des fonctionnalités existantes sur les précédents (C'est une V5 dans mon cas mais je viens de vérifier: c'est pareil sur V6.) Me semble que ce sont certaines box numericable qui ne savent pas faire ça.

Pas besoin de modifier le port sur le Syno quand on peut le faire sur la box dans la règle de redirection. Exemple sur une freebox:

Heureusement que la plupart des box savent faire la translation de port par elle mêmes, parce qu'avoir a mettre ce genre d'architecture avec deux subnets et un routeur intermédiaire juste pour ça, ça me gonflerait un peu.

Dans le cas donné en exemple (je cite: "Mon ip avait été utilisée pour hacker") il est bien question d'usurpation d'IP, pas d'utilisation de proxy pour masquer le pays d'origine.

Contrairement à une idée reçue, c'est non seulement loin d'être aussi facile qu'on pourrait penser, mais quasiment inexploitable dans la plupart des configurations. Et c'est Stéphane Bortzmeyer qui l'écrit: http://www.bortzmeyer.org/usurpation-adresse-ip.html

Oui, avec ce genre de règle en haut de la liste du firewall (modifier éventuellement le subnet 192.168.1.0 selon la config de la box): et aucune autre règle active en dessous. et enfin, terminer par: **EDIT** Cela dit si aucun port n'est redirigé dans la box, ça revient au même...

Il n'en est pas à son premier méfait ce chinois-la http://www.abuseipdb.com/report-history/61.144.43.235 (sans doute une IP dynamique, donc pas forcément toujours le même gus à la manœuvre)

Mais la ce ne sont pas des disques vierges inconnus pourtant: puisqu'ils n'ont pas été modifiés.

Je ne comprend pas bien la manip: apres l'étape 6 ne devrait-on pas se retrouver dans l'état initial de l'étape 1? Vu qu'on on remet des disques qui n'ont pas été modifiés, il va booter sur le DSM installé sur ces derniers

Peux-tu dire comment se met en place le second blocage?** **edit** c'est bon: trouvé

Bien sur: tout répertoire ajouté à "open_basedir" permet aux programmes php d'accéder à toute la hiérarchie sous-jacente (détails ici). Mais pourquoi ne pas simplement avoir testé?

Tu parles sans doute de ma phrase "les settings fait sous DSM sont conservés lors des reboot" je suppose? Tu conviendras que ce problème du wifi est quand même très spécifique. De plus ça ne doit pas courir les rues les personnes utilisant une interface wifi (clé ou intégré) sur le NAS comme interface principale (pour y rediriger les ports de la box). Si le support Synology n'est pas au courant, alors ce bug n'est pas près d'être corrigé, vu qu'il doit toucher bien peu de monde en plus.

Ah je comprend mieux, comme tu parlais de *firewall* j'ai bloqué la dessus. En effet, le blocage IP s'applique exclusivement aux connexions aux service DSM utilisant une authentification compte/mot de passe. Ca se comprend puisque ça se déclenche sur un nombre d'échecs de mot de passe. Voila pourquoi une connexion en mode "socket" tcp, ne peut pas faire l'objet de ce genre de mesures défensives. PS: note bien que ton filtre iptables, non seulement ne résistera pas à un reboot , mais qu'une simple modif de la config du firewall va aussi réinitialiser tous les filtres.

Ma réponse initiale ne portait pas sur le coté plus ou moins rapide ou automatique de la manip, je répondais juste à "Semblerai que le pare-feu des syno ne soit pas très efficace contre des attaques sur la couche tcp". Un autre avantage est que les settings fait sous DSM sont conservés lors des reboot.