CoolRaoul

Je ne vois pas tres bien ce qu'ils ont bien pu récupérer étant donné que "synomail" n'était qu'un lien symbolique vers "synobox". [EDIT] J'ai déposé sur pastebin un script perl que j'utillise pour envoyer des mail et qui devrait fonctionner tel quel sur le syno. le voici, si ça peut t'être utile: my_sendmail

Activer temporairement l'option suivante pourrait être utile pour mieux comprendre ce qui se passe:

A tout hasard j’essaierai d'inverser la valeur de l'option suivante (activer si inactive, désactiver sinon):

Il est dans la branche "stable": http://ipkg.nslu2-li...6/cross/stable/ (http://ipkg.nslu2-li...6.17-1_i686.ipk)

Pour ma part, tant que OVH n'aura pas clarifié de façon officielle sa position concernant le support de l'acces Webdav, je ne m'engagerai pas dans l'offre payante. **EDIT** et a ce sujet, lire ici: http://forum.ovh.com/showthread.php?t=78661

Même pas besoin de les vider: "supprimer le raccourci" apparait aussi avec les groupes non vides

Si Synology à décidé de le cacher et de ne pas le documenter (à l'exception de cette simple mention dans les releases notes) c'est peut-être pas un hasard alors.. Tu vas avoir du mal à trouver du support

Pas dans toutes les versions de DSM alors, je suis pourtant en 4.0 et il ne semble pas présent: et pourtant, en effet: http://www.synology.com/releaseNote_enu/DS110j.php bizarre...

Il y a encore 20 mn je n'avais jamais entendu parler d'eaccelerator C'est un composant pre-installé dans DSM?

Une rapide recherche m'a permis de trouver ceci (https://eaccelerator.net/ticket/104): Il semble que tu utilises une version de eaccelerator compilée avec l'option '--with-eaccelerator-use-inode'. Donc la replacer par une version compilée avec l'option '--without-eaccelerator-use-inode' devrait probablement résoudre ton problème.

Un de tes scripts php fait un "open" dans un répertoire qui n'est pas dans la liste "open_basedir" Ca se règle par ici:

Je tenterai bien un apt-get install cifs-utils[/CODE]

Alors la, aucune idée system peut-être ...

tu y étais presque, Il faut inverser: netstat -t | grep MBP et, si tu veux ne pas tenir compte de la casse: netstat -t | grep -i MBP Tu trouvera ici un (petit) tuto sur le sujet pour débuter: http://www.journaldu...-pipeline.shtml

Tu as raison: faut également ajouter /opt/sbin, oublié (la différence est que la coutume veut que l'on mette dans les répertoires "sbin" les commandes qui nécessitent les droits root et dans "bin" les autres , et comme mount.davfs est dans le premier cas)

Si le motif est authentification" c'est que le dialogue se fait mais qu'il y a un probleme au niveau compte/mot de passe. En tout cas on peut éliminer un problème de connectivité réseau. Est-ce que le compte que tu utilise pour te connecter est bien validé pour utiliser cloudstation? (sur le syno, dans l'application cloudstation , onglet "privileges").

En effet : faut juste remplacer dans "/etc/passwd" "/sbin/nologin" par "/bin/ash" sur la ligne de l'utilisateur concerné. ==> Attention à ne pas merdoyer lors l'édition de /etc/passwd: une incohérence sur les entrées root ou admin peut rendre toute connexion au syno impossible (et même jusqu'a interdire le redémarrage)

Faudrait au moins essayer de comprendre comment parler de "bricolage" peut parfois être blessant. Si, par exemple, dans mon boulot, mon chef traitait ainsi mon travail, ce ne me ferait franchement pas plaisir. Je ne pense pas: le changement du PATH s'applique exclusivement aux process interactifs (puisque effectué dans "/etc/profile" et/ou "/root/.profile"). Pour les process système (lancés par cron ou au boot ou indirectement par d'autre process système) l'installation d'ipkg n'a aucun impact. (alors qu'ajouter ou upgrader des modules au perl natif de DSM comme tu cherche a le faire avec cpan pourrait en avoir :-> ) Et de plus, rien n'oblige à ajouter /opt/bin au PATH par défaut pour les shells interactifs: suffit d'ajouter explicitement cette définition dans les scripts dans lequels on à besoin d'avoir accès à des commandes ajoutées par IPKG. (et personnellement je m'abstiens à quasi systématiquement coder le PATH en dur dans tous mes scripts pour éviter les mauvaises surprises). C'est peut-être le cas sur les modèle de la gamme à base d'architecture intel comme le tien (bien que cela m'étonne quand même quelque peu), mais je peux t'affirmer que sur les plate-formes à base ARM ce n'est absolument pas le cas. Sur ces dernières, à l'exception d'un script (/etc/rc.optware), rien n'est installé ailleurs que sous "/volume1/@optware". Et les mise a jour de firmware ne touchent pas à ce répertoire. Et donc, en cas de mise a jour de firmware, suffit simplement de restaurer une sauvegarde de rc.optware, rétablir son invocation dans rc.local et éventuellement, si on le souhaite, d'ajouter /opt/bin au PATH dans les profiles pour que ça roule. **EDIT*** Au temps pour moi pour la remarque ci dessus hors de propos dans cette réponse: j'ai confondu avec un autre contributeur du fil.

Si t Tu as fait un spk pour gcc? Je trouve pour ma part plus propre d'avoir une installation optware séparée dans son répertoire "/opt", sans la moindre adhérence avec le firmware officiel, et en laissant intact les listes des modules visibles par le perl intégré nativement dans DSM. Chacun son approche, (pour optimiser ses chances d'être aidé dans un forum, mieux vaux commencer par éviter de dénigrer les choix des autres..)

