CoolRaoul

Tu as sans doute mal positionné les droits (ecritire) sur les dossiers partagés. Essaie aussi d'utiliser même nom d'utilisateur et mot de passe pour windows et pour le syno, ça rend les choses plus simple

Sans parler de la légalité du truc sans doute discutable (on en a déja discuté dans d'autres fils d'ailleurs, je rejoins la remarque de Lelolo sur l'utilisation de la fonction recherche), avec du vieux matos, niveau consommation électrique et nuisances sonores m'étonnerais que sur la durée ça vaille la peine.

Ce que j'ai constaté: En bootant apres avoir enlevé le disque 1 (volume1) le syno redémarre normalement et recrée le dossier @database sur le disque2 (qui continue a se nommer volume2). @database contient la base pgsql dans laquelle se trouvent les stockés les index. Donc ça devrait le faire,

je vais essayer de reproduire tout ça et je reviens

Décidément j'ai vraiment du mal à comprendre ce que tu veux dire

La prochaine fois que cela arrive, avant de ressaisir l’adresse dans le formulaire, pourrais-tu préalablement noter ce que donne la commande "route" quand connecté au syno en console (ssh ou telnet) stp? ***EDIT*** Mieux, des que tu constate l'apparition du problème, effectues *dans l'ordre* les opérations suivantes; Connectes toi en terminal (ssh ou telnet): note l'heure de modification du fichier "/etc/sysconfig/network" (ça pourra donner une indication de quand ça c'est passé) ainsi que son contenu. récupère la sortie de la commande "route" reboote le syno sans rien changer. Si le contenu du champ "passerelle par défaut" est toujours vierge apres le reboot alors tu peux refaire la configuration Rapportes-nous tout ça et on avisera

Si il a été initialisé par le syno oui. Comprend pas bien le rapport avec le fait de booter sur un seul disque, et plus globalement le sens de cette phrase: "j'ai beau déplacer les dossier... /../ il refait l'indexation": c'est justement à cause du déplacement des dossiers qu'il refait l'indexation. Suffit d'attendre qu'elle se termine.

Quand tu dis "les valeurs de ma passerelle disparaissent" doit-on comprendre que le champ "passerelle par défaut" du formulaire panneau de configuration -> réseau devient vide ou bien qu'il est remplacé par une autre valeur (et si oui laquelle?) **EDIT** Tu ne l'as pas précisé mais on peut supposer que ton NAS est bien en IP Fixe?

Comme celui-ci par exemple:

La partition système est automatiquement dupliquée de façon transparente sur *tous* les disques. On peut visualiser la présence de cette partition avec la commande "fdisk -l" Suffit que l'un des disques (n'importe lequel) soit présent pour que le syno puisse booter

très intéressant tout ça, Tenez nous au courant de vos tests

http://fr.wikipedia.org/wiki/Certificat_électronique#S.C3.A9curit.C3.A9_des_syst.C3.A8mes_d.27information

Sous réserve de confirmation, les sous-titres externes ne sont pas gérés par le protocole DLNA.

Lien vers le test: http://www.59hardware.net/articles/stockage-r%C3%A9seau,-nas/synology-ds213j-2013071514509.html Conclusion: "Le NAS Synology DS213j risque fort bien de devenir incontournable dans la gamme des NAS 2 baies économiques et pourrait devenir la référence absolue."

Ben non, tu disais, je te cite: Ce qui est inexact vue que d'origine le serveur utilise bien un certificat (auto signé).

Sous réserve de preuve du contraire, ce message n'indique pas qu'*aucun* certificat n'est utilisé, mais que le certificat présenté par le site ne peut pas être vérifié car il n'est pas signé par une authorité de certification de confiance.

Non, le lien vers l'info à été capturé dans le filet d'un de mes flux RSS d'actus. Mais pourquoi cette question ?

