CoolRaoul

Essaie de lancer le démon sshd avec un environnement vierge, comme ceci: env - /usr/syno/etc.defaults/rc.d/S95sshd.sh start[/CODE]

Comme ceci:

Par contre ca ne marche pas dans le cas de dossiers entiers, on obtient le message: Les éléments suivants ne seront pas chargés, peut-être parce qu’il s’agit de dossiers, ou que des erreurs inconnues surviennent :

Pas de problème en DSM 4 (ca marche aussi en 3.X)

Oh, je n'avais pas percuté que tu pensais plutôt au cas de transferts *vers* le NAS qu'en sens inverse! Dans ce cas une solution: installer le plug-in java sur le PC client ce qui va permettre à filestation de visualiser les dossiers locaux *et* distants et donc de déplacer ou copier des dossier entiers. Faudra aussi activer l'option suivante: Sinon, un montage Webdav est aussi une option à envisager

Ben oui,ça vient de sortir: c'est tout frais.

Découvert par hasard, pas testé: http://www.nclone.com/ Permet de faire des sauvegardes/restauration d'images disques stockées sur le NAS en bootant les PC à sauvegarder sur le réseau par l'intermédiaire du Synology Un volontaire pour nous faire un petit test?

Avec file station, après avoir sélectionné le dossier, faut choisir l'action "télécharger" et on récupère une archive zip du contenu du dossier. Est-ce que ça peut faire l'affaire?

Absolument: cela fonctionne en créant automatiquement des hardlinks dans chacun des répertoires de sauvegardes successifs pour les fichiers non modifiés. (bien entendu les fichiers nouveaux ou modifiés sont créés normalement) C'est donc assez économique en place disque tout en conservant un historique complet.

Si on veut reproduire en ligne le comportement de timebackup, une meilleure approche est d'utiliser l'option "link-dest" de rsync. La commande ressemblerait alors à rsync -av --delete --link-dest="<repertoire backups>/<date de la veille>" \ "<repertoire_source>/" \ "<repertoire backups>/<date du jour>" (le "/" apres le répertoire source est important pour que ne soit pas créé un niveau intermédiaire a la destination) La difficulté étant en shell de calculer "proprement" la date la veille A tester: date --date='yesterday' +"%Y-%m-%d"[/code] marche sur un linux "complet". Je ne sais pas si c'est le cas sur le busybox qui fait tourner les Synology (suis pas a la maison pour le moment)

Euh, a ta place je ne serais pas aussi catégorique: La question étant "Je souhaiterais conserver les sauvegardes jour par jour" Je trouve qu'au contraire Timebackup répond *exactement* à cette question. Suffit de configurer le calendrier de la tache comme ceci:

Faudra un jour que tu nous expliques comment tu te débrouilles pour modifier le contenu du fichier de config des vhost *sans* passer par la ligne de commande... Mouais... autant le laisser vide, alors

Le mieux pour toi serait plutôt d'utiliser Time Backup à la place de la sauvegarde traditionnelle.

Que donne la sauvegarde lancée en ligne de commande? /usr/syno/bin/synolocalbkp -a "<nom de la tache de sauvegarde>"[/CODE] (le faire sur une toute petite tache de sauvegarde *locale* créée spécialement) et la sauvegarde de configuration, elle fonctionne?

Regarde un peu voir si ça ne serait pas le même problème

Quand tu autorise l'acces SSH sous DSM c'est le ssh natif que tu actives. Comme je te l'ai dis un peu plus haut, tu as installé par ipkg l'openssh de optware qui s'est automatiquement activé et c'est ce dernier qui répondait à tes connexions sur le port 22. Celui-ci, contrairement à celui intégré à DSM ne fait pas l'équivalence des mot de passe entre le compte "admin" et le compte "root" ce qui explique ton problème. (et ca risque de se reproduire au prochain reboot) A ta place je desinstallerai cet openssh "alternatif" dont tu n'as probablement pas besoin.

