CoolRaoul

Tu m'as mis sur une piste ! apès avoir renommé les deux fichiers /usr/syno/etc/httpd-ssl-vhost.conf-user /usr/syno/etc/httpd-vhost.conf-user qui contiennent ma conf reverse proxy la sauvegarde marche: FSERV> /usr/syno/bin/synolocalbkp -b "My Backup Set 1" Export confbkp file to : /volume1/@tmp/23531/FSERV_20120314.dss au lieu de FSERV> /usr/syno/bin/synolocalbkp -b "My Backup Set 1" Segmentation fault (core dumped) Dans quels fichiers met-tu ta conf reverse proxy?

C'est bien aussi ce que j'aurais envie de faire, mais maintenant que j'ai ouvert un ticket au support, si je remet tout à zero on ne risque pas de trouver la cause du problème. J'attend au moins de voir ce qu'ils vont me proposer.

Quel modèle le routeur? Ne saurait-il pas faire des redirections différences fonction de l'IP entrante?

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]

Si j'ai bien compris tu as mis en place sur ta box une redirection du port 5666 vers le port 5000 de ton syno sur son IP locale. Si c'est bien cela, pourquoi ne pas avoir gardé le même port des deux cotés? Le résultat est que, dans le cas des connexions sur ton lan interne, j'ai bien l'impression que la redirection de port n'est pas faite et que tu vas attaquer ton syno sur le port 5666, qui ne répond pas bien entendu. La solution suivante pourrait marcher: Essaie de rajouter les lignes suivantes lignes au fichier "/usr/syno/etc/httpd-vhost.conf-user" LoadModule proxy_module modules/mod_proxy.so LoadModule proxy_connect_module modules/mod_proxy_connect.so LoadModule proxy_http_module modules/mod_proxy_http.so NameVirtualHost *:5666 <VirtualHost *:5666> ServerName nas.mondomaine.com <-- REMPLACER ici ProxyRequests Off ProxyVia Off <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / http://localhost:5000/ ProxyPassReverse / http://localhost:5000/ </VirtualHost> et ensuite redémarre apache : /usr/syno/etc/rc.d/S97apache-sys.sh restart /usr/syno/etc/rc.d/S97apache-user.sh restart Tiens nous au courant du résultat

Public et anonyme (mais comme tu l'as sans doute remarqué on peut mettre une date d'expiration et/ou un mot de passe)

Avec file station faut procéder comme ceci: ce qui va donner: apres avoir cliqué "partager" tu obtiendra un unique vers le fichier/ A savoir: Ca ne marche pas (a ma connaissance) pour les répertoires. Ca marche pour tous les fichiers, qu'ils soient dans le dossier cloudstation ou pas

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?