CoolRaoul

Quel modèle ?Un collegue ne semble pas avoir le problème sur son DS212, sur mon DS210J c'est franchement catastrophique

par "rien" tu veux dire meme pas le prompt "username" ?

J'ai aussi constaté cela, uniquement en HTTPS. C'est pas limité a DSM, shellinabox rame a mort en https aussi On dirait que le moteur de cryptage matériel n'est pas utilisé par SSL en 4.2

pourquoi?

C'est par ça qu'il aurait fallu commencer, donc oui! Et si ça ne marche toujours pas, activer temporairement telnet sur le syno S1 et essayer de se connecter en telnet ("putty -telnet", ou simplement avec la commande telnet) avec le PC connecté de la même manière.

As-tu un moyen de t'assurer que le démon sshd de s1 est bien actif et est a l'écoute sur le port 15632 ? Un moyen d'avoir un acces *direct* à S1 (sur place, étant connecté au mème lan) ?

(Pas bien compris les différences de fond entre les deux derniers tests: si la connexion S2 -> S1 sort en timeout ça le fera quelle que soit la façon dont on est arrivé sur S2, directement ou en faisant un aller/retour) Cela dit, il serait intéressant de savoir si tu parviens à te connecter sur S1 à partir d'une *autre* équipement que S2. As-tu fait ce test?

Tu est bien connecté "root" ? (je viens de vérifier, je suis en 4.2 et aucun problème sur le chmod)

Ok dans ce cas, ça revient au même alors, mais ça n'explique pas ce qui s'est passé sur le serveur dhcp du routeur pour allouer ainsi une adresse différente.

Quel rapport avec les NAS Synology? **EDIT** Grilled!

De toutes façons, avec un erreur de type "timeout" ça ne peux pas être un probleme de clé

Non, dans ce cas le probleme est ailleurs

je pensais au firewall intégré au Syno

Il y aurait peut être une piste (un peu tordue je reconnais) mais, attention, je n'ai pas testé. Bien que l'interface DSM permet de mettre des quotas uniquement au niveau de l'utilisateur, la commande "setquota" (/sbin/setquota) supporte les quotas de groupes (cf setquota --help) Par conséquent, en créant un groupe dédié à cet usage, il devrait être possible, en forcant le groupe pour les dossiers/fichiers créés dans le dossier (chgrp le groupe le_dossier ; chmod g+rxxs le_dossier), en limitant l’accès au dossier aux membres du groupe (chmod "o=" le_dossier) et en ajoutant au groupe les utilisateurs autorisés à accéder au dossier, de positionner un quota sur le groupe (avec la commande setquota) et aboutir à l'effet souhaité. Mais je le répète, ce ne sont que des hypothèses à tester!

Avec un message "Connection timed out" tu es certain qu'il ne s'agit pas d'un probleme de clés déja La connexion tcp est bloquée quelque part entre les deux syno J'imagine que ta config est dans ce genre: [s1] <--> [routeur 1] <---> (internet) <---> [routeur 2] <-> [s2] Déja vérifier si le firewall de s1 n'aurait pas blacklisté l'ip de routeur2 par hasard Essayer aussi en désactivant le firewall de S1

Peut-être une extension (adblock ou un truc dans le genre) Essayer de démarrer Firefox en mode sans echec, comme ceci:

J'avais lu un peu vite sans réaliser que l'objectif était de conserver les ACL entre DSM et un *autre* Linux DSM gère les ACL avec une extension "maison" de ext4, synoacl: fserv> mount | grep ext4 /dev/mapper/vol1-origin on /volume1 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl) /dev/mapper/vol2-origin on /volume2 type ext4 (usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl) Par conséquent il n'est possible que de conserver les acl "synoacl" entre deux serveurs DSM (et encore sous réserve de bien utiliser le rsync de DSM). D'un autre Linux vers DSM (ou inversement) ce ne sera pas possible.

Sur quoi te bases-tu pour dire ça? fserv> /usr/syno/bin/rsync --help | grep syno --syno-acl copy Synology ACL data --syno-cmd=FILE Synology customized command from FILE --syno-prog=FILE export progress of rsync transmission to FILE --syno-auth Enable synology authentication machanism --syno-pseudo-root --syno-comp-mode Run rsync as compatible mode

Faut croire que la désactivation de la fonction journal nettoie le répertoire des logs. La commande "/bin/df -h /" te permettra de vérifier que tout est OK C'est plus que probable

Le plus simple est "information systeme", onglet "service", serveur multimedia -> désactiver

Facile, et voici le lieu du crime: 1983 /var/log/lighttpd Tu as du activer a un moment l'option ci dessous: Donc Désactiver l'option (si ce n'est pas déja fait) Arréter mediaserver dans putty, fairerm /var/log/lighttpd/* redémarrer mediaserver ton probleme devrait être résulu **EDIT** Si çà se trouve l’arrêt/démarrage de mediaserver n'est pas utile mais bon, ceinture, bretelles toussa...

Tres bien, Voila qui est intéressant: ta partition système à la bonne taille (ce qui est une bonne nouvelle) mais il y a un truc qui l'a remplie (100% occupée) Va donc falloir trouver quoi Faudrait nous donner le résultat de la commande suivante /usr/bin/du -d 3 -xm /

Il n'est pas futé ce CFE: il veut absolument que l'on utilise le compte admin, c'est codé en dur.

La voix de la sagesse... tu as raison

Me ch** un peu de le faire a distance: normalement ça ne devrait pas poser de problème mais je ne suis pas à jamais a l'abris d'une couille dans un de mes scripts de démarrage eu reboot.