CoolRaoul

Ah zut, me semble avoir que la faille exploitée avait pour effet de modifier/ou supprimer certaines commandes (dont "ls" et "mv") Mais je ne retrouve pas l'info

Peux tu essayer de remplacer dans mv 3.3.avi '3 3.avi' mv par ls et nous donner le résultat?

C'est avec les quotes *ou* avec les "", mais pas les deux (ou m'as-tu vu parler de mettre des "" ???)

et si tu entourais les noms contenant des espaces avec des quotes ? Comme ça: mv 3.3.avi "3 3.avi" Sans les quotes le shell interprète cela comme l'appel de la commande "mv" avec *3* arguments: mv "3.3.avi" "3" "3.avi" autrement dit tu demandes de déplacer les fichiers "3.3.avi" et "3" dans le répertoire "3.avi" (au dela de deux arguments, "mv" essaie de déplacer les N-1 premiers objets de nom donnés en paramètre dans le dossier dont le nom est le Nème argument). Comme le 2eme fichier n'existe pas et que le 2eme argument ne correspond à aucun répertoire non plus, ça explique l'erreur.

Vu que la redirection de port n'a pas été faite, en te connectant sur XXXXXX.synology.me ce n'est pas sur ton NAS qui tu arrives mais tres probablement sur le formulaire de connexion externe au routeur (ou sur un autre équipement: il est possible que le routeur ait été configuré ainsi par une autre personne dans la mesure ou ce dernier est mutualisé avec les autres locataires du bâtiment à ce qu'il semble) Pour faire les redirections de ports oui. DSfile sait utiliser une méthode alternative de connexion ("quickconnect" que j'ai évoquée plus haut). Quand c'est actif, le NAS établit une connexion *sortante* vers des serveurs chez Synology qui vont jouer le rôle de passerelle. Par suite, plus besoin d'ouvrir de port dans le routeur (puisque il n'y plus besoin de connexions entrantes passant à travers le routeur). Mais les connexions directes restent également possibles simultanément. L'inconvénient est d'un coté une perte de performance et de l'autre la dépendance aux serveurs relais chez Synology. C'est d'ailleurs indiqué en remarque dans la la partie "quickconnect" du panneau de configuration DSM: Comme tu peux le remarquer, pour l'instant seuls 5 services (parmi lesquels DSfile) sont "quickconnect compatibles". (attention: "partage de fichier" fait référence à l'utilisation de liens pour accéder de façon unitaire et ciblée à *un* fichier, on ne parle pas ici du partage réseau Windows) A partir de DSM 5 de nombreux autres services le seront, y compris l'interface DSM elle même (et donc FileStation), comme indiqué ici:

