CoolRaoul

Ca été déja dit plusieurs fois: le partage "photo" est un peu spécial et est en fait prévu pour être accédé *exclusivement* par photostation ou DS_Photo. Comme il s'agit d'applications web, tournant dans dans l'environnement du serveur apache, elle s'exécutent sous le compte système "nobody" et c'est pourquoi les droits des dossiers et fichiers de ce partage ne peuvent/doivent pas être modifiés. Il faut gérer les comptes et les droits via l'interface d'admin photostation. Si on veut gérer les droits autrement, alors faut s'astreindre à ne pas utiliser photostation et a se constituer un autre dossier partagé (normal celui-la, pourquoi pas le nommer "photos", au pluriel) pour y stocker ses photos .

Via le parefeu intégré c'est clair que ce n'est pas possible: celui-ci n'est qu'une interface autour de iptables et le module de filtrage par addresse MAC ("libipt_mac.so") n'est même pas présent parmi ceux installés (voir dans "/lib/iptables"). et autrement je ne vois pas

En tout cas, je n'en reçoit plus

Mauvais PATH, corriger le PATH (dans "/etc/profile" et dans "/root/.profile") Ou se déconnecter/reconnecter si cela a déja été fait. Relire le wiki

Voici ce que je ferai: (optionnel) par sécurité, un backup du volume sur un disque externe USB (éventuellement sélectionner uniquement ce qui est important) Et ensuite l'option 1 (attention, si ce n'est pas un modèle support le "Hot Swap", insérer le nouveau disque NAS éteint)

A ta place, avant d'accuser le cron, je commencerait par rediriger la sortie du script dans un fichier log histoire de pouvoir analyser les eventuelles erreurs, En début de script, Un truc dans le genre: exec >>/tmp/boot_cron.log 2>&1 echo "=======" date # histoire de savoir l'heure de démarrage echo "=======" set -x # pour activer la trace des commandes Le contenu du fichier log pourra te mettre sur la piste. Autre chose, je constate tu ne positionnes pas le "PATH" dans ton script (et c'est une très mauvaise idée en général). Suivant comment à été lancé le démon "cron" (soit au boot ou relancé manuellement) il sera exécuté dans le 1er cas dans l'environnement par défaut dont le PATH se limite à "/bin:/usr/bin". C'est cet environnement dont va hériter ton script et Il aura du mal a trouver la commande "wakelan" dans ce cas

Trouvé d'autre personnes tombant sur cette même erreur dans ce fil. La solution donnée est de ne pas avoir oublié d'appliquer le point 8 de la page d'aide du Wiki (que je te conseille de bien relire en entier au passage) Le voici: Une fois effectué cette opération je te conseille de déconnecter ta session ssh et de te reconnecter pour tout recommencer (y compris la séquence umount, rmdir, etc ... que j'ai indiquée)

Oui c'est possible, en mettant en place un reverse proxy ou bien via le module "haproxy". Les deux approches qui ont déjà été abondamment expliquées et commentés dans ce forum. Une rapide recherche et tu trouvera la solution PS: sans vouloir te commander, il serait bien de prendre le temps de passer la case présentation, c'est un peu la tradition ici.

Probable des restes d'une tentative d'installation optware foireuse. A titre d'info donne le résultat de la commande: mount | grep /opt et ensuite, pour tout bien nettoyer, faire: umount /opt rmdir /opt rm -rf /volume1/@optware Puis recommencer l'install d'optware (sauf si une des 2 dernières commandes précédentes renvoie une erreur)

Faux positif probablement, je m'y suis connecté du boulot pour vérifier. On passe via un proxy filtrant, configuré à la "bondage & discipline", et il n'a pas tilté. Voici une capture de la page dans mon evernote: https://www.evernote.com/shard/s28/sh/c781b042-2fb1-4cdb-96fe-4d7d42f7d1ee/16f835a842ef779e52c140e68ae7a206

C'est completement inexplicable pour moi que https://192.168.1.62:5001 passe mais pas le ping sur cette même addresse. Tu peux essayer de désactiver le firewall du syno si il est activé mais, vu que par défaut il ne filtre pas les trames ICMP, je n'y crois pas plus que ça. Attendons si quelqu'un d'autre a une idée

Es-tu sur que le NAS a bien switché sur sa nouvelle IP ? Quel est le résultat de la commande "ping 192.168.1.222"

Pourquoi avoir tapé des slashs ("/") alors que ce sont des antislashs ("") que j'avait mis dans mon exemple ? Et <ipunas> doit être substitué par I'P du nas bien entendu!

Il est possible que le serveur windows ait conservé en cache l'ancienne IP du NAS. Essaie pour confirmer de te connecter au NAS en utilisant un chemin UNC et en y mettant son IP plutot que son nom ("<IP_du_NAQ>"). Si ça marche dans ce cas, un redémarrage du PC devrait résoudre le probleme.

Je l'avais écrit pourtant : "à faire à la source, dans le répertoire de backup via NFS et sur le syno en direct" (en 3 exemplaires donc) Mais tu peux laisser tomber, maintenant qu'on a trouvé que c'est du à un bug NFS Pas exactement: comme je l'ai indiqué dans mon dernier message c'est un bug de *la version de NFS utilisé par Synology*. Il ne peut donc se manifester uniquement lors de l’accès coté client via NFS à des dossier partagés par le NAS apparemment en présence de certaines configurations de liens symboliques provoquant une "boucle" (du genre a -> b -> a) En lisant attentivement ma réponse précédente tu va te rendre compte que la réponse ne peut être que négative. Et tu peux le vérifier, suffit de simplement faire le test.

