CoolRaoul

J'ai meme donné un script en exemple

Ah, pareil que moi, mauvaise piste alors...

Voici: ConnectionMode="" DSID="<une suite de caracteres hexa ici>" client="<nom netbios de mon pc>" db_loc="C:/Users/<mon user windows>/AppData/Roaming/CloudStation/db" password="" port="" proto_version="2" server="" serverID="<mon id ezcloud>" serverName="" session="<une suite de caracteres hexa ici>" user="<mon username sur le syno>" watch="C:/Users/<mon user windows>/CloudStation"

Stp, ça t'ennuyerait d'exécuter la commande suivante sur ta machine et de nous donner le résultat ? /usr/syno/synoman/webman/modules/BackupApp/sysconfbkp.cgi[/CODE]

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

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

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

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

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'

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.

5000 Megas, autrement dit 5 Gigas Bigre! Mais bof, qu'est-ce que 5 gigas de nos jours...