CoolRaoul

Commencer par: chmod +x /Volume1/System/PhotoStation_DB_copy.sh Et ça ira bien mieux

Dans ce cas je me serai contenté de désactiver le wifi de la box et connecter un point d'accés wifi séparé au réseau Beaucoup moins galère à configurer. (un truc dans le genre de: http://www.amazon.fr/TP-Link-TL-WA801ND-passive-antenne-d%C3%A9montable/dp/B004UBU8IE/ )

Pas d'accord sur le DHCP. Le protocole est conçu pour supporter plusieurs serveurs DHCP sur le LAN (détail). Le principe est que tous les serveurs répondent (DHCPOFFER) à la requête initiale effectuée en broadcast (DHCPDISCOVER), c'est ensuite le client qui va choisir *l'un d'entre eux* et lui demander (DHCPREQUEST, toujours en broadcast pour que les autres serveurs soient au courant) l'allocation d’adresse . Le serveur répond par une confirmation (DHCPACK) En outre, a partir du moment ou le réseau wifi et le réseau filaire partagent le même subnet (ce qui est le cas par défaut des box) n'importe quel serveur DHCP du réseau saura répondre aux requêtes de n'importe quel appareil, qu'il soit connecté en wifi ou en ethernet. Pas besoin de mettre une clé WIFI sur le NAS. Pour info c'est la configuration que j'utilise: serveur DHCP actif sur mon NAS, celui de la box désactivé (j'aurais pu le laisser actif mais ça aurait été moins pratique pour les allocation d’adresses prédéfinies) et WIFI sur la box.

Apparemment les problèmes avec les flux de radio en .m3u ce n'est pas nouveau: Mais suffit de télécharger le .m3U et récupérer l'url .mp3 à l'intérieur, après tout ce n'est pas la mer à boire.

Ca sauvegarde bien les ACL pourtant (en encore heureux!) qui ne sont pas supportées en FAT32 Je pense qu'il devrait également être possible de les stocker sous forme de métadonnées dans le sous dossier "@app@metadata" de la cible de sauvegarde.

Ce n'est pas à cela que je pensais, il n'est bien entendu pas question que la sauvegarde *suive* les liens symboliques (ce qui en effet peut avoir des effets de bords bien tordus) mais bien qu'elle les sauvegarde *en tant que tels*. Je considère qu'une restauration d'un dossier partagé devrait être capable de le reconstituer dans l'état initial. A partir du moment ou les liens sont officiellement supportés ça me semblerait la moindre des choses qu'on soit capable de sauvegarder et restaurer ces derniers. Dans l'état, on peut "modifier ses sauvegardes" tant qu'on veut, les liens sont purement et simplement ignorés.

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.