Bon ce n'est pas le premier, mais en plus d'être gratuit, celui-la a l'avantage d'être proposé par un éditeur jouissant d'une bonne notoriété. Rassurant coté support et pérennité. ExtFS : les partitions Linux en lecture/écriture depuis Windows Je n'ai pas testé, tout retour sera donc bien venu

Ben moi je dirai carrément que je ne comprend pas *du tout*, car comme tu le dis, https *implique* certificat, et il y a pas à tortiller: Ref: http://serverfault.com/a/343444

Ben non, elles s'appliquent a tout ce qui arrive sur l'interface ethernet (mais pas aux VPN par contre, faut le savoir). ***EDIT*** Pour reproduire le comportement que tu souhaites (ne pas filtrer réseau local, ce qui me semble raisonnable dans la plupart des cas), suffit d'ajouter en-tête de liste une règle de ce genre: En adaptant le champ "addresse IP" suivant ton plan d'addressage LAN.

Dans ce cas c'est sur l'IP de cet *autre serveur* qu'il redirige, les flux externes sur le port 22 n'ont aucune raison d'aboutir sur le NAS. Pas fermé OK mais redirigé *forcément*: il n'y a pas de miracle, faut bien que le routeur sache vers quel équipement du réseau interne diriger les connexion ssh (tcp/22) venant de l'extérieur et ça ne peut être que toi qui l'a configuré C'est que donc tu as laissé activé le service de sauvegarde réseau ou sftp comme je l'ai suggéré.Hélas, pour une raison qui m'échappe, tu ne veux pas nous confirmer ou pas cette information Tant pis pour toi alors A partir de la ca devient complèment brumeux Tu as déja reussi à décourager Sp@r0 puis Bud, à mon tour d'abandonner maintenant. je me désabonne du fil. Bonne chance quand même.

Oui étonné je suis aussi, vue que "/etc/profile" et "/root/.profile" sont lu uniquement par les shells interactifs, aucune raisonnement rationnel me semble possible pour expliquer ça. Forcément une autre raison

Info complémentaire: ne pas oublier qu'il faudra éditer le fichier de nouveau a chaque nouvelle version de VideoStation (bien qu'ayant signalé le probleme au support Syno, ce n'est bien entendu pas corrigé dans la dernière beta vu qu'ils ont préféré botter en touche comme je l'ai raconté plus haut)

Avec ssh désactivé dans terminal, le service ssh reste actif *uniquement* si sont activés sftp et/ou le service de sauvegarde réseau (mais si c'était le cas, sachant que ces services s'appuient sur ssh, j'ose espérer que tu nous l'aurais signalé). J'ai pris le temps de faire la manip pour être sur de ne pas dire de bêtises. Et même dans cette configuration, toute tentative de connexion en mode terminal est refusée: Donc, à part les messages dans les logs, je ne vois pas de quel ordre peuvent tes "soucis" avec ssh? Si tu ne veux plus voir dans la log les tentatives de connexions ssh, tu n'as qu'a t’abstenir de rediriger le port 22 dans ton routeur! (sans oublier que simplement s'assurer qu'en supplément du service terminal ssh, le service de sauvegarde réseau et sftp sont bien désactivés, aurait le même résultat) Quand au filtrage par le firewall (qui devient inutile avec les précautions ci dessus), une règle comme aurait aussi fait l'affaire: NB: avec les indications partielles que tu ne nous a donné qu'au compte goutte (on ne sait toujours pas quelle est la configuration complète du firewall, quels ports sont redirigés dans le routeur, quels sont les services actifs sur le NAS). on est obligé de deviner entre les lignes et tu comprendra qu'on se lasse un peu à la longue)

Si ssh est désactivé dans les options "terminal" , alors le port 22 est fermé, par conséquent que le firewall filtre ou pas ne va rien changer. Donc je ne vois pas comment ce qu'il ne peut "filtrer pas bien" Essaie de rebooter le Syno et de refaire le scan de ports