CoolRaoul

Alors un client en mode graphique n'est *définitivement* pas la solution: des que le navigateur web qui aura été utilisé pour y accéder va se terminer, le client ftp va lui aussi se terminer, ce qui revient à laisser le PC allumé http://www.gnu.org/software/wget/manual/wget.html Sur le syno, la commande est "/usr/syno/bin/wget" Pour avoir le détail des options supportées par cette version, taper: /usr/syno/bin/wget --help

Je n'ai pas le même ressenti: me semble au contraire que le besoin soit assez confidentiel. (comme quoi ...) Apres tout, on peut bien imaginer que personne n'a un Syno tout seul sur son réseau. On dispose forcément a coté d'une machine sachant faire client ftp. Et puis, sous DSM, reste toujours la solution "wget" en ligne de commande (qui peut donc être scripté et lancé en tache de fond, un avantage par rapport à un client graphique), installé de base.

Dans tous les cas une application web (en php) ne pourra écrire sur le NAS que dans des répertoires autorisés en lecture/écriture au compte ou au groupe "http" (sous lequel tourne le serveur apache "user") à moins de savoir utiliser le module "suPHP" (qui est intégré de base dans DSM: CF "/etc/httpd/modules/mod_suphp.so") mais je n'ai pas d'expérience de ce machin.

Autant expliquer la manip alors Pour cela, suffit que le fichier "index.html" du dossier "web" contienne: <meta http-equiv="refresh" content="0; URL=/photo">

Essaie de regarder le contenu des deux fichiers "/var/log/upstart/sshd.log" et "/var/log/upstart/ssh-shell.log" tu y trouvera peut-être des indications sur la cause de l'erreur (je pencherai pour une erreur de syntaxe dans sshd-config).

Je viens de découvrir ça aussi, zut **EDIT** Et une solution de contournement est ici:

Pour visualiser la fin d'un fichier il est plus simple d'utiliser la commande "tail" que "vi" Ceci dit, ton screenshot semble montrer que tu as utilisé le compte "admin" plutot que "root" pour te connecter. Et aussi, vu que tu semble pas complètement maitriser la situation, je me demande pourquoi tu as choisi de bidouiller le fichier sshd_config (avec tous les risques que cela comporte en cas d'erreur comme cela semble être le cas ici) pour changer le port ssh alors qu'il suffit simplement de modifier la redirection dans ta box ou ton routeur. (et pourquoi ne pas l'avoir indiqué des le départ aussi?) Si ça continue à coincer, faudra sans doute nous communiquer ce que contient ton fichier sshd_config (en le mettant sur pastebin par exemple)

suffit de déposer à la racine du partage "web" un fichier index.html affichant "acces interdit" ou tout autre message que tu veux. Cela dit, de fait, dans ta configuration actuelle, l'acces web est bien effectivement limité au répertoire "photo" .

A mon avis: Commencer par rebooter déja. Ensuite, est-ce que telnet fonctionne? Si oui, se connecter en telnet et jeter un oeil à la fin de "/var/log/messages" juste apres avoir tenté l'activation ssh

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.