CoolRaoul

Si "Trash It" est une appli tournant sur le MAC et que ce dernier accede aux dossier partagés du NAS en SMB/CIFS, on peut activer un journal mais, hélas pour toi,il n'est pas activé par défaut Sous l'interface d'admin DSM, faut aller dans "panneau de configuration" -> "Services de Fichiers" -> "Win/Mac/NFS" -> "Service de fichiers Windows" et cocher "Activer le journal des transferts" Il sera ensuite possible de consulter les traces (notamment les suppressions) en cliquant "Afficher les journaux" Mais la c'est trop tard. Et dans le cas ou c'est le protocole natif Mac qui est encore utilisé, je ne pense pas qu'il soit possible de disposer de traces.

je l'ai brièvement testé lors de la sortie de DSM5 et je n'ai pas vu/trouvé de possibilité de synchro sélective (CAD uniquement certains dossiers GDrive). Tant que ce ne sera pas possible ça ne me conviendra pas trop. (ne m'avais pas semblé très stable non plus mais il y a eu des correctifs depuis)

Je confirme que normalement tu devrais avoir les onglets ci dessous: Si personne d'autre n'a d'idée faudra contacter le support Syno

A noter que les déplacement et/ou copies entre dossiers du NAS et effectués via Filestation n'utilisent pas le réseau et se font à vitesse maxi eux (de disque à disque)

Tu veux dire que ça reste bloqué sur ? **EDIT** Je me trompe ou les deux screenshots sont identiques?

Alors, si ça a fonctionné comme cela, en remplaçant dans le script "/bin/bash" par "/bin/sh" ça devrait marcher. Il s'agirait juste d'ajouter la ligne: PATH=/bin:/usr/bin juste en début de script (apres la ligne "#! ...").

Oh, tu rigoles! Pour eux je suis un simple quidam, je n'ai strictement aucune entrée chez Syno

Etrange alors. En tout cas tu observes bien un trafic permanent (bien qu'avec un profil différent) même en l'absence de synchro. Ce que je considère comme anormal. De toutes façon, te biles pas: maintenant que j'ai pu faire des des tests avec le NAS de mon pote qui m'ont permit de constater exactement le même comportement qu'avec le mien, j'espère que ça suffira pour faire entendre raison au support.

Tiens étonnant, tu as un traffic bien plus important (et régulier) que moi. Peut-être as-tu des synchro en cours. De mon coté c'est *pile* toutes les 5 secondes, 3 paquets échangés (Phone -> NAS, NAS->phone, Phone -> NAS): fserv> /usr/sbin/tcpdump -i eth0 -n port 6690 -c 9 | awk '{print $1,$3,$4,$5$(NF-1), $(NF)}' tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 9 packets captured 9 packets received by filter 0 packets dropped by kernel 09:43:26.322265 92.158.61.207.34300 > 192.168.1.14.6690:length 262 09:43:26.325695 192.168.1.14.6690 > 92.158.61.207.34300:length 287 09:43:26.384535 92.158.61.207.34300 > 192.168.1.14.6690:length 0 09:43:31.559302 92.158.61.207.34300 > 192.168.1.14.6690:length 262 09:43:31.562443 192.168.1.14.6690 > 92.158.61.207.34300:length 287 09:43:31.622982 92.158.61.207.34300 > 192.168.1.14.6690:length 0 09:43:36.922400 92.158.61.207.34300 > 192.168.1.14.6690:length 262 09:43:36.925531 192.168.1.14.6690 > 92.158.61.207.34300:length 287 09:43:36.989821 92.158.61.207.34300 > 192.168.1.14.6690:length 0

Ca serait mieux en effet, l'objectif étant de focaliser sur le client android. (on peut filtrer uniquement ce dernier si on connait son IP en ajoutant "and host <ip>" à la commande "tcpdump" également)

Peut-être n'est-tu pas root Autre possibilité, spécifier l'interface dans la commande. un "netstat -i" va lister tes interfaces, sélectionner celle avec l'ip du LAN ("eth0" pour moi) et ensuite: tcpdump -i eth0 port 6690

Au moins depuis la version 5 tcpdump est intégré à DSM (dans "/usr/sbin/") pourtant!

Bon, vu que ma requête ci dessus n'a pas eu l'air de déchaîner l'enthousiasme des foules, j'ai fais la manip avec le Syno d'un pote et, comme je m'y attendais, j'ai pu là aussi constater ces échanges entre le smartphone et le démon cloudstation toutes les 5 secondes. J'espère que cette fois le support Synology va bien vouloir reconnaître que le défaut est du coté du client DScloud et pas spécifique à la configuration de mon NAS. A suivre.

Je vois que tu débutes en unix... Pourquoi avoir choisi ce shell "/bin/bash" qui n'existe pas sous DSM ? (au passage je suis curieux de savoir avec quelle syntaxe tu as exécuté le script en ligne ce commande pour que ça fonctionne). Sous DSM, le shell dont on dispose de base est "/bin/ash" (ou "/bin/sh" mais c'est identique). La ligne "#!/bin/ash" serait donc plus appropriée. Tiens, tant que j'y suis, puisque tu compte lancer le script via le gestionnaire de tâche, je te conseille de mettre "en dur" la déclaration du PATH à l'intérieur ("PATH=/bin:/usr/bin" pour commencer). Vu que, par défaut, les environnements d'exécution batch et interactif ont un PATH différent tu pourrais tomber sur des différences de comportement bien velues à dépatouiller si tu ne fais pas ça. "root" a toujours *tous les droits* sur *tous les fichiers* (a l'exception du droit d'exécution ("x") qu'il faut explicitement positionner si absent mais il peut le faire de toutes façons avec la commande "chmod" qui va bien)

