CoolRaoul

Comment as-tu pu faire *toutes* les manips puisque ca bloque des la première? Peux-tu copier ici *exactement* la commande que tu a tapée pour obtenir ce résultat? Comment as-tu pu mettre "xml2epg.pl" dans le dossier enregistrement étant donné que tu bloques à la première étape, étape dont la fonction est justement de récupérer "xml2epg.pl"?

en tout cas moi je n'en ai pas Un truc a savoir pour box: necessite l'option use_locks 0 dans le fichier de conf webdav (/opt/etc/davfs2/davfs2.conf) Et ce sera plus propre en le mettant dans une session dédiée, comme ceci (entre crochets le chemin de ton répertoire local monté en webdav) : [/volume2/box.net] use_locks 0[/code]

Ca je l'aurait trouvé tout seul Mais pourquoi est-il démarré au boot et surtout que fait-il a consommer du CPU ? ***EDIT*** j'avance, apparemment c'est le process "synosnmpc" qui fait les requêtes snmp ***EDIT #2*** synosnmpc semble lié au moniteur de ressource, lorsque il (le moniteur) n'est pas actif, snmpd redeviens bien moins consommateur, se contente de boucler sur un "select", lectures de quelques compteurs dans "/proc" et c'est tout.

Je viens de vérifier, le service SNMP est bien désactivé dans le panneau de configuration DSM. Malgrès cela, le process snmpd est présent: root@fserv> /bin/ps |grep snmp 5755 root 13400 S /usr/syno/sbin/snmpd -Ln -c /usr/syno/etc/snmpd.conf -p /var/run/snmpd.pid udp:161,udp6:161,tcp:161,tcp6:161 8240 root 12756 S /usr/syno/sbin/synosnmpcd 28711 root 2984 S grep snmp Ca ne serait pas tres grave si ce dernier n'était pas actif en permanence, consommant du CPU (peu mais en continu) root@fserv> ps -fp 5755 UID PID PPID C STIME TTY TIME CMD root 5755 1 0 Sep23 ? 00:05:56 /usr/syno/sbin/snmpd -Ln -c /usr/syno/etc/snmpd.conf -p /var/run/snmpd.pid udp:161,udp6:16 Bref, ça me gonfle Une idée? (possible que cela soit depuis le passage en 4.1, je l'aurait remarqué avant sinon)

Es-tu connecté sur le compte "admin" ou un sur compte faisant partie du groupe des administrateurs??