Dis nous déjà si tu y a bien déja accès en *local*. Il va falloir modifier la configuration de ta box (si tu accède à internet par ce genre d'équipement). Est-ce que tu sais faire? Si tu es vraiment novice, attention à la sécurité de tes données: n'oublie pas que d'autre que toi risquent également d'avoir accès à *tes* données si tout ça n'est pas correctement configuré. Dans l'interface WEB d'admin du synology il y a une application nommée "file station", dis-nous ça te conviendrai pour accéder à tes données de l'extérieur. Si c'est plutoto avec un smartphone ou une tablette que tu veux accéder, l'approche pourrait être sera différente. Merci de l'indiquer. Dans tous les cas nous indiquer quel type d'acces tu souhaite utiliser: streaming de fichiers audio ou simple téléchargement/chargement de fichiers à distance.

Essaie de refaire les étapes dans l'ordre indiqué par le guide d'installation rapide .

Je vois, c'est le ssh d'optware qui tourne et pas le "natif" de DSM Personnellement je me serai abstenu de mélanger les deux (ou alors en faisant par exemple tourner le second sur un autre port que le 22) Bien, voyons ton probleme maintenant: lorsque tu es connecté "admin", si tu fais "su - root" et tapes le mot de passe admin , qu'est-ce que ça donne? (edit) Je me répond a moi meme: le "su root" ne semble pas fonctionner. ("su: incorrect password") Autre solution: activer (provisoirement) telnet et te connecter root de cette façon.

Je pense avoir trouvé la cause du problème! (sur ma config en tout cas) Faut d'abord savoir que timebackup utilise la crontab pour mettre en place son "scheduling" La commande qu'il insère dans la contab est /usr/syno/bin/timebkp create_version --unique <N> ou <N> est le numéro de tache time backup (peut se retrouver avec la commande "timebkp list_task --name=<nom tache>") Lorsque mes sauvegardes time backup commençaient à foirer , j'avais constaté que l'éxécution manuelle de cette commande reussissait bien à effectuer le snapshot. Par contre les sauvegardes programmées continuaient à planter ("failed to create snapshot") et je n'avais pas trouvé d'autre solution que le reboot. C'est alors que j'ai réalisé qu'il m'arrivait parfois de relancer crond pour qu'il prennent en compte des modifications personnelles de /etc/crontab. Je procédais simplement comme ceci: /usr/syno/etc.defaults/rc.d/S04crond.sh stop /usr/syno/etc.defaults/rc.d/S04crond.sh start[/code] Mais ceci à pour effet de faire hériter à crond (et à toute les jobs qu'il lance) une copie de l'environnement courant du shell. On peut le constater aisément comme suit: [code]ps ex | grep crond[/code] (si on a installé le ps "optware" par "ipkg install procps") J'ai donc essayé de m'astreindre à relancer cron avec un environnement vierge; de cette façon: [code]env - /usr/syno/etc.defaults/rc.d/S04crond.sh start[/code] Et, jusqu'ici, tout fonctionne sans erreur (je croise les doigts)

Depuis la 4.0 le contenu du fichier "/usr/syno/etc/httpd-vhost.conf-user" est analysé lors de la sauvegarde de configuration car c'est dans ce dernier que DSM enregistre sa propre configuration virtual host (accessible par le panneau de conf). Il est possible que le contenu du tien ne perturbe pas l'outil de sauvegarde. En tout cas, chez moi et chez un autre membre du forum, avoir déplacé le contenu dans un autre fichier a immédiatement résolu les plantages de sauvegardes. Ca me suffit pour conclure que la cause est bien cella-la. Je peux t'envoyer en MP le contenu de ma conf vhost si tu veux faire le test chez toi (je viens de reproduire l'anomalie à l'instant) (EDIT) démo en images: root@FSERV > cat /site/etc/httpd/conf.d/vhost.conf >/usr/syno/etc/httpd-vhost.conf-user root@FSERV > /usr/syno/bin/synolocalbkp -b "tst" Segmentation fault (core dumped) root@FSERV > cat /dev/null >/usr/syno/etc/httpd-vhost.conf-user root@FSERV > /usr/syno/bin/synolocalbkp -b "tst" Export confbkp file to : /volume1/@tmp/12527/FSERV_20120409.dss

Apres avoir donné la valeur "2" à l'entrée "BasicAuthLevel" de la clé HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\webClient\Parameters de la base de registre, on peut utiliser le client webdav natif de windows 7 ("connecter un lecteur réseau->se connecter à un site web permettant de stoquer des documents et des images, etc...) (plus de détails ici)

Une autre option pour protéger les pages phpmyadmin des attaques est de mettre un ".htaccess" avec protection par IP, dans le répertoire "/var/services/web/phpMyAdmin/" Exemple, pour moi qui accede à la console phpmyadmin uniquement a partir de mon pc, ça donne: order deny,allow deny from all allow from "ip de mon pc ici"

Ce n'est pas ce que j'ai dit. Je ne comprend toujours pas en quoi l'absence de "cloud station" dans la liste des applications de la config du firewall du syno te pose un problème puisque tu as dis *ne pas utiliser* ce firewall

C'est sur qu'il ne faut pas s'attendre à ce que l'interface de config de ton firewall physique indique "cloud station" en toute lettres ! Donc faut juste y autoriser le port 6990 et le rediriger le port 6990 du syno et ça devrait aller.