cly

Bonjour, Suite a des pbs sur le disque qui contenait mes donnees partagees par uPnP, je suis en train d'essaye de recuperer ce qui peut l'etre. Ca m'aiderait d'avoir la liste des fichiers memorises lors de la derniere indexation, comme je saurai ce que j'ai perdu. Question: connaissez-vous un outil en ligne de commande qui permette de faire comme un 'ls' sur le serveur uPnP? (Utiliser ma freebox pour listerr tous les fichiers potentiels est un peu... penible!) A defaut, un soft sur PC qui pourrait se connecter au Synology et qui me permettrait de recuperer cette liste par copier-coller me depannerait bien. J'ai essaye Cidero, mais c'est d'une lenteur phenomenale et ca ne permet pas le copier-coller (du moins je n'ai pas trouve) Merci!

Alors voici le resultat des experiences: - changement de password 'admin' depuis DMS: ca ne change que celui d'admin, pas de root - changement de password 'root' depuis un shell: ca ne change que celui de root j'ai du avoir un truc bizarre, du style j'ai oublie que j'avais change le password de root parce que l'ancien marchait toujours avec le ssh de Syno... Mais comment faites-vous, les autres qui ont l'openssh d'ipkg? Vous ne changez jamais le password de root/admin?

oui, bien sur j'ai fait un /opt/etc/init.d/S40sshd restart je me prends: Permission denied, please try again. et il n'y a rien dans les logs (dans /var/log, car /opt/var/log n'existe pas) Pour un compte non root, ca fonctionne.

Bonsoir, Suite a un ipkg upgrade, le paquet openssh a ete mis a jour, ainsi que /opt/etc/sshd_config, sans me demander la permission! J'ai pu facilement remettre a jour le numero de port que j'utilisais pour cette 2eme instance (en plus de celle d'origine, sur le port 22), mais je n'arrive pas a me connecter en tant que root avec cette instance d'openssh (avec celle de syno c'est OK). Je ne me souviens plus si ca marchait avant mon upgrade ou pas... J'ai beau forcer PermitRootLogin yes, ca ne change rien. C'est normal?

Pour info, j'avais contacte le support Free a ce sujet, qui m'avait repondu.... qu'ils ne font pas de support a ce sujet (uPNP) :-)

Moi j'ai une freebox v5, en mode routeur.<br />Je n'ai aucun pb pour voir les films, si ce n'est que certains noms sont tronques de facon mysterieuse (il y a un autre fil de discussion la-dessus d'ailleurs).<br /><br />Chez moi, les photos ne marchent pas... je vois bien les vignettes sur la tele, mais pas moyen de les voir en grand.<br /><br />Pour les MP3, c'est une limitation volontaire de la freebox: a priori il faudrait que free paye une licence pour avoir le droit de supporter le MP3. Il semble y avoir moyen de contourner ca en encapsulant le mp3 dans des avi (google est ton ami).<br /><br />As-tu bien lance une re-indexation des fichiers multimedia depuis l'interface du Syno?

Oui, c'est possible, je le fais pour mes videos. Il suffit de monter le disque externe dans l'arborescence exportee en upnp/dlna, par exemple: mount -o bind /volumeUSB1/usbshare/video /volume1/video/externe/ Pour automatiser cela au boot du NAS, j'ai rajoute un script /usr/syno/etc/rc.d/S99mountusb.sh qui en appelle un autre en background (pour eviter de bloquer le boot si le disque externe n'est pas allume). /usr/syno/etc/rc.d/S99mountusb.sh: #!/bin/sh /volume1/documents/mes-scripts/mountusb.sh & Ce 2eme script fait: #!/bin/sh Target=/volumeUSB1/usbshare/video while [ 1 ]; do if [ -d "$Target" ]; then /bin/mount -o bind $Target /volume1/video/externe return 0 fi sleep 30 done return 0 Contrairement au script /usr/syno/etc/rc.d/S99mountusb.sh dont l'emplacement et le debut du nom (S99) sont importants, tu peux placer et le nommer le 2eme comme tu veux.