Je crois hélas que c'est le bon angle... Pour ma part, vu que le volume de mes données "critiques" est faible, j'en ai migré l'archivage chez BOX J'ai la-bas (grace à une promo que j'ai su saisir au bon moment) un espace de 50G dans le cadre de l'offre gratuite, mais de toutes façon j'ai besoin de bien moins Et ça supporte le webdav. A part ça, en gratuit je ne vois pas.

Patiente et sinon, essaie plutot d'envoyer un MP a l'auteur du package: Diaoul Note: je j'ai jamais utilisé cet outill-là donc tu en connais déja plus que moi sur ce dernier. j'ai ma propre gestion de crontab basée sur des scripts perso j'ai peur que l'installer me foute un peu le souk

Je ne comprend qu'il y ait encore des gens pour mettre en place sur leur Syno un acces webdav vers Hubic maintenant que OVH a officiellement annoncé l'abandon de ce protocole (et cela a été annoncé dans ce fil en plus)

Ah oui, en effet, j'ai pu reproduire le problème. Bon, je vais regarder ça ce week-end.

Ce que je demandais c'est le message apparait apres que tu ait fait quelle opération *exactement*? Cliqué sur un élément de l'interface et si oui lequel par exemple. (et, eventuellement, une copie d'écran pourrait aider) Parce que à, tu comprendra j'espère, qu'avec ta description il n'est pas franchement facile de comprendre quoi faire pour reproduire le problème. En attendant, essaie déja de supprimer tout le contenu du dossier EPG, comme ceci: rm /usr/syno/etc/packages/VideoStation/EPG/*[/CODE] et ensuite relance le script.

J'avais aussi fait un post en français ici sur ce forum que je viens de retrouver. Comme il est un peu plus argumenté, je pense utile de donner son lien:

Je n'utilise pas photo station, désolé **EDIT** le bon endroit pour poser ta question est ici: http://www.nas-forum.com/forum/forum/97-photo-station-videos-blog/

Ben, à cause du genre d'inconvénient que j'ai décrit, je préfère utiliser des sites publics (imgur, imageshack) pour ce genre de chose Donc je n'ai pas la moindre expérience d'outils dédiés sur le NAS. Cela dit, un simple upload ftp + un partage web du même répertoire en http avec Web Station me semble amplement suffisant et pas besoin de tuto pour ça.

Oui mais attention: si tes images ont du succes, tu risque de voir ta bande passante en upload rapidement saturée.

Et, pour que cela ne se reproduise plus, n'oublie pas mon conseil, quelques posts plus haut sur la manip dans le .profile "/opt" c'est un lien vers (ou un montage) de "/volume1/@optware". Tout ceux qui l'ont installé en ont une version spécifique, qui dépend des packages qu'ils ont choisit installer. Il peut arriver que certains aient aussi des choses privés dans "/volume1/@optware/etc" par exemple (comme des password de montage webdav) Pour faire propre il vaut largement mieux que tu reinstalles optware en partant du bootstrap.

Erreur de ma part, en effet Aie, en effet, semble que si le shell dans /etc/passwd n'est pas valide sshd ne permet pas le login même en spécifiant une commande. Te reste alors un autre option, (que j'aurais du te proposer plus tot d'ailleurs), installer le spk "config file editor": il te permettra d'éditer /etc/passwd a travers l'interface web DSM (connexion en admin obligatoire) et ainsi rétablir le bon shell pour root Tiens-nous au courant du résultat.

Ta session putty doit avoir le host "en dur", dans le champ que j'ai entouré de rouge: Suffit de créer une copie de ta session "nas" que tu nommera par exemple "proxynohost" et dans laquelle ce champ est vide. Et alors, en utilisant la syntaxe: plink -load proxynohost -y -t root@<addresse nas>[/CODE] en remplaçant <addresse nas> par le contenu du champ "host name" de la session "nas" ca devrait marcher

J'ai retrouvé mon post mais il concernait un autre shell et c'était dans le forum anglais Donc voici la manière "propre" d'utiliser un autre shell sur le compte root sans prendre de risques Ici exemple du bash optware: Ajouter au début de /root/.profile: if [ -x "/opt/bin/bash" -a "$BASH_VERSION" = "" ] ; then case $- in *i*) echo >&2 "exec'ing bash" exec /opt/bin/bash --login ;; esac fi ET en cas de probleme, reste toujours ma manip via plink pour s'en sortir

Tu as modifié le shell du compte root dans /etc/passwd. Il ne faut *jamais* faire ce genre de choses sous DSM!!! J'ai expliqué dans un post comment s'y prendre proprement, des que je le retrouve je te donne le lien. Bon, heureusement la situation n'est pas désespérée. Tu vas de nouveau exécuter plink mais comme ceci, avec la commande "/bin/sh" en parametre: plink -t root@<nom ou ip de ton nas> /bin/sh[/CODE] Ceci va te permettre de te connecter en root sur le NAS dans la fenetre de commande windows Une fois connecté, édite "/etc/passwd" et remplace le shell du compte root par "/bin/ash" Attention, sois très prudent dans cette derniere manip: la moindre erreur et tu pers définitivement l'accès au NAS. Le plus sur est de garder la session putty connectée et, dans une autre fenêtre tester que tu peux de nouveau de connecter normalement. Tu ne déconnectera le plink qu'a ce moment-la

Je suppose que c'est que tu utilises? Son auteur est un membre actif de ce forum. Donc, en posant plutôt la question dans le fil dédié j'imagine que tu ne tardera pas à avoir une réponse.

Oui mais dans ce cas il s'agissait d'une console connectée en shell sur IOS, et en effet, là, le jailbreak est necessaire Alors que la ce dont tu as besoin ici c'est un client console qui se connecte sur un *autre* systeme (le NAS en l'occurence).