CoolRaoul

Me semble bien que "#recycle" n'est pas visible dans le paramétrage de la tache

pourquoi "2" ?? Le service de fichier windows est-il activé au moins? Ca, je serait vraiment étonné que cela puisse avoir le moindre impact sur ton problème

Deux conditions pour ca: Java installé sur le PC Option suivante active dans filestation: Déja c'est mieux de s'y prendre ainsi ainsi pour transférer des fichiers que de passer par file station. Si tu ne vois pas les fichiers il est possible que tu ais mal (ou pas) configuré les privileges sur les partages que tu a créé sur le NAS Dans l'interface d'admin DSM: panneau de configuration->dossier partagé sélectionner le dossier "configuration des privileges"

C'est bien celle-ci ta caméra? As-tu essayé cette config ? Tu peux tenter l'install du firmware FOSCAM pour le modèle FI8918W Faire une demande a partir de cette page: http://foscam.us/tools-support.htm

Reste à espérer que la "manière très light pour que NetBackup ne plante pas" ne soit soudain plus considérée comme suffisamment "light" par une prochaine version de firmware. Et donc, pour la pérennité on ne peut jurer de rien.

Tu as du oublier la premiere ligne du script dans le copier/coller pour avoir cette erreur #!/usr/bin/perl -w (et le nommer "bkup1.sh" est un peu étrange pour un script perl) Voici comment s'y prendre, Dépose le par exemple sous le nom "/usr/local/bin/my_sendmail" (créer le répertoire si il n'existe pas) ensuite, faire un chmod +x /usr/local/bin/my_sendmail[/code] Enfin pour envoyer un mail: [code] echo "corps du message" | /usr/local/bin/my_sendmail -s "<sujet du mail>" -f "<addresse email expéditeur>" -m <serveur smtp> <addresse destinataire> [/code]

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..)