CoolRaoul

DS210 (88FR131) pour ma part:

Bon j'avance, Je suis parvenu à intercepter la commande utilisée par le backup: root 24863 1 0 21:15 ? 00:00:00 /usr/syno/bin/synolocalbkpd -D root 1974 24863 0 21:28 ? 00:00:00 \_ sh -c /usr/syno/bin/synolocalbkp -b "My Backup Set 1" > /dev/null 2>&1 root 1975 1974 26 21:28 ? 00:00:00 \_ /usr/syno/bin/synolocalbkp -b My Backup Set 1 Et, en lançant a la main: FSERV> /usr/syno/bin/synolocalbkp -b "My Backup Set 1" Segmentation fault (core dumped) ==> mais pourquoi envoyer la sortie d'erreur vers /dev/null (> /dev/null 2>&1) et pas dans un fichier log???

Je viens de découvrir un truc qui me fait deviner un bug bien tordu: Lorsque tente de lancer un backup (bouton "sauvegarder maintenant"), il échoue et je trouve un fichier nouvellement créé dans "/dev" nommé ... "ull" ("dev/ull" donc). (vérifié en supprimant ce "ull", lancant le backup pour constater que le fichier est de retour !) Bien entendu j'ai essayé de feinter en créant un lien symbolique de "/dev/ull" vers "/dev/null"), sans succès.

Non, rien d'aussi exotique. Uniquement des packages officiels.

J'ai sauté l'étape 2197 pour ma part. M'étonnerait que ce soit la cause. Dans ton cas il s'agit bien de backups locaux, tu confirmes? Bon, j'ai ouvert un dossier de support, on verra.