Ce n'est pas parce que la question est basique (et elle l'est, pour la clarté on peut en discuter) que la solution l'est aussi. Je l'ai déjà écris à deux reprises: pour accéder au NAS par internet un simple navigateur suffit (Internet Explorer, Chrome, Firefox ou autre). Tu pourra alors accéder à FileStation, qui est un peu l'équivalent de DSFile dans un navigateur. Il y a aussi d'autre méthodes possibles (comme ftp). Si tu veux y accéder en connectant "un lecteur réseau", la solution la plus approchante passe par le protocole Webdav, mais ce n'est pas forcément immédiat à configurer sur les postes clients. Par exemple, sous Windows 7, certains (dont moi-même) ont galéré avec ça. Enfin, faut bien savoir que, dans tous les cas, une redirection de ports dans le routeur situé entre ton NAS et internet est indispensable (ce ne sont pas les même ports suivant le type d’accès, navigateur, webdav ou autre). Et pas forcément suffisant: si ton accès internet ne bénéficie pas d'une adresse IP fixe, faudra mettre en oeuvre le DDNS, encore que ça ne soit pas trop difficile à faire dans le panneau de configuration DSM. (j'imagine que cela doit peut être un peu charabia pour toi, voila qui confirme que la réponse ne peut pas être "basique") Hélas, tu nous as dit "Je ne sais pas comment est constitué le réseau sur lequel est branché le Nas". C'est ennuyeux car cette connaissance est un préalable indispensable pour faire l'opération de redirection de ports. Cela, ajouté à "je ne pige rien aux tutos de Synology", fait que, même avec la meilleure volonté du monde, on voit difficilement comment s'y prendre pour t'aider.

Tu te compliques la vie peut-être pour rien: en configurant le firewall du syno distant pour refuser les connexion sur le port 22 pour tout autre IP que celle du syno source (2 règles à ajouter) plus d'attaques et pas besoin de changer le numéro de port.

Alors, si ta demande se limite à ça, la réponse je l'ai indiqué dans mon message : Il y a d'autre façons, mais vu que tu semble allergique à la technique, le mieux est de s'en tenir à ça pour le moment.

Hors sujet (et je vais probablement me faire incendier), mais pourquoi avoirs choisi de participer à la beta avec un NAS contenant des données importantes non sauvegardés?

Si tu as du mal a trouver la réponse à ton problème (et pourtant c'est une des question les plus souvent posées sur le forum: ce ne sont pas les fils sur le sujet qui manquent), le mieux est d'attendre l'arrivée de DSM 5.0 après la fin de la phase beta en cours. Tu pourras te connecter à distance beaucoup plus simplement, en utilisant (comme c'est déja possible avec DSFile) utiliser quickconnect pour te connecter à DSM ou directement à filestation via un navigateur PC.

Oui: le script me semble un peu bancal mais on constate bien qu’après le "stop" tous les process dhcp sont arrêtés et à la suite du "start" ils sont a nouveau actifs avec les mêmes paramètres. Note aussi que ça va changer en 5.0: DHCP devient intégré à DSM et n'est plus sous forme de package, les scripts de start/stop seront ailleurs.

Me suis mal exprimé: ce qui m'a interpellé c'est comment on peut avoir un processus *dans* un dossier. A part "/proc", dans un dossier on trouve des fichiers (possiblement exécutables) , d'autres dossiers et éventuellement des sockets unix ou fifos, mais parler de "processus"?

Pas apres le "stop":

J'ai vérifié et en effet les scripts font des erreurs (peut-être un peu buggés ?) fserv> ps -ef |grep dhcp root 20491 1 0 09:19 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20492 20491 0 09:19 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20548 19770 0 09:20 pts/0 00:00:00 grep dhcp fserv> /var/packages/DHCPServer/scripts/start-stop-status stop Deleted 0 keys from file /etc/synoinfo.conf kill: can't kill pid 20492: No such process fserv> ps -ef |grep dhcp root 20611 19770 0 09:20 pts/0 00:00:00 grep dhcp fserv> /var/packages/DHCPServer/scripts/start-stop-status start sh: 1: unknown operand sh: 1: unknown operand sh: 0: unknown operand sh: 0: unknown operand sh: 2281: unknown operand rm: can't remove '/etc/dhcpd/dhcpd.conf.leases': No such file or directory rm: can't remove '/etc/dhcpd/dhcpd-leases.log': No such file or directory kill: can't kill pid 20717: No such process fserv> ps -ef |grep dhcp root 20724 1 0 09:20 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20725 20724 0 09:20 ? 00:00:00 dnsmasq --user=root --cache-size=200 --conf-file=/etc/dhcpd/dhcpd.conf --dhcp-lease-max=2147483648 root 20761 19770 0 09:20 pts/0 00:00:00 grep dhcp Il est bien stoppé pour moi (cf les commandes "ps") A quoi constates-tu que DHCP ne s’arrête pas de ton coté?

C'est quoi "/PWNED" ?? (Google ne m'a pas vraiment aidé)

Emacs + Tramp alors! (mais la "learning curve" risque d'être un peu ardue si tu ne connais pas)

Merci pour l'info. Pour moi le principal est que ce soit réglé lors de la sortie de la version définitive de DSM 5

Non, la seule option possible c'est winscp qui permet de faire du scp, avec filezilla ca sera au mieux sftp et sur le syno, par sftp, on ne peux accéder qu'aux fichiers situés dans les dossiers partagés **edit** cf: http://winscp.net/eng/docs/scp Remarquer que dans la plupart des situations sftp est préférable, mais la on est dans un cas particulier.

Ah ca c'est exact, c'est juste pour modifier des fichiers existants (dans une liste prédéfinie à déterminer), ponctuellement

"Config file editor" Le support du package a été interrompu mais on peut le récupérer ici

Ben non, ça reste inexplicable: je ne vois aucune explication pour qu'un script sous le compte root fasse l'erreur "Permission denied" en ouverture de "script_cam.sh.log".

Vu que les messages précédents du fil on prés d'un an, et que plusieurs versions de VideoStation on été publiées depuis, ça m'étonnerait beaucoup que ce soit le *même* problème (juste des symptômes similaires) As-tu bien installé VLC et cochant l'option "plugin" dans le menu présenté lors de install?

Heureux que ca marche Par contre l'erreur ci-dessus me plonge dans un abime de perplexité: le script étant exécuté en tant que root (qui a, de fait, *tous* les droits), l'erreur ci dessus est absolument inexplicable

Merci de prendre le relai

Ne *jamais* utiliser notepad pour éditer un script unix! Si tu tiens à utiliser une appli Windows, à la limite prendre notepad++ configuré comme cela: Sinon, "vi" directement sous DSM (rustique mais sans surprises)