CoolRaoul

Il s'agit d'ouvrir des ports dans un *routeur*, si ça ne fonctionne pas c'est un probleme de compatibilité avec le routeur, les bornes wifi ne sont pas en cause.

Moi aussi et j'avais d'ailleurs ouvert un dossier avec le dev sur ce problème, et puis c'est subitement tombé en marche et j'ai laissé tomber.

Il y a des exceptions, vérifier la liste de compatibilité ici

Pour cela il faut que l'option de téléchargement soit activée (c'est une option globale). Se connecter à Photostation avec le compte admin (ou un compte membres du groupe des administrateur) Cliquer sur "Paramètres": Choisir "photos": Cocher la case: Ensuite les utilisateurs connectés disposerons de l'option de téléchargement de photos de individuellement ou par album (uniquement celles auxquelles ils ont accès en visionnage bien entendu) NB: j'ai trouvé ça dans l'aide intégrée:

Regarde dans le journal du syno, tu verra sans doute l'explication de l'erreur

Ici les symptômes constatés semblent indiquer que la culpabilité est à chercher du coté de ES Explorer: Dans la rubrique réseau->FTP j'ai entre autres une définition de connexion sur mon NAS qui fonctionne. J'en crée manuellement une autre, *strictement* identique, et sur celle-la: "Erreur, impossible de trouver le serveur FTP"" D'ailleurs, pour en avoir le cœur net je viens d'installer Total Commander et son plugin webdav et, là, la connexion au NAS s'est faite du premier coup (même user et config, https, port 5006).