ben non: suffit simplement d'installer le package ipkg perl de la meme façon que tu as installé gcc c'est ce que j'ai fait.

pas tout a fait le meme probleme en fait, mon syno a un CPU arm, j'avais du creer ce symlink: /opt/bin/arm-none-linux-gnueabi-ld -> ../arm-none-linux-gnueabi/bin/ld [/size][/CODE] pour régler des erreurs similaires Mais comment se fait-il que ce soit dans "/usr/local" que ca se passe chez toi? Est-ce le perl natif du syno que tu veux étendre ou celui de optware (installé par ipkg). Pour ma part j'ai préféré laisser intact le perl "natif" (/usr/bin/perl) et installer le perl optware (/opt/bin/perl) afin d'étendre ce dernier Voici un extrait de sa config: [font=courier new,courier,monospace]Characteristics of this binary (from libperl): Compile-time options: PERL_DONT_CREATE_GVSV PERL_MALLOC_WRAP USE_LARGE_FILES USE_PERLIO Built under linux Compiled at Mar 16 2012 04:49:07 @INC: /opt/lib/perl5/5.10.0/arm-linux /opt/lib/perl5/5.10.0 /opt/lib/perl5/site_perl/5.10.0/arm-linux /opt/lib/perl5/site_perl/5.10.0 [/font]

**HS** A ta place le relogerai le ".cpan" (par un symlink) ailleurs que dans "/root" (la place est comptée sur le file system "/" et .cpan peut beaucoup grossir au fil des mise a jours.)

Absolument: l'environnement des scripts lancés au boot (et en cron) n'exécute ni /etc/profile ni /root/.profile (ces derniers étant comme dans tout unix destiné aux shells interactifs) . Je conseille toujours de mettre le PATH en dur (et donc ici /opt/bin pour optware) dans les scripts: il n'est jamais bon de faire dépendre un script de son environnement hérité. Ce dernier qui peut être tres variable suivant le contexte (cron, startup, ssh <commande>, shell interactif, CGI,...) ou il est invoqué

Le backup standard fait bien une copie incrémentale, mais tu ne disposera pas d'un clone de ton disque HD1 sur le disque HD2 si c'est ce que tu souhaitais au départ. Tous les dossiers sources sont sauvegardés dans un sous dossier du dossier de backup cible L'important est d'avoir des sauvegardes, non ? La on dirait que tu veux avoir simultanément les avantages du raid miroir (limiter les temps d'arret de service en cas de panne disque) et ceux de la sauvegarde différentielle sur un volume séparé (sécurité des données en cas de corruption de volume) Ce n'est pas possible à ma connaissance.