Quelle est la premiere ligne du script? que donne "ls -l /volume1/Save/script.sh" ?

Est-ce que le script s'exécute lorsque il est lancé en ligne de commande? (via connexion ssh ou telnet) En outre, essaie de rajouter: >>/volume1/Save/script.log 2>&1 à la fin de ta ligne dans le planificateur de tache ce fichier log sera créé lors de l'exécution de la tache et il contiendra les éventuels messages d'erreur que tu pourra consulter.

Alors la je sèche, Dans cette situation je tenterai un reboot

Je vois, c'est sur que si tu te cherchais à te connecter en ssh sur un port que ton démon sshd écoutait un autre ça ne risquait pas de fonctionner De mon coté, pour utiliser un autre port (et éviter ce genre de problème) je préfère le faire au niveau de la règle de redirection sur le routeur/la box.

Juste par curiosité: peux-tu nous dire quels paramètres tu as du modifier? J'utilise un "sshd_config" non modifié et je n'ai pas de problèmes de connexion.

Je n'ai pas eu a configurer quoi que ce soit **edit** Mais, même si tu parviens a faire marcher ton bidule, ça risque d'être peu pratique et probablement pas tres preformant: Si j'ai bien compris BubbleUPNP, sur ton smartphone ou ta tablette, va devoir aller lire en streaming les fichiers media à partir du serveur DLNA du NAS pour les re-streamer à nouveau vers la clé HDMI.

Bubble, je l'utilise et ça marche au poil. Tu es bien allé dans l'onglet "devices" pour sélectionner le NAS d'abord? Sinon, je ne suis pas chez moi là, peux pas t'aider dans l'immédiat

Non, le firewall de logge pas les connexions qu'il a bloqué. L'option de notification qui apparait dans ses parametres ("M’avertir quand des applis ou services sont bloqués par le pare-feu et fournir l’option de débloquer ce service ou cette appli.") ne s'applique que lorsque on active un nouveau package pour prévenir si il y a des ports à ouvrir et proposer de le faire. Ce type de message (mise en blacklist) apparait sous forme de *notification*, pas dans les journaux.

C'est un serveur DLNA, mais le serveur multimédia de DSM devrait être suffisant. Serait surprenant que la clé ne soit capable dialoguer avec ce dernier et pas avec le serveur natif de DSM. **edit** Suis tombé sur cet article pas tres rassurant: http://www.minimachines.net/actu/google-chromecast-la-concurrence-saffute-11510 **edit #2** nb: ne s'agit pas du même modèle de clé mais c'est la même techno: http://www.jesuisgeek.fr/tests/test-dongle-hdmi-wifi-hd-1080p-pour-diffuser-vos-contenus-sur-la-tv-6154.html "Je l’ai essayé pour la fonction dlna en espérant accèder à mon nas. Cela ne fonctionne pas du tout. Le dongle se contente d’appeler un logiciel tier. Concernant la lecture vidéo, ça saccade en permanence et côté dongle, aucun paramètrage possible."

As-tu également posé la question ici ?

Le service VPN client de DSM ne serait-il pas actif?