Bonjour,

Bonsoir, desole de revenir tardivement sur le message #9:

OK merci pour l'info, je me doutais que desactiver l'hibernation enleverait le bruit. Mais ca m'embete de desactiver l'hibernation vu qu'il y a peu d'activite sur mes disques...

Bonjour, J'ai lu avec attention les threads decrivant les problemes de LCC eleve avec des disques WD Power Green. De mon cote, j'ai un DS209 avec 2 disques WD de 500Go: WD5000AAKS et WD5000AAJS, ce sont des Caviar Blue, et pas des Power Green. Pour tester l'hibernation, j'ai descendu la periode a 10 minutes dans l'interface web de gestion du Syno. Les disques semblent hiberner correctement si j'en crois les logs dans /var/log/messages (et syno_hibernate). Par contre toutes les 10 minutes, j'entends un petit bruit metallique qui me fait penser au parquage des tetes, et j'ai observe que le LCC augmente de la meme facon (+1 toutes les 10 minutes). Ca ne semble donc pas etre le meme pb que celui decrit pour les disque Power Green, mais quand meme ca m'intrigue. D'autres sont dans le meme cas que moi? Des idees? Merci

Bonjour, J'ai essaye de me rendre a l'avis des sages .. J'ai donc vire estmp et postfix d'ipkg et installe mailstation, et cree a la main /usr/sbin/sendmail qui n'existait pas. Apres quelques essais infructueux avec mutt, je me suis rendu compte qu'il semble plutot chercher /opt/sbin/sendmail, j'ai donc rajoute un autre lien vers le sendmail de mailstation. Mais voila.... quand j'essaie de m'envoyer un mail sur mon compte @free.fr, je ne recois rien (oui, le port 25 est ouvert en sortie, mais pas en entree, pour l'instant je n'ambitionne pas de recevoir du mail de l'exterieur sur le syno) (ceci dit ca ne marche pas non plus quand j'essaie de m'envoyer un mail en local avec "mutt root" par exemple) J'ai essaye sendmail en direct, ca ne marche pas mieux. Pour la config de MailStation, j'ai juste renseigne mon nom de host (DynDNS - ce n'est pas un nom de domaine), et active SMTP. J'ai fait un test avec Webmail qui a fonctionne, puis je l'ai desactive. Qu'est ce que j'ai rate? Je n'ai pas trouve de logs :-(

Bonjour, J'ai vu que plusieurs d'entre vous utilisent postfix. Ma question est: utilisez-vous celui installable via ipkg ou celui qui fait partie de mailstation? Quand j'essaie d'installer avec "ipkg install postfix", je n'obtiens que des erreurs: Configuring postfix creating new user(s) and group(s) ... failed changing permissions of /opt/var/spool/postfix/* ... chown: unknown group name: mail chown: unknown user name: mail chown: unknown user name: mail ok changing permissions of /opt/sbin/post* ... ok En effet, dans /etc/group j'ai: postfix:x:125:postfix maildrop:x:126: je suppose que ces lignes viennent avec l'install initiale du Synology? La presence de maildrop explique le 1er message d'erreur. Ensuite, les chown mail qui echouent sont dus a l'absence de user "mail". Je suis surpris qu'il y ait de telles erreurs lors de l'installation. Suis-je le seul?

OK Je vais regarder ca. Ca devient un peu off-topic, mais j'ai continue a jouer avec tout ca... Si je faisais nail root , aucun mail n'arrivait, c'est a dire que nail n'etait pas capable d'expedier un mail (jusqu'a present, on avait juste teste sa capacite a lire un mail achemine par esmtp(aka sendmail)/procmail). Je n'avais pas fait attention que lors de l'installation de nail, j'avais le message Usage of sendmail is disabled in this version of nail due to missing sendmail-package. nail is capable of using SMTP, read http://nail.sourceforge.net/man/nail.1.html to learn more about its usage. alors meme que esmtp est installe, et est capable de se substituer a sendmail dans les cas simples. (c'est peut-etre un bug du package nail, ou de esmtp, a verifier....) Ceci explique que nail n'est donc pas capable d'appeler le sendmail installe localement, meme pour envoyer du mail local. Par contre, si dans /opt/etc/nail.rc, je rajoute set smtp=smtp://smtp.free.fr set from="nom.que.je.veux@free.fr" alors nail est capable de se connecter au serveur SMTP de Free, mais ne pourra bien sur pas acheminer ainsi des mails locaux. Mais ca marche pour envoyer des mails a l'exterieur! (il est important de forcer le champ from avec une adresse externe, sous peine de rejet par le serveur SMTP) Les mails recus a l'exterieur paraissent venir de "nom.que.je.veux@free.fr <nom.que.je.veux@free.fr>" Ensuite, j'ai essaye mutt, qui est plus evolue que nail. Par defaut, il est capable d'envoyer du mail localement, en appelant sendmail (esmtp dans mon cas). Cela fonctionne grace a la directive "mda" dans la config de esmtp (/opt/etc/esmtprc). Mais esmtp est egalement capable de se connecter a un serveur SMTP pour les mails vers l'exterieur, il suffit d'ajouter dans /opt/etc/esmtprc: hostname smtp.free.fr:25 (il est important de preciser 25 dans le cas de Free, sinon il tente de se connecter au port 587, ce qui est apparemment dicte par la RFC 2476, mais pas gere par Free dirait-on) Ensuite, il faut expliquer a mutt qu'il doit utiliser une adresse de type xxx@free.fr dans le champ from, lors de la discussion avec le serveur SMTP de Free, sous peine de rejet du mail. Cela s'obtient ainsi: set use_from=yes set from=xxx@free.fr set use_envelope_from=yes set envelope_from_address=xxx@free.fr Je n'ai pas compris pourquoi les 2 champs doivent etre forces, mais un seul ne suffit pas. Cette fois-ci, les mails paraissent venir de root <xxx@free.fr> ce qui est un peu moins joli qu'avec nail. Je n'ai pas encore trouve comment ameliorer cela. Le bilan de tout ca est qu'on peut envoyer des mails locaux et externes, et lire les mails locaux en installant que des petits packages, et sans se lancer dans la config d'un vrai serveur de mail. En resume: - install de cron, esmtp, procmail, nail, eventuellement mutt - cron est alors capable d'envoyer des mails aux utilisateurs locaux (fonctionnement standard de cron, pour l'envoi des messages de stdout/stderr) - par contre, utiliser MAILTO=xxx@free.fr dans la crontab ne fonctionne pas - nail/mutt sont capables de lire les mails locaux Pour l'envoi de mail, c'est un peu plus complique: - nail ne peut pas envoyer de mail vers des utilisateurs locaux, mais peut envoyer des mails a l'exterieur via un serveur SMTP externe - mutt est capable d'envoyer des mails locaux et externes via un serveur SMTP En esperant que ca serve a quelqu'un d'autre que moi....

Apres encore un peu de recherches, j'ai reussi !!! Donc apres quelques coups sauvages de grep dans les binaires (pas encore installe strings), j'ai trouve des choses interessantes. grep mail /opt/sbin/crontab , j'ai vu /usr/sbin/sendmail Or sendmail, fourni par le paquet esmtp est dans /opt/sbin/sendmail Un ptit coup de ln -s /opt/sbin/sendmail /usr/sbin/sendmail et le pb de l'acheminement du mail etait resolu! (le mail va dans /opt/var/spool/mail) Ensuite, nail continuait a me dire que je ne n'avais pas de mail. grep mail /opt/bin/nail | grep / donne /var/mail . La encore, ln -s /opt/var/spool/mail /var/mail a retabli la situation. Ma conclusion est qu'il y a de petits bugs de config des paquets nail et estmp. Comment fait-on pour les signaler?