Aller au contenu

cellobrutos

Membres
  • Compteur de contenus

    43
  • Inscription

  • Dernière visite

Tout ce qui a été posté par cellobrutos

  1. Je me permets de remonter ce sujet car j'ai ce même problème depuis DSM5 (ça fonctionnait très bien sur 4...). Pour préciser un peu plus, apache masque même dans mon cas le dossier /icons que j'avais créé au bon endroit et le rend parfaitement inaccessible (/mon.adresse.I.P/icons me renvoie sur un 404, alors que le dossier existe bien et qu'il n'est pas particulièrement protégé par un .htaccess quelconque)
  2. Je l'ai retiré de la DMZ et tout rebooté (j'avais même commencé sans la DMZ, que j'ai activée quand j'ai vu que ça plantait). Mais sans meilleur résultat. Le problème de Cloudstation c'est que si je dois en local utiliser 192.168.1.20 et en externe utiliser mon adresse externe, faudra que je change de configuration tout le temps et ce sera chiant.
  3. Je me disais aussi, pour EZ internet... Et donc, euh, non, toujours pas. Le problème, c'est surtout pour cloudstation... si ça synchronise sur 192.168... en local et que je dois changer le paramètre pour synchroniser en extérieur à chaque fois, ça va être chiant. Sinon, le reste, tant pis.
  4. Pour la DMZ: ce n'est évidemment pas pour la prod, mais pour les tests (au moins je suis sûr que ce n'est pas un problème de ports!). Rien dans le pare-feu, et non pas d'EZ internet... je m'y mets! :-)
  5. Ca ressemble à un problème de mdp mais ce n'en est pas un. J'ai vraiment consciencieusement essayé une 40aine de fois en faisant attention à ce que je tape, avec des copier-coller, tout ce qu'il faut. En local ça passe systématiquement, en externe jamais. La box est en DMZ donc tout est ouvert et tout pointe vers le NAS. Mais même en ouvrant un à un les ports dont j'ai besoin, niet.
  6. Ma box est une SFR Fibre. Mais je ne pense pas que ce soit un problème de loopback car j'accède bien au NAS (j'ai la page de login) : par contre, le NAS refuse mon login. J'ai essayé sur plusieurs navigateurs, y compris cache vidé. J'ai aussi essayé en SSH et en FTP... même chose. En SSH, par exemple, ça me dit ssh_exchange_identification: Connection closed by remote host (alors que ça marche vers 192.168.1.20). Le log système me dit user [admin] failed to log in.
  7. Bonjour, J'ai récemment déménagé, et changé de FAI. J'ai bien reparamétré mon nom de domaine vers ma nouvelle IP (qui est fixe), ainsi que le routeur pour qu'il pointe vers mon NAS (DS411+ sous DSM 4.3). Depuis hors de chez moi, tout fonctionne parfaitement. Depuis derrière ma box, par contre, j'ai un problème. Quand je pointe vers 192.168.1.20, j'arrive bien sur la page de login, et je peux me connecter au syno sans problème avec tous mes comptes utilisateurs comme admin. Quand je pointe vers mon.syno.com, j'arrive bien sur la page de login (donc le routeur de la box est correctement paramétré, ainsi que mon hosts). Mais quand je rentre mon login/pwd admin, il est refusé. Même chose avec tous les utilisateurs. Pas de faute de frappe, ni d'IP bloquée. La seule chose qui a changé entre hier et aujourd'hui est le nouveau routeur/box, mais il semble bien pointer vers le NAS, et c'est bien le NAS qui refuse mon login (et encore, seulement quand j'utilise l'adresse externe depuis chez moi), pas la box! Du coup, quelqu'un sait? J'ai cherché, mais rien trouvé... Merci!
  8. AFP (je suis sur mac), et FTP.
  9. En même temps, les freebox sont en bridge… il y a un routeur derrière (une borne airport pour le 1, et un netgear pour le 2, mais le paramétrage est identique modulo quelques ports qui dirigent sur une autre machine chez syno 2 - mais pas les ports liés aux mails (493, 25, etc.)). Pour syno 3, c'est réglé pour les mails.
  10. Ok, je vais regarder avec l'application mail server. Par contre, la freebox est paramétrée exactement pareil chez syno 1 et chez syno 2, donc peu probable que cela soit la cause du problème (sauf si la freebox du Syno 2, une V6, fait plus chier son monde que la freebox du Syno 1, une V5 - quelqu'un a des retours là-dessus?)
  11. Ca, non, je n'ai pas essayé, car je n'ai jamais très bien pigé comment ça fonctionnait… Je peux lire 2-3 tutos si nécessaire et essayer ces prochains jours.
  12. Les versions de DSM ont évolué sur les 2, pas forcément au même rythme. Syno 1 est passé progressivement de 3.x à 4.3 beta sans jamais dysfonctionner. Syno 2 est aussi passé progressivement de DSM de 4.0 à 4.2, sans aucune relation avec le moment où ça ne fonctionnait plus… mais je ne me souviens plus de quelle version fonctionnait et à quel endroit! Peu probable que j'ai updaté le syno en même temps que déménagé et que ce soit précisément à ce moment que tout ait commencé à planter niveau emails. Je pense que ça n'a plus fonctionné depuis qu'il est derrière cette freebox.
  13. Je t'en prie! Alors: - depuis le réseau du syno 2, on peut envoyer tous les emails que l'on veut depuis n'importe quel client que j'ai pu y tester, ainsi que tout webmail. - je n'ai pas testé syno 1 chez syno 2, mais syno 2 était ailleurs avant (derrière une box Bouygues Telecom) et envoyait des emails, de mémoire.
  14. @mickey_mouss : Quand je paramètre le syno 1 avec mon adresse gmail, c'est mon adresse gmail qui sort en "from". Quand je le paramètre avec free, je n'utilise aucune identification, donc aucune adresse de "from". Mais ça fonctionne dans tous les cas sur le syno 1. Je n'ai aucun compte mail rattaché ni à l'abonnement freebox du syno 1, ni à celui du syno 2. Quant au syno 2, il n'envoie pas, quelque soit la configuration, gmail ou free ou autre.
  15. Quelqu'un a une idée? :-/
  16. Bonjour à tous, j'ai un problème avec un DS213j qui saute systématiquement pendant des synchronisations, même locales. 1. le DS213j synchronise vers un DS411+ distant. Ca fonctionne, mais systématiquement, après quelques Go, ça plante. Le message d'erreur est "Network Backup failed to backup task [NICO] to [192.168.1.42]. ([43] Connection to the destination server is timeout. Please check the following and try again:The destination server is connected to a stable network.Backup client and server is busy.)" 2. je ramène tout à la maison, et j'essaie en local. Même chose. Pourtant la cible est correctement connectée, elle synchronise parfaitement 4To de données vers un 3e syno distant depuis des mois 3 fois par semaine avec ajout de plusieurs dizaines de Go à chaque fois, sans aucun problème. 2bis: Si je synchronise de la cible vers la source, aucun problème, tout fonctionne. 3. j'essaie avec un logiciel de synchronisation depuis mon ordinateur, les 2 synos connectés en AFP sur mon mac. Et là, je m'aperçois que c'est mon serveur source qui se "déconnecte" régulièrement, sans raison. Il semble que certains fichiers fassent "planter" la synchronisation d'une manière ou d'une autre. 3bis: dans l'autre sens, tout fonctionne également... 4. même manuellement, sans logiciel de synchro: déplacer des fichiers de source vers cible ne fonctionne pas non plus, ça finit toujours par planter... Du coup, plusieurs questions: - pourquoi???? - comment puis-je régler ce problème? Je n'ai aucun moyen de savoir à l'avance quel fichier va faire planter la synchro, donc pas de moyen d'anticiper. Et comme le programme "sauvegarder et restaurer" sur le syno n'a pas des messages d'erreur très détaillés, on ne peut pas savoir ce qui se passe. Merci BEAUCOUP d'avance...
  17. Je up, au cas où… Quelqu'un a une solution ou ne serait-ce qu'une idée? :-(
  18. @loicb : je n'ai pas à proprement parler de compte email free, donc difficile pour l'authentification... Mais j'ai essayé (avec authentification) avec plusieurs autres comptes, notamment gmail. Le résultat ne change pas: ça fonctionne toujours sur syno 1, jamais sur syno 2. @domlas : Je n'ai rien sur le 465. J'ai pas mal de redirections de ports sur ma freebox, mais c'est uniquement dans le sens "entrant" freebox -> syno, pas l'inverse, si? Dans tous les cas, je n'ai pas plus de redirections sur le port 465 sur l'une ou l'autre des freebox, et pourtant ça passe sur l'une, pas sur l'autre… Dans tous les cas, le message d'erreur "Failed to send mail (Failed to resolve host.)." est indiqué par le syno, donc ce serait bien plutôt le syno qui n'arrive pas à envoyer, et pas un coinçage au niveau du routeur?
  19. Je t'ai parfaitement compris la première fois, j'ai donc du mal m'exprimer, je recommence en simplifiant: Syno 1 et Syno 2 sont tous les deux derrière une freebox. Syno 1 et Syno 2 ont la même configuration exactement, y compris l'adresse "to" (que je cache ici mais qui est absolument correcte). Pourtant, Syno 1 envoie, syno 2 n'envoie pas. Voici, encore une fois, cette fois sous forme d'image directement, syno 1: et voici syno 2:
  20. Sauf que non, derrière une freebox, aucun besoin d'authentification pour smtp.free.fr (cf le lien de loicb, et cf le réglage de mes syno ici (qui marche) et là (qui ne marche pas)). (Dans l'absolu, par ailleurs, je ne vois pas le rapport entre son compte free à lui et le mien, derrière une freebox - je peux envoyer mes propres emails depuis chez lui, ça n'a aucune importance! Sans compter le fait que ni lui ni moi n'avons de compte mail free...) Mais le truc, c'est que ça marche depuis chez moi dans tous les cas avec un compte free, orange, hotmail, gmail, même un email@mondomaine.com chez OVH. Depuis chez mon copain avec la freebox, absolument aucun de ces réglages ne fonctionne. J'ai pris smtp.free.fr pour l'exemple, mais le résultat est le même avec gmail, que je mette son compte, mon compte, le compte de n'importe qui.
  21. C'était aussi mon analyse, et pourtant... Voici la config du syno 1, et voici celle du syno 2 (laissons 3e de côté pour l'instant…). Tous les deux sont derrière une freebox, et ton lien précise bien qu'il n'y a pas besoin d'authentification derrière une freebox de toute façon. L'adresse de destination est bien entendu correcte, et j'ai de toute façon essayé avec plusieurs différentes, sans succès. Le syno 2 me dit "Failed to send mail (Failed to resolve host.).", le syno 1 envoie toujours l'email quelque soit le réglage utilisé (dans la mesure où le réglage est correct bien sûr). J'ai essayé avec d'autres réglages smtp, du genre un smtp.gmail.com, ou en désactivant ssl et avec le port 25, et tout fonctionne toujours très bien sur le syno 1, pas sur le syno 2 (ni syno 3). Donc je sèche...
  22. Bonsoir, J'ai 3 synology, dans 3 endroits différents. Mon problème concerne les notifications par email, qui fonctionnent sur un mais pas sur les deux autres. Syno 1: chez moi, derrière un routeur lui-même derrière une freebox. Les notifications fonctionnent très bien, avec un smtp en smtp.free.fr, port 25, pas d'authentification. Syno 2: chez un ami, derrière une freebox puis un routeur, le routeur redirige tous les ports vers un autre NAS sauf quelques-uns vers le mien (dont le 25). Les notifications ne fonctionnent pas, avec les mêmes paramètres du Syno. Syno 3: chez un autre ami, derrière une Livebox. Aucune notification avec les mêmes paramètres. Question: pourquoi est-ce que cela fonctionne sur le Syno 1 et pas sur les 2 autres avec les mêmes réglages du Syno, et quels sont les choses qui peuvent bloquer? Routeur, box? Comment paramétrer cela correctement? Merci d'avance! François
  23. Bonjour, je rencontre un problème lors de la sauvegarde rsync d'un VPS que je souhaite automatiser. La commande utilisée est : rsync -r -e 'ssh -a' /test user@remote_IP::NetBackup/test Fort logiquement, il me demande le mot de passe du user en question : user@remote_IP's password: puis, un peu plus tard, il me demande cette fois le mot de passe root de mon NAS : Password: J'ai donc d'une part créé une clé afin de ne pas avoir à rentrer le mot de passe du user (root, comme ça je suis tranquille, mais je sais que c'est mal dans l'absolu...), et il ne me demande plus le premier mot de passe. Par contre, il me demande toujours le deuxième. Voici ce qui se passe : rsync -r -e 'ssh -va' /test root@remote_IP::NetBackup/test OpenSSH_5.5p1 Debian-6+squeeze3, OpenSSL 0.9.8o 01 Jun 2010 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug1: Connecting to remote_IP port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/id_rsa type 1 debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048 debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p1-hpn13v11 debug1: match: OpenSSH_5.8p1-hpn13v11 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.5p1 Debian-6+squeeze3 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-ctr hmac-md5 none debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'remote_IP' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug1: ssh_rsa_verify: signature correct debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Offering public key: /root/.ssh/id_rsa debug1: Server accepts key: pkalg ssh-rsa blen 279 debug1: read PEM private key done: type RSA debug1: Authentication succeeded (publickey). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: Sending environment. debug1: Sending env LANG = en_US.UTF-8 debug1: Sending command: rsync --server --daemon . Password: debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0 debug1: channel 0: free: client-session, nchannels 1 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK Transferred: sent 2888, received 2896 bytes, in 2.7 seconds Bytes per second: sent 1070.4, received 1073.4 debug1: Exit status 0 Sur un autre forum plus spécialisé linux où j'ai posé la question, tout le monde s'oriente vers un problème avec ma clé, or je suis sûr que ce n'est pas cela: quand je me connecte en ssh par exemple, il ne me demande aucun mot de passe. Par ailleurs, quand je rsync avec un user qui n'est pas root (et qui n'a donc pas de clé rsa), il me demande bien 2 mots de passe. Enfin, quand j'utilise un user différent (non root), le premier mot de passe demandé est celui du user, et le second le root. Bref, à mon avis, mon NAS demande un mot de passe pour le module rsync, et je n'arrive pas à trouver un moyen de le passer sans avoir à le rentrer, ce qui m'empêche de programmer la tâche en cronjob car cela bute toujours sur ce fameux "2e mot de passe". Ca fait un mois que je cherche, rien de ce que j'ai vu ne semble s'approcher du problème car tous les tutos se focalisent sur la paire de clés RSA, et non sur ce problème de module... Est-ce que quelqu'un sait comment régler ce souci? Merci d'avance!
  24. Salut, je me permets de poser la question ici: comment remplacer le ventilateur CPU? On m'a envoyé (sous garantie) un nouveau ventilateur, je souhaite remplacer l'ancien, mais impossible de déconnecter les 3 fils et d'enlever les 2 "vis" en plastique. Je me demande si je loupe quelque chose... Y a-t-il un guide quelque part, avec des photos ou une vidéo? Merci! F.
  25. Ah, merci! Le mot-clé était donc "migrer", mais à 1h30 du matin... J'ai préféré poser la question car j'ai du une fois envoyer un Syno en SAV, il a été remplacé par un nouveau mais identique, et au retour, en remettant les disques dedans, obligation de formater... Youpi!
×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.