(message déplacé, m'était trompé de fil) J'ai voulu feinter en activant le service network backup et en créant un backup set de type network avec pour destination "localhost" Ca plante pareil hélas...

Essayer de désactiver jumbo frame si c'est activé, juste pour voir.

Trouvé une piste: Pour le client windows, dans le dossier "%APPDATA%\CloudStation\conf" se trouve un fichier nommé "client.conf" dans lequel se trouve la ligne suivante: port=""[/CODE] je te laisse tester tout ça a titre d’exercice

J'ai voulu feinter en activant le service network backup et en créant un backup set de type network avec pour destination "localhost" Ca plante pareil hélas... Oups, mauvais fil => message déplacé...

Il serait déjà intéressant de savoir si certains sont capables d'avoir des backups locaux fonctionnels en 4.0. C'est ton cas?

En attendant que Syno nous sorte un fix, je me suis bricolé un petit script de sauvegarde "quick and dirty" Si ça peut dépanner certains: #! /bin/sh PATH=/bin:/usr/bin:/usr/syno/bin # 3 lignes suivantes a customiser srcdisk="/volume1" targetdisk="/volume2" target="$targetdisk/backups/LocalBackup" for dir in $( ls $target | sed -e 's@^.*/@@') ; do [ -d $srcdisk/$dir ] || continue echo "backup of $dir" >&2 rsync --archive --hard-links --syno-acl "$srcdisk/$dir" "$target" done EDIT: j'avais oublié de supprimer le parametre "dry-run", un restant de mes test.

Avec tous ces problèmes, je vais bientôt regretter d'avoir fait l'upgrade 4.0 moi. Comment se fait-il que des choses aussi vitales n'aient pas été découvertes pendant la phase beta?

+1 pour moi zut alors!

La solution est ici

J'ai rencontré le meme probleme Dans la log (/var/log.messages) j'avais ces erreurs lors de chaque connexion VPN Entrante: pptpd[24621]: CTRL: Client <IP> control connection started pptpd[24621]: CTRL: Starting call (launching pppd, opening GRE) pppd[24622]: /usr/local/synovpn/lib/pppd/2.4.5/radius.so: cannot open shared object file: No such file or directory pppd[24622]: Couldn't load plugin /usr/local/synovpn/lib/pppd/2.4.5/radius.so pptpd[24621]: GRE: read(fd=9,buffer=1bd25,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs pptpd[24621]: CTRL: PTY read or GRE write failed (pty,gre)=(9,10) pptpd[24621]: CTRL: Reaping child PPP[24622] pptpd[24621]: CTRL: Client <IP> control connection finished Je m'en suis sorti en desinstallant et reinstallant le package VPN

Bon apparement c'est pas encore tout a fait au point. Il y a des bugs dans les scripts de démarrage de syslog et j'ai aussi le sentiment que l'interopérabilité entre le package "syslog server" d'une part, le /sbin/syslogd de base et le syslog-ng intégré à DSM de l'autre n'est pas encore complètement "fluide" exemple: FSERV> /usr/syno/etc/rc.d/S22syslogng.sh start Syslog-ng server start... sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand sh: or: unknown operand Trouvé la source du bug dans "/usr/syno/syslogclient/scripts/runscript.sh" if [ -n "${fac}" ]; then if [ -z ${SYSLOGNG_FAC_FILTER_STRING} ]; then SYSLOGNG_FAC_FILTER_STRING="program(${fac})" else SYSLOGNG_FAC_FILTER_STRING="${SYSLOGNG_FAC_FILTER_STRING} or program(${fac})" fi fi Il aurait fallu des quotes autour de "${SYSLOGNG_FAC_FILTER_STRING}", comme ceci: if [ -z "${SYSLOGNG_FAC_FILTER_STRING}" ]; then[/code] J'ai ouvert un dossier de support chez Synology, on verra bien

Peut-être en CPL ?

Le protocole Cloudstation ne s'appuie pas sur du http, par conséquent derrière un proxy faut abandonner tout espoir. Non ce n'est pas possible.

Dans les réseaux d'entreprise, en général *tous* les ports sont fermés a l'exception du , du 443 et parfois du 22. Comme ces derniers sont déjà utilisés par des services standards, je ne vois pas trop ce qu'il serait possible de faire pour satisfaire ta demande

Conditions a remplir: Le port 6690 du Syno doit être accessible de l'extérieur (via règles dans la box) Ne pas oublier de l'autoriser dans le firewall si celui-ci est activé: Le Synology doit être accessible de l'extérieur avec un nom permanent (type dydns) à moins que vous disposiez d'une IP fixe. et ensuite on se connecte à cloud station en donnant son adresse à la place de l'ID:

Dans ce cas vaudrait peut-être mieux t'abstenir, tu risque de faire des dégats en faisant des choses sans comprendre. "cache_dir" n'est pas une commande. Que cherches-tu a faire en tapant ça? Pour vérifier que le répertoire est créé il faut taper, par exemple: ls -ld /opt/var/cache/davfs2[/CODE] Peux-tu nous dire comment tu t'y es pris pour modifier le fichier '/opt/etc/davfs2/davfs2.conf'

Simplement cliquer sur le nom et commencer à taper:

D'après les retours dans ce forum et celui de Synology (ainsi que ma propre expérience, mais je n'ai pas testé toutes les configurations possibles) il semble bien que la réponse soit positive.

Qui aurait une idée sur (ou déja rencontré) ce problème? Lorsque je me connecte à l'interface d'admin http Syno à partir de mon taff (ou je passe par un proxy), lorsque certains applications DSM sont actives (interface syslog par exemple) Chrome se met par moment à consommer du cpu en permance (un core pour lui tout seul). J'ai essayé en désactivant toutes les extensions sans plus de résultat. Pas de problème par contre avec d'autres navigateurs (IE, Opera ou Firefox) Je n'ai rencontré ce problème qu'avec DSM jusqu'ici

A l'occasion de la sortie de DSM 4.0 je me permet un petit "up" sur ce sujet Il n'est désormais plus necessaire d'editer "/usr/syno/etc/synosyslog" en se connectant en ssh (ou telnet) sur le syno Cela se fait directement dans l'interface d'admin. dans le panneau de configuration sélectionner ce qui nous donne: Dans le champ "serveur" mettre l'IP du serveur syslog (dans l'exemple ci dessus on redirige sur le package syslog installé en local) L'onglet "filtre de journal" permet de choisir quelles catégories d’évènements sont propagées.