CoolRaoul

la prochaine fois je vérifierai avant d'affirmer ! Marche plus chez moi aussi Regression de la 4.2?

Va savoir! le seul élément tangible est qu'il existe des témoignages d'occurrence de ce problème d'indexation lors des updates mais ce n'est pas le cas général La conclusion que c'est lié un élément de configuration que ceux qui sont touchés doivent avoir en commun me semble aller de soi. Ensuite, déterminer *exactement* ce qui est la cause de cette anomalie risque d'être un processus beaucoup plus velu. Dans tous les cas, je ne pense pas que choisir d'attendre pour faire la mise a jour changera quoi que ce soit puisque cela ne semble pas spécifique à la 4.2.

Si c'est, comme le dit Leelou01, un problème "connu depuis longtemps mais qui persiste mise à jour après mise à jour", ça ne te servira à rien d'attendre si ta configuration fait partie de celles touchés. Et, en complément d'info, il n'y a rien de systématique: tout le monde ne se retrouve pas dans cette situation. Pour ma part, je n'ai pas eu droit à cette phase d'indexation infernale lors de ma mise a jour 4.2

Première possibilité, ils ont du être visibles précédemment et Windows les a conservés en cache.Devraient disparaitre apres un reboot. Ou bien, l'utilisateur connecté au NAS a partir du poste windows n'est pas effectivement interdit d'acces au partage En outre, ne pas confondre le droit d'acces au *partage* (qui se gère dans panneau de configuration -> dossier partagé -> privilèges -> configuration des privileges) et les droits d'acces aux sous-dossiers *dans* le partage (filestation -> propriétés -> permissions). En outre, des qu'on a activé les ACL, il devient possible sous file station, de modifier aussi les droits d'acces au dossier racine du partage de façon distincte des droits sur le partage lui-meme.

Faudrait peut-être envisager le cas ou la culpabilité serait coté DVICO, pas compatible avec les évolutions de la couche SMB introduites en DSM 4.2 A votre place, je pense que je tenterais de signaler ce problème au support dvico histoire d'avoir leur avis (à moins que cela ait été déjà fait?), après tout c'est *leur* appareil qui plante.

La nouvelle fonction "rapport" de DSM 4.2 se plante dans les grandes largeurs dans sa rubrique "dossiers partagés" Lorsque la cible contient des fichiers référencés de façon multiples via des hardlinks (et c'est le cas des répertoires cible Time Backup) ils sont pris en compte dans le calcul de la taille autant de fois que d’occurrences même si il s'agit d'un unique fichier en réalité. Résultat des rapports farfelus, avec un dossier dans mon cas dont la taille apparaît supérieure au volume qui l'héberge!

Une solution possible est indiquée ici: http://www.synology.com/support/tutorials_show.php?lang=fre&q_id=484 Plus précisément la partie "3.2 Méthode 2: Copie des données par le réseau"

La plupart des logs sont dans "/var/log", donc un simple find /var/log -type f -mtime -1 permet de trouver plusieurs candidats potentiels. Quant aux packages, ils mettent souvent leur logs dans leur dossier propre, accessible via "/var/packages", donc, pour ceux voulant partir à la pèche: find /var/packages -follow -type f -mtime -1 va ramener quelques candidats (faut faire le tri) ==> Le "-follow" est requis car les packages utilisent souvent des liens symboliques de "/var/packages/nom_du_package/.../chemin vers /volumeN/@appstore/nom_du_package/../autre_chemin Disons qu'on peut les mettre un peu ou l'on veut, suffit de renseigner l'emplacement de son choix dans la directive "ErrorLog"

La deuxième option est la bonne

***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"