Il me semble avoir indiqué la commande à utiliser dans ma réponse. PS: si tu en connais aussi peu, fait *extrèmement* gaffe en manipulant la ligne de commande sous le compte root sans bien comprendre ce que tu fais. Une simple faute de frappe au mauvais endroit pourrait avoir des conséquences dévastatrices et rendre ton NAS inutilisable et de voir obligé a pratiquer un reset voire une ré-installation.

IcI c'est coté *cible* que le rsync coince sur un problème de lien symbolique circulaire, pas sur la source. En fait le problème rencontré est spécifiquement lié a l'utilisation de NFS et a d'ailleurs déjà été signalé sur les NAS synology: http://superuser.com/questions/599498/nfs-too-many-levels-of-symbolic-links-how-to-find-and-fix Voila pourquoi j'ai suggéré une autre approche que celle s'appuyant sur NFS (qui n'est d'ailleurs pas idéale pour d'autres raisons).

Et bien! Qu'est-ce que ça aurait été si tu avais opté de nous donner des détails Commence par créer le répertoire "/opt" ("mkdir /opt") et ça devrait aller beaucoup mieux.

Toutes les commandes précédentes sont de celles qui n'utilisent pas le canal de données. Par contre je vois bien que le mode passif est bien positionné (PASV), ce qui contredit mon diagnostic initial. Alors une possible explication est qu'un firewall est mal configuré (ne laisse pas passer les range de ports utilisés pour le canal de données). Soit celui du Syno soit un autre en amont. Des explications détaillées ici: http://blog.deadcode.net/2009/04/24/ftp-to-your-box-from-external-network/

Vu que tu ne parle que de la commande "LIST" doit on comprendre qu'il n'y a pas de problemes pour les autres commandes ftp? Le symptôme tel que que tu le décris (timeout) ressemblerait à une mauvaise gestion du mode actif de ftp (sans doute par le routeur), pour le résoudre faudrait forcer le mode passif dans ton client ftp. Mais si c'était la bonne explication la plupart des autres commandes utilisant le canal commande (get, put ...) aurait le même comportement. Si c'est que LIST qui merdoie je suis un peu pommé

Ce n'est pas ce que je t'ai demandé, tu as oublié "man3": ls -ld man3 ^^^^ On va laisser de coté l'option "activation du service rsync", qui a quelques inconvénients sous DSM comme être incompatible les autres services de sauvegarde réseau (voir les détails dans l'aide de l'option "panneau de configuration->sauvegarde réseau->utiliser la configuration rsync personnalisée" ) et en outre est un chouïa plus complexe.. Tu pourra te limiter à l'autre option que j'ai citée, le simple "rsync via ssh". Il suffit juste pour cela que le service ssh soit activé sur le NAS. Dans ton cas ça va donner (ce n'est que le 2ème argument de la commande qui va changer): rsync -vazxH --numeric-ids --ignore-errors --delete --delete-after / root@<IP_SYNO>:<chemin du dossier cible sur le syno> Cette approche va te demander de saisir le mot de passe du compte root du syno pour effectuer la connexion. Et c'est tout. [ce qui suit sort un peu du cadre de ce fil, mais tu devrais facilement trouver de l'aide détaillée sur l'authentification par clé ssh par ailleurs] Si tu veux automatiser tout ça (sans avoir à saisir le mot de passe) tu pourra plus tard envisager l'authentification par clé. En gros faudra alors créer (avec la commande "ssh-keygen") une paire de clés ssh privée/publique sans mot de passe coté linux et mettre la clé publique associée dans "/root/.ssh/authorized_keys" du Syno et ajouter a ta commande rsync le paramètre. Cette clé devra par précaution de sécurité être strictement réservée à cet usage. Il faudra alors ajouter l'argument suivant à ceux de ta commande rsync: -e "ssh -i<chemin du fichier de la clé privée>"

pas sur que ce soit une bonne idée d'utiliser dossier monté du syno en NFS comme cible. Même si ce n'est pas sur que l'erreur vienne de là (l'erreur qui indique plutôt une série de liens symboliques circulaires ou plus simplement un simple lien symbolique récursif sur lui même. Mais normalement le switch "-a" de rsync devrait permettre de s'affranchir de ce problème), ce n'est pas idéal pour un backup. Serait bien plus efficace de faire un rsync en mode client/serveur, soit en activant le service rsync sur le syno, soit directement via ssh, syntaxe rsync <parametres> <source> <user_syno>@<host_syno>:/dossier_cible/ dans ce deuxième cas. Et pour revenir à ton problème de lien, est-ce que tu as aussi l'erreur en faisant le "ls -l" en direct sur le syno et pas a distance en NFS? Que donne un simple "ls -ld man3" apres un cd dans "<chemin variable selon le cas>/usr/share/man" ? (à faire à la source, dans le répertoire de backup via NFS et sur le syno en direct) ?

Dans filestation, le menu contextuel d'un répertoire propose l'option "télécharger", ce qui à pour effet de récupérer une archive zip du répertoire.

En effet ça suffit à mon besoin Je vais essayer ça des que possible.

La fonction de base de strace est justement de tracer les appels système, si on en peux même pas lui faire confiance pour ça, ça craint un peu. Inversement, qu'une E/S ne provoque pas d'appel système, j'ai du mal à imaginer. J'ai bien peur qu'en supprimant tout ça je me retrouve avec plus de synchro du tout in fine. Peut-être que btsync n'est simplement pas la bonne solution pour mon besoin: je cherche à maintenir sur le NAS un miroir d'un certain nombre de dossiers bien identifiés de mon smartphone Androïd. Et DsCloud n'est pas adapté dans le cas de dossiers "éparpillés" comme ceux-la.