Pas s'inquiéter du "ftp" dans le message d'erreur, c'est normal même en webdav, juste le texte du message qui est foireux. J'avais *exactement* la même erreur d'ailleurs, mais utiliser l'IP avait résolu le problème (jusqu’à ce qu'il disparaisse avec le nom aussi) **edit** Si ça peut te rassurer/consoler (biffer la mention inutile), ça me fait exactement pareil en ajoutant une nouvelle entrée pour mon NAS, alors que l'autre entrée déjà présente fonctionne! Bug de ES explorer donc

Avec ES File Explorer je suis tombé sur un bug velu pour la connexion webdav Fonctionnait en donnant l'IP mais pas avec le nom du serveur. Ca vaut le coup d'essayer (si tu as une IP fixe, et apparemment c'est le cas puisque tu es chez free: 81.56.101.184): _> nslookup buteaustation.familyds.org Server: 212.27.40.240 Address 1: 212.27.40.240 dns1.proxad.net Name: buteaustation.familyds.org Address 1: 81.56.101.184 bro67-1-81-56-101-184.fbx.proxad.net **EDIT**Par contre je n'ai plus ce bug maintenant

Merci pour tous ces détails Un de ces jours j'avais bien envie de me faire plaisir (ce n'est pas que j'en ai vraiment besoin ...) avec un modèle 4 Baies, mais le différentiel de consommation avec mon DS213j (donné pour moins de 4Watts en idle, hors conso disques! (*) ) me chiffonne un peu (http://www.synology.com/fr-fr/products/compare_products/DS415play/DS213j) (*) à moins que ce soit une coquille?

Non; ce que je veux dire c'est quand le système ne fait pas de transfert de données (en gros pas d'utilisateurs connectés, quelque soit le service) mais pas en hibernation pour autant

Oups, les 2 baies supplémentaires (par rapport à la 213play) ça met un coup à la conso électrique. **EDIT** Synology ne communique que 2 valeurs pour la consommation: "accès" et "hibernation du disque dur", serait intéressant d'avoir un 3ème, en mode "idle": pas d"hibernation mais pas d’accès non plus. Cette info est-elle disponible quelque part?

Non, le dossier restera crypté. Le reset permet juste de remettre à zero le mot de passe du compte admin. En plus en désactivant l'option "monter automatiquement au démarrage", quelqu'un qui vole le syno avec ses disques n'aura aucun moyen d'accéder au contenu crypté, même si il connait le mot de passe d'un des comptes ayant accès au dossier crypté. (a vérifier, mais le reset hardware doit normalement effacer le mot de passe du montage auto) Tous les détails ici: http://www.synology.com/fr-fr/support/tutorials/455

Et pourquoi ne pas avoir simplement essayé ? "Panneau de configuration" -> "dossier partagé" -> sélectionner le dossier -> "modifier" -> "emplacement" et le tour et joué.

Pour la "recherche par appliance" comme vous avez demandé, faut aller dans l'onglet "autres serveurs" ("others servers"), et là on a le filtre détaillé

/var/packages/MariaDB/scripts/start-stop-status stop suivi de /var/packages/MariaDB/scripts/start-stop-status start devrait sans doute le faire

Quels champs faudrait-il ajouter selon vous dans le formulaire de filtrage des logs ci dessous pour répondre a votre besoin?

ils sont dans "/var/log/messages", mais par défaut DSM filtre les logs SSH Pour les rendre visibles, j'ai du ajouter un fichier que j'ai nommé "local.conf" (l'important c'est que le suffixe soit .conf) dans le répertoire "/usr/local/etc/syslog-ng/patterndb.d" avec le contenu suivant: #+ # Overrides filter f_messages in /etc/syslog-ng/syslog-ng.conf #- filter f_messages { level (info .. emerg) and not facility(mail, news, cron) and not program(syslog-ng) and not filter(f_local) and not filter(f_synology); }; Ca remplace le filtre par défaut suivant, déclaré dans "/etc/syslog-ng/syslog-ng.conf": filter f_messages { level(warn..emerg) and not facility(auth, authpriv, mail, news, cron) and not filter(f_synology); }; qui empèche les logs "auth" (la classe qu'utilise sshd) d'apparaitre dans "/var/log/message" Faut redémarrer le syno pour qu'il soit pris en compte (en fait le redémarrage du serveur syslog est suffisant mais c'est plus simple comme ça)

Ca ne bloquera pas tout mais ça réduit bien Exemple (et pourtant je n'utilise pas le port SSH par défaut) plusieurs tentatives de login SSH (le blocage d'IP à fait son job) cette nuit de ce gugusse: http://www.abuseipdb.com/check/62.210.188.89 A essayé en utilisant une liste de users/password en ordre alphabétique: Jul 13 06:32:43 fserv sshd[9145]: Invalid user abc123 from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9144]: Invalid user abel from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9138]: Invalid user abby from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9140]: Invalid user abc123 from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9137]: Invalid user a.bogdan from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9139]: Invalid user abc123 from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9142]: Invalid user abc123 from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9143]: Invalid user accounts from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9141]: Invalid user abc123 from 62.210.188.89 Jul 13 06:32:43 fserv sshd[9146]: Invalid user ace from 62.210.188.89 Apparemment il est chez Free mais suis étonné de son reverse DNS (62-210-188-89.rev.poneytelecom.eu) Un allemand a aussi essaye de pénétrer mon VPN, mais sans aller jusqu'a l'identification: Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008] Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: received Vendor ID payload [RFC 3947] method set to=109 Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109 Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [FRAGMENTATION] Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable] Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [Vid-Initial-Contact] Jul 13 04:14:02 fserv pluto[11273]: packet from 85.10.217.54:500: ignoring Vendor ID payload [IKE CGA version 1] Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: responding to Main Mode from unknown peer 85.10.217.54 Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: OAKLEY_DES_CBC is not supported. Attribute OAKLEY_ENCRYPTION_ALGORITHM Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1 Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: STATE_MAIN_R1: sent MR1, expecting MI2 Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both are NATed Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2 Jul 13 04:14:02 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: STATE_MAIN_R2: sent MR2, expecting MI3 Jul 13 04:15:12 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54 #21: max number of retransmissions (2) reached STATE_MAIN_R2 Jul 13 04:15:12 fserv pluto[11273]: "L2TP-PSK-NAT"[21] 85.10.217.54: deleting connection "L2TP-PSK-NAT" instance with peer 85.10.217.54 {isakmp=#0/ipsec=#0}

Trouvé, c'est bien le responsable du site! http://www.nas-forum.com/forum/index.php?app=forums&module=extras&section=boardrules Tout est normal alors!

Pas bien ça de faire les chose sans comprendre le mécanisme ni les implications juste parce que c'est écrit sur un site quelconque.

Faire un reset du syno désactive le firewall (entre autre) (sinon je me demande d'ou vient cette mode depuis quelques semaines d'activer cette redirection auto http -> https qui pose plus de problème qu'autre chose semble-t-il).

C'est pas exactement un problème de vie privée ici: je n'en sais pas beaucoup plus sur celle de ce monsieur après avoir lu sa page Google+ et après tout il ne partage que ce qu'il choisit. Et pour ce qui est de *ma* vie privé, elle n'est pas impactée par cette anomalie non plus. Je trouvais juste étonnant qu'il soit si facile de passer pour un officiel du forum vis à vis de Gmail/Google+ juste en mettant "NAS-Forum" dans son champ "employeur".

Depuis ce matin, gmail affuble les message de notification du forum de la photo d'un gus dont la page Google+ indique que son employeur est "NAS-Forum", ça fait "bizarre"! (Je me demande pourquoi je l'ai flouté car je suppose que beaucoup de membres du forum ont accès à son profil public Google+)

Le serveur IMAP fait partie du package "Mail Server", Mail Station c'est juste le webmail

Bon, il n'y a pas de redirection sur un autre port alors. Tu peux vérifier ici que ton port est bien redirigé: http://www.canyouseeme.org/