CoolRaoul

Chtite question a ceux qui ont déja ouvert une demande de support chez Synology Vous avez été recontacté sous quel délai en moyenne? J'ai déja 3 dossiers ouverts depuis ce week-end et n'ai toujours pas reçu la moindre réponse (mis a part le mail automatique "Thank you for contacting Synology") Merci d'avance

Dans /var/log/messages probablement. Mais j'ai l'impression qu'il s'agit la d'un autre problème Dans les autres cas ça semble se concentrer autour de la sauvegarde de configuration. Le sgi qui est chargé de la manip est "sysconfbkp.cgi" Chez moi son exécution donne: FSERV> /usr/syno/synoman/webman/modules/BackupApp/sysconfbkp.cgi Content-type: text/plain; charset="UTF-8" P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT" x-request-error: system { "errno" : { "key" : "error_system", "section" : "common" }, "items" : [], "success" : false, "total" : 0 } Je serai tres interessé par voir ce que donne cette commande chez ceux chez lesquel le backup et la sauvegarde de configuration reussit

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: