CoolRaoul

***EDIT*** J'ai du redémarrer le syno pour pouvoir créer un volume supplémentaire apres la manip

En fait c'est possible (je viens de le tester dans un émulateur) mais risqué. Voici un exemple de manip pour réduire la taille du volume1 en ligne de commande (j'ai pris 5gigas comme exemple, remplacer "5G" dans la suite par la taille souhaitée) : $ # ignorer les erreurs pour les 3 commandes suivantes $ /usr/syno/etc/rc.d/S20pgsql.sh stop $ /usr/syno/etc/rc.d/S80samba.sh stop $ /usr/syno/etc/rc.d/S83nfsd.sh stop $ # a partir de la ne pas continuer en cas d'erreur $ umount /volume1 $ e2fsck -f /dev/vg1/volume_1 $ resize2fs /dev/vg1/volume_1 5G $ lvm lvreduce -L 5G /dev/vg1/volume_1 WARNING: Reducing active logical volume to 5.00 GB THIS MAY DESTROY YOUR DATA (filesystem etc.) Do you really want to reduce volume_1? [y/n]: y Reducing logical volume volume_1 to 5.00 GB Logical volume volume_1 successfully resized $ mount /volume1 Tu devrais maintenant pouvoir créer un nouveau volume.

Il y a une différence: un volume group peut être étendu en lui ajoutant des disques supplémentaires (sur un NAS 4 baies ou plus par exemple). Mais dans ton cas ça revient au même en effet.

Daprès ce que je lis dans ce post je ne pense pas non Et ici aussi: http://forum.synology.com/enu/viewtopic.php?f=19&t=52387#p200466

Si la case "create" n'est pas disponible c'est parce que tu as affecté au premier volume que tu as créé dans le groupe la taille *totale* disponible dans le groupe. Par conséquent il ne reste plus suffisament de place libre pour un nouveau volume.

Bof, c'est inévitable dès lors que si ton port SSH est visible sur le net. Le blocage auto doit jouer son rôle (s'assurer qu'il est bien activé) Quelques pistes pour limiter la visibilité de ton NAS en ligne: utiliser (via la redirection de port de ton routeur) un autre port que le 22 pour le service ssh mettre des règles firewall, spécifiquement sur le port 22 limitant les ranges d’adresses aux sources "amies" et connues de toi. activer ssh que quand necessaire

Et parmi les problèmes signalés dans ce fil, quel était le tien ? **edit** mea culpa: je n'était pas allé jusqu'a la page 1 du fil

Normalement, si il t'a rendu le prompt ("DiskStation>") c'est que l'indexation est arrétée

Cela n'a pas de sens: si c'est la livebox qui met a jour l'enregistrement NOIP, non seulement le Synology ne peut pas être au courant qu'il est connecté à ce service DDNS mais encore moins senregistrer dessus! A moins que tu ait configuré ton compte NOIP sur le Syno *et* sur la Livebox (mais dans ce cas pourquoi?) Commencer par désactiver le firewall pour réparer le problème de connexion (inutile d'empiler les couches quand on est en phase d'investigation de problème). Il sera bien temps de le re-activer lorsque la connexion sera rétablie. "grilled" sur le fil

Faire comme ceci dans ce cas: sh /usr/syno/etc.defaults/rc.d/S66synoindexd.sh stop

probablement pas connecté root?

Suffit de respecter le formalisme correct pour spécifier sous réseau/masque: dans l’adresse de sous réseau, les bits ne correspondant pas aux bits du masquent doivent être à zero. Tu peux t'aider de ce tres pratique petit soft: "Advanced IP Calculator", à télécharger ici: http://www.radmin.fr/products/utilities.php ***EDIT*** Oups, je viens de réaliser ton probleme, en effet avec les bits a 0 c'est refusé! ***EDIT #2*** Ce qui est refusé en fait c'est le dernier octet à zero il me semble, pas terrible ***EDIT #3*** Ouvert un ticket de support pour signaler le bug,

Ah oui, bien vu

Il n'y a que moi que cela choque ??? Alors je suis d'accord que cela doit marcher, mais quand on est dans une situation ou ça ne marche pas, autant éviter les redirections tarabiscotées et inutiles .... Donc d'abord essayer une redirection toute simple 5000 -> 5000 et taper http://mon nom d'hote:5000 Je me demande si il ne s'est pas simplement mal exprimé en voulant faire un raccourci, et que cette ligne correspond en pratique a deux redirections distinctes: 5000 -> ip_locale_syno:5000 et 5001 -> ip_locale_syno:5001

Un truc me chiffonne: c'est la livebox que tu utilises comme client dydns (pas de problème avec ça à priori) mais tu écrit "le syno a chaque démarrage me dis que l'adresse ip est renvoyé à mon compte no ip" Comment s'y prend-t-il pour te "dire" ça? Ca se manifeste sous quelle forme?

Le chemin est "/etc/ntp.conf"

Il est tres courant que les proxys d'entreprise n'autorisent que les connexions vers les port et 443 (parfois 8080) Si c'est le cas, le 5000 doit être bloqué et ne te reste alors que la solution ou

Dernières nouvelles du front: initialement, (juste apres l'update 4.2 donc) mon ntp.conf s'est retrouvé avec le contenu suivant server 127.127.1.0 prefer Une fois activée l'option service ntp, il s'est retrouvé ainsi: server 0.fr.pool.ntp.org minpoll 6 maxpoll 10 iburst prefer Et et redésactivant à nouveau l'option, alors qu'on pouvait imaginer se retrouver dans l'état initial, voila le résultat: server 0.fr.pool.ntp.org minpoll 6 maxpoll 10 iburst prefer restrict default noquery notrust nomodify restrict -6 default noquery notrust nomodify restrict 127.0.0.1 restrict -6 ::1 restrict 0.fr.pool.ntp.org

En effet DSM n'utilise plus la crontab pour la synchro NTP. En outre, après avoir forcé une synchro manuelle, j'ai observé que l'offset était de 236 secondes (pres de 4 minutes), un peu beaucoup à mon avis. En activant la (nouvelle) fonction *serveur* NTP dans DSM, le ntp.conf est mis a jour avec une référence au serveur spécifié dans l'interface et le démon ntpd du syno se met alors en mode synchro NTP "au fil de l'eau". J'ai donc un peu l'impression que si la fonction *serveur* NTP n'est pas activé, les fonctions de synchro en tant que *client* ne sont pas actives. A surveiller.

Si par "toujours d'actualité" tu veux dire est-ce que ça fonctionne à l'identique, la réponse est oui (juste désactiver l'option "SSLCipherSuite HIGH:MEDIUM", qui a pour résultat de faire ramer à mort les connexions ssl, voir ) Ensuite, je confirme que synology.me permet d'utiliser autant de sous domaine que voulu, sans rien a déclarer (ssdomaine1.mondomaine.synology.me, ssdomaine2.mondomaine.synology.me, etc ...)

C'est de notoriété publique cette qualité déplorable du support AFP sur Syno? (suis pas tres au courant, n'utilisant pas de Mac)Aurais-tu des sources? Sinon, tu pourrais vérifier si AFP ne se serait pas amélioré en 4.2, vu ceci: http://www.pcinpact.com/news/76584-synology-dsm-4-2-beta-augmentation-performances-et-support-dairplay.htm **EDIT**etant donné que Synology a annoncé que les performances SMB étaient améliorées avec la 4.2, si tu rencontre une baisse, il faut que tu ouvre un ticket de support, ce n'est pas normal

Quel intérêt de faire du SMB sur Mac ?

Pourquoi pas, j'aimerai bien comprendre ce qui coince: je viens de faire deux tests successifs, avec la meme source EPG, avec le perl DSM et le perl optware et je ne reproduis pas l'erreur. Tiens moi au courant PS: pour l'acces au NAS je n'aurais pas besoin d'un compte root, un compte utilisateur lambda sera suffisant.

les commandes de base a connaitre pour utiliser le debugger: pour lancer le script en mode debug: perl -d <chemin du script> <parametres> ensuite: examiner une variable: x <variable> point d'arret: b <No de ligne ou nom de fonction> pas a pas: n continuer c ca devrait suffirt pour un début

Toutes les conversion de temps du format chaine de EPG vers le format interne sont faites par ma fonction "str2time". Si tu maitrise perl, sous debugger, en mettant un breakpoint dans cette dernière, tu peux peut-être voir d'ou viens l'erreur.