CoolRaoul

IcI c'est coté *cible* que le rsync coince sur un problème de lien symbolique circulaire, pas sur la source. En fait le problème rencontré est spécifiquement lié a l'utilisation de NFS et a d'ailleurs déjà été signalé sur les NAS synology: http://superuser.com/questions/599498/nfs-too-many-levels-of-symbolic-links-how-to-find-and-fix Voila pourquoi j'ai suggéré une autre approche que celle s'appuyant sur NFS (qui n'est d'ailleurs pas idéale pour d'autres raisons).

Et bien! Qu'est-ce que ça aurait été si tu avais opté de nous donner des détails Commence par créer le répertoire "/opt" ("mkdir /opt") et ça devrait aller beaucoup mieux.

Toutes les commandes précédentes sont de celles qui n'utilisent pas le canal de données. Par contre je vois bien que le mode passif est bien positionné (PASV), ce qui contredit mon diagnostic initial. Alors une possible explication est qu'un firewall est mal configuré (ne laisse pas passer les range de ports utilisés pour le canal de données). Soit celui du Syno soit un autre en amont. Des explications détaillées ici: http://blog.deadcode.net/2009/04/24/ftp-to-your-box-from-external-network/

Vu que tu ne parle que de la commande "LIST" doit on comprendre qu'il n'y a pas de problemes pour les autres commandes ftp? Le symptôme tel que que tu le décris (timeout) ressemblerait à une mauvaise gestion du mode actif de ftp (sans doute par le routeur), pour le résoudre faudrait forcer le mode passif dans ton client ftp. Mais si c'était la bonne explication la plupart des autres commandes utilisant le canal commande (get, put ...) aurait le même comportement. Si c'est que LIST qui merdoie je suis un peu pommé

Ce n'est pas ce que je t'ai demandé, tu as oublié "man3": ls -ld man3 ^^^^ On va laisser de coté l'option "activation du service rsync", qui a quelques inconvénients sous DSM comme être incompatible les autres services de sauvegarde réseau (voir les détails dans l'aide de l'option "panneau de configuration->sauvegarde réseau->utiliser la configuration rsync personnalisée" ) et en outre est un chouïa plus complexe.. Tu pourra te limiter à l'autre option que j'ai citée, le simple "rsync via ssh". Il suffit juste pour cela que le service ssh soit activé sur le NAS. Dans ton cas ça va donner (ce n'est que le 2ème argument de la commande qui va changer): rsync -vazxH --numeric-ids --ignore-errors --delete --delete-after / root@<IP_SYNO>:<chemin du dossier cible sur le syno> Cette approche va te demander de saisir le mot de passe du compte root du syno pour effectuer la connexion. Et c'est tout. [ce qui suit sort un peu du cadre de ce fil, mais tu devrais facilement trouver de l'aide détaillée sur l'authentification par clé ssh par ailleurs] Si tu veux automatiser tout ça (sans avoir à saisir le mot de passe) tu pourra plus tard envisager l'authentification par clé. En gros faudra alors créer (avec la commande "ssh-keygen") une paire de clés ssh privée/publique sans mot de passe coté linux et mettre la clé publique associée dans "/root/.ssh/authorized_keys" du Syno et ajouter a ta commande rsync le paramètre. Cette clé devra par précaution de sécurité être strictement réservée à cet usage. Il faudra alors ajouter l'argument suivant à ceux de ta commande rsync: -e "ssh -i<chemin du fichier de la clé privée>"

pas sur que ce soit une bonne idée d'utiliser dossier monté du syno en NFS comme cible. Même si ce n'est pas sur que l'erreur vienne de là (l'erreur qui indique plutôt une série de liens symboliques circulaires ou plus simplement un simple lien symbolique récursif sur lui même. Mais normalement le switch "-a" de rsync devrait permettre de s'affranchir de ce problème), ce n'est pas idéal pour un backup. Serait bien plus efficace de faire un rsync en mode client/serveur, soit en activant le service rsync sur le syno, soit directement via ssh, syntaxe rsync <parametres> <source> <user_syno>@<host_syno>:/dossier_cible/ dans ce deuxième cas. Et pour revenir à ton problème de lien, est-ce que tu as aussi l'erreur en faisant le "ls -l" en direct sur le syno et pas a distance en NFS? Que donne un simple "ls -ld man3" apres un cd dans "<chemin variable selon le cas>/usr/share/man" ? (à faire à la source, dans le répertoire de backup via NFS et sur le syno en direct) ?

Dans filestation, le menu contextuel d'un répertoire propose l'option "télécharger", ce qui à pour effet de récupérer une archive zip du répertoire.

En effet ça suffit à mon besoin Je vais essayer ça des que possible.

La fonction de base de strace est justement de tracer les appels système, si on en peux même pas lui faire confiance pour ça, ça craint un peu. Inversement, qu'une E/S ne provoque pas d'appel système, j'ai du mal à imaginer. J'ai bien peur qu'en supprimant tout ça je me retrouve avec plus de synchro du tout in fine. Peut-être que btsync n'est simplement pas la bonne solution pour mon besoin: je cherche à maintenir sur le NAS un miroir d'un certain nombre de dossiers bien identifiés de mon smartphone Androïd. Et DsCloud n'est pas adapté dans le cas de dossiers "éparpillés" comme ceux-la.

