CoolRaoul

L'erreur SMTP 501 signale une erreur de syntaxe, et le "Invalid Sender" indique qu'il s'agit de l’adresse email de l'émetteur. Difficile à croire que DYDNS pourrait être impacté. C'est ton processus d'envoi de mail qui est en faute. Faudrait savoir ce qui a été mis dans le champ "From"

Rajouter la ligne suivante à la fin du fichier: PATH=/opt/bin:$PATH **EDIT** toutefois je ne vois pas ou pouvait bien être l'erreur, me semblait correct ton .profile

Pas de panique! Commencer par nous montrer le contenu de ton ".profile" en s'y prenant comme ceci: /bin/cat .profile et ensuite tu pourras corriger ton erreur de cette façon: /bin/vi .profile

Faudra tenir compte du fait que l'USB du Ds212j est limité à l'USB2, donc les performances risquent d'être un peu juste. S'assurer aussi de la comptabilité (certains disques USB externe on tendance à se mettre en hibernation d'une façon mal acceptée par le NAS)

Même d'occase, ça doit pouvoir se trouver pour pas très cher.

Les attaques reprennent alors que tu a les IP blacklistés dans le firewall et via l'autoblock ? Ce n'est pas la même IP alors?

Et après avoir vidé la corbeille?

Il est possible que (suite au problèmes évoqués justement) le dossier de sauvegarde cible soit corrompu. Essayer de reconfigurer la sauvegarde vers un nouveau dossier, créé par exemple voisin du précédent (sous réserve de suffisamment de place libre dans le volume contenant le partage de destination)

Par le centre de paquets

D’après ce que j'ai pu lire ici, l'UHD86 sait utiliser uniquement le protocole DLNA pour accéder aux contenus multimédias sur le réseau. Donc inutile de créer un compte "livebox" sur le NAS, sachant que DLNA n'utilise pas d'authentification par compte utilisateur. Tout d'abord, si ce n'est pas déja fait, il faut installer et activer le package "serveur multimedia" sur le Syno (à faire avec le centre de packages). Ensuite, ppour que les fichiers multimédias soient visible par les clients DLNA, faudra qu'ils soient situés dans un des dossiers (ou l'un de leurs sous-dossiers) spécifiés dans la configuration du service d'indexage média (se règle dans le panneau de configuration DSM) Ensuite il semble y avoir quelques pre-requis au niveau de la livebox, c'est détaillé plus précisément dans ce paragraphe du site dont j'ai donné le lien plus haut.

Je pensais que tu utilisais une solution maison pour tes sauvegarde. La modif du sshd config va modifier le port utilise coté *serveur* (sshd va écouter sur le port spécifié) mais il est aussi nécessaire de modifier le port coté *client* et je ne vois pas d'endroit, dans la config de la sauvegarde réseau ou on pourrait faire cela. Tu peux tenter (non testé) de creer, coté syno client, un fichier "/etc/ssh/ssh_config" avec ce contenu: Host * port XXXX (avec la valeur que tu as choisi pour XXXX) Je n'y crois pas beaucoup. Cependant, comme j'ai pu vérifier que le client ssh natif du syno (/usr/syno/bin/ssh) prend bien ce fichier en compte , ça vaut le coup d'essayer. En plus, ma sauvegarde de test est passée en "déconnecté" juste après avoir fait la manip, ça donne de l'espoir. **EDIT*** NOTE: si ça fonctionne tu devrait pouvoir te contenter de remettre sshd_config dans l'état initial, et faire uniquement la manip avec le "ssh_config", faire la redirection dans les box comme je l'ai indiqué (externe *:XXXX -> ipsyno_lan:22) .

Plutôt bloquer les IP des attaquants (ou carrément le bloc réseau complet) à l'aide du firewall Sinon, encore mieux: utiliser le blocage auto qui activera et désactivera les IP automatiquement sans avoir à t'en préocupper

Tout pareil, même constat et aussi résolu par un simple reboot.

Si j'ai bien suivi le fil, dans ton cas la seule erreur restante dans ton cas est le message "error: err_network" lors du restart d'apache? Le support va commencer à te faire désactiver le reverse proxy puisque ce n'est pas officiellement supporté, et si l'erreur est lié a ce dernier on ne sera pas beaucoup plus avancé.

Bien noter que ce n'est pas une configuration supportée officiellement par Synology. Par défaut, les droits que met DSM sur les dossiers partagés sont tres ouverts (777). Il y a donc des contraintes de sécurité à prendre en compte. Alors que, dans le cas de connexions externes (smb, ftp, filestation, etc ...) , les accès sont contrôlés par les droits des partages, ce n'est plus le cas une fois connecté local en ssh. Il reste possible d'aller resserrer les permissions à la main (un bon vieux "chmod" en ligne de commande ou via filestation) sur les dossiers mais bien savoir qu'il reste une exception pour le dossier "photo" qui doit être rester ouvert "par construction" si on veut l'utiliser avec photostation.

Pourquoi modifier ssh_config? Suffit de modifier uniquement la redirection de port de la box, du port XXXX en externe vers le port 22 du NAS en interne, et voilou

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