CoolRaoul

Voila, voila ... Théoriquement, pour respecter strictement ta spec ceci devrait faire l'affaire (à mettre dans un script autonome, lui même invoque par /etc/rc.local #!/bin/sh # 1- Vérifier que "/etc/ddns_provider.conf" et # "/etc.defaults/ddns_provider.conf"sont identiques # # 2- Si ils ne sont pas identiques, copier le fichier # "/etc/ddns_provider.conf" et le coller dans # "/etc.defaults/ddns_provider.conf" en écrasant l'ancien # 3- Si la 2ème étape a eu besoin d'être effectuée, rebooter le syno PATH=/bin:/usr/bin A_FILE="/etc/ddns_provider.conf" D_FILE="/etc.defaults/ddns_provider.conf" cmp -s $A_FILE $D_FILE && exit # fichier identiques: rien a faire cp $A_FILE $D_FILE reboot Mais attention, faire un "reboot" lors de la séquence de startup (puisque appelé par rc.local), je ne pense pas que ce soit une très bonne idée. Le boot DSM exécute certaines parties en parallèle, ton reboot va arriver comme un poisson dans l'eau en plein milieu de cette séquence tandis que d'autre opérations sont en train de se dérouler (démarrage des packages par exemple) et ca risque de mettre un joyeux souk. Déja, a la place du reboot peut-être se contenter d'un simple /usr/syno/etc/rc.d//S09DDNS.sh restart serai moins violent Mais meme dans ce cas, et a cause du parallellisme du démarrage, ton rc.local peut tres bien être exécuté avant ou apres le démarrage DDNS, ou pire ... simultanément! Tu vois, c'est pas si simple. Je vais essayer de trouver une solution plus robuste Stay tuned...

Si tu disposes de la commande "du" d'optware (ipkg) tu peut avoir une idée précise de la place réellement occupée par les différents dossier images timebackup. Commencer par se déplacer dans le dossier cible de timebackup La dessous tu devrais avoir un sous dossier avec un nom du style "<hostname>_XXXXXXXXXX", et en dessous un autre nommé "task_<n>" (chez moi par exemple, ça donne "/volume2/backups/TimeBackup/fserv_00113205F256/task_8") Une fois dans le répertoire "task_n", tu utilise la commande "du -sh *" (en s'assurant de bien utiliser le "du" optware et pas celui intégré a dsm). Cela va afficher un rapport d'utilisation de chacun des dossiers images timebackup avec prise en compte unique des fichiers multiplement liés (ce que ne fait pas /usr/bin/du), par conséquent l'espace disque réellement occupé, dossier par dossier

Sur quoi te bases-tu pour supposer que ce que tu constates est causé par le serveur DHCP? Tu peux faire le test sous windows en ligne de commande: ipconfig /renew Est-ce que cette commande met longtemps à répondre? Si non ce n'est pas le serveur DHCP le coupable.

http://www.dd-wrt.com/wiki/index.php/Netgear_WNDR3700

Il me semble (reste à démontrer) qu'il se pourrait que certains scripts de démarrage (dans /usr/syno/etc.defaults/rc.d/) pourrait fonctionner de façon asynchrone. Résultat, quand "/usr/syno/etc.defaults/rc.d/<machin> stop" rend la main, <machin> n'est pas forcément encore arrété. Voila pourquoi, je pense que "S95sshd.sh stop" va se contenter d'initialiser l'arret du démon ssh, arrêt qui ne sera effectif que lorsque *toutes* les sessions ssh existantes se seront terminées. Je suppose que lorsque tu as voulu arréter le service ssh, tu était toi-même connecté par l'intermédiaire d'une session ssh non? C'est pour éviter cela: que ssh reste actif je pense:

C'est confirmé: http://www.justanswer.com/computer-networking/3xkm2-forward-external-port-8008--wndr3700.html Décevant quand on sait que la première BOX modem/routeur fournie par la plupart des FAIs sait faire ce genre de chose.

Le test que je demandais de faire était d'ajouter explicitement une ACL pour le groupe "administrateurs" ? Faudrait essayer même si ça peut avoir l'air bizarre. Ce n'est pas obligatoire: une application (de la part de Microsoft on peut s'attendre a tout) peut tout à fait récupérer, d'une part la structure de donnée correspondant à l'ACL, d'autre part la structure correspondant a la liste de droits du process et tenter de vérifier elle-même les droits, plutôt que l'approche, a priori plus "naturelle", de tenter l'ouverture du fichier en écriture et d'intercepter l'éventuelle erreur . Si tu veux savoir exactement ce qui ce passe je t'invite a utiliser process monitor sur le PC, c'est un outil absolument extraordinaire pour "espionner" ce que fait un process en temps réel. Il va te permettre d'auditer quels sont les API invoquées par Office et voir les codes retour. Ce devrait aider pour voir exactement ou ça et ce qui coince. En parallèle, activer la trace SMB dans DSM (panneau de conf -> Win/Mac/Nfs -> Service de fichiers windows -> activer le journal des transfert) peut aussi aider à identifier ce qui se passe.

Peut-être qu'office starter interprète mal l'autorisation *implicite* donnés aux utilisateurs du groupe administeurs d'accéder aux dossiers. Une piste: essayer d'ajouter une autorisation *explicite* sur ces dossiers en ajoutant une entrée d'ACL donnant droit de lecture/ecriture (ou plus) sur ces dossiers à ce groupe

Ca peut demander une manip supplémentaire; On en a discuté ici le cas de la sauvegarde cryptée (via ssh donc):

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