Avec le tcpdump je vois effectivement un broadcast UDP sur le port 3838 émis toutes les secondes mais comment se fait-t-il que strace n'y voit que du feu? Un process peut faire des E/S réseau sans que cela implique le moindre appel système? Mis à part cette question, je me demande à quoi cela peuvent bien servir ces broadcasts. Les démon cloudstation bouclent en attente sur un select() avec timeout de 3 seconde, ça me semble plus approprié pour ce type d'application.

Si il y avait des E/S réseau impliquant le process btsync le strace ne devrait-il-pas capturer les appels systèmes correspondants (read, write, ou sendto/recvfrom dans le cas de sockets udp) ? Ce n'est pas parce que le process est en écoute sur des socket qu'il y a forcément du traffc. Normalement il devrait y avoir du traffic uniquement lorsque'il y a des modifications de fichiers à propager, déclenché coté NAS un une notification inotify et coté client par l'arrivée de données de signalement des clients via le réseau. Là, en mode standby, je constate un réveil toutes les secondes et les seuls appels système exécutés à chaque cycle sont pour lire l'heure et re-armer une alarme.

Je m'immisce dans le fil car je viens d'installer ce bidule (pas pris le package mais je ne pense pas que ça fasse de différence) J'ai pu constater que le process btsync se réveille exactement toutes les secondes. A chaque cycle il ne fait *strictement aucune entrée/sortie* (pas plus réseau que disque) mais consomme par contre du CPU. Je me demande bien ce qu'il peut foutre. En tous cas ça confirme la remarque (le NAS n'entre jamais en veille) mais pas le diagnostic (tres bavard sur le réseau) puisque aucun traffic réseau n'est produit en absence de modifications à propager. **EDIT** J'ai déjà posé la question sur le forum de btsync, mais apparemment ça ne passionne pas les foules: http://forum.bittorrent.com/topic/25171-daemon-never-sleeping-longer-than-1-second/?p=73000

Aussi pour moi oui. Reste à trouver les différence entre "BRAVIA", "BRAVIA-1", il doit forcément en avoir

Disons qu'il est assez capricieux, faut faire des acrobaties et règler au petits oignions certaines entrees de la base de registre pour qu'il se connecte sans heurts. Par exemple, sur mon PC perso a l'instant j'ai pu vérifier que je peux me connecter en webdav à mon NAS en http et https, mais je ne suis pas sur si on me donnait un PC Win7 "vierge", d'être capable de retrouver exactement les bons settings. Avec NetDrive en général sa fonctionne sans à-coup. 5006 c'est en SSL avec la config par défaut , donc faut essayer: https://<iplocalesyno>:5006 ou (sans le "s" à "http") http://<iplocalesyno>:5005 Bien entendu pour une connexion externe faut avoir redirigé les ports dans la box et utiliser l'IP externe si elle est fixe sinon le nom DDNS ****EDIT*** Tiens, je viens de retrouver cette page que j'avais bookmarké, peut être utile: http://www.brizawen.com/?p=324

Pas de différences entre bravia-1 et bravia ou entre bravia et dlna générique?

Passer par Filestation:

Le contexte décrit initialement par le 1er message du fil était celui d'une application Window. Dans ce cas, c'est au sein du module système de gestion de fichiers approprié (que ce soit celui de Windows ou tierce partie) que vont être traduites en requêtes Webdav encapsulées HTTP les primitives d'acces aux fichiers invoquées par le code de l'application. Le lecteur video client lui n'a aucune raison ni besoin de savoir par quel canal (webdav, smb ou ntfs direct) il accède au fichier. Et puisqu'il est question de VLC, Je viens de faire un test en ouvrant un fichier video via webdav avec ce dernier (et avec un proxy au milieu pour compliquer les choses). Il a lancé la lecture de la video immédiatement sans attendre un téléchargement complet. Ces test ont été fait avec l'implémentation webdav de chez Webdrive mais je ne serai peu surpris que ça se passe de façon identique avec le Webdav natif de windows ou celui de netdrive. En résumé faut commencer par tester avant de disqualifier cette solution a priori.

CF: http://www.webdav.org/mod_dav/faq/#01-02 ***EDIT*** En complément: http://stackoverflow.com/questions/11216884/which-file-access-is-the-best-webdav-or-ftp "WebDAV supports partial transfers and in FTP partial uploads are not possible (ie. you can't override a block in the middle of the file)."

Il y a aussi la solution webdav ...

Ca vaut le coup d'essayer ce nouveau profil après tout: Si Synology a pris la peine de définir un profil spécifique aux modèles Sony récent, c'est déjà qu'il ont reconnu qu'il y avait bien un problème.

Vu que sur PC il faut le plugin VLC dans le navigateur pour que ça fonctionne, je ne mettrai pas beaucoup d'espoir dans la manip via le navigateur intégré à la TV

C'est normal il ça me semble bien.

La tentative de connexion vient probablement d'un *client" d'Amazon (ils vendent des services "cloud" , et m

J'espère que la BOX est en mode bridge, parce que sinon, avec le netgear, ça fait deux routeurs en cascade et il te faudra te préparer à des "nervouzes breakdowns, comme on dit de nos jours", entre autre pour les ouvertures de ports.

Si tu ne comprend pas l’intérêt des groupes, je te conseille de ne pas te lancer dans les ACL, tu risque de trouver ça encore plus compliqué et être complètement perdu.