CoolRaoul

Et bien j'ai l'impression qu'on a atteint les limites de ce qu'on peut faire à distance en terme de diagnostic. Et tout cas moi je sèche Juste une dernière question, le dernière erreur ("Configuring ipkg-opt.ipk...WARNING: can't open config file: /usr/syno/ssl/openssl.cnf"), quelle est la commande qui l'a provoquée?

Faire exactement ce que j'ai décrit dans mon post un peu plus haut: mettre les lignes que j'ai données "en début de script" (dans boot.sh en l'occurence, juste au dessus de la ligne "#Déclaration des variables" par exemple )

Non: à partir du moment ou l'autre script est inviqué par la commande ".", il s'exécute dans le contexte de l’appelant. (c'est grosso modo équivalent à une commande "include" présente dans d'autres langages) J'ai bon espoir que le contenu du fichier log nous donnera l'explication. Tiens nous au courant du résultat

Juste savoir que le droit "exécuter" est un pre-requis pour avoir acces a tout ce qui est en dessous (on peut le voir comme le droit de *traverser* dans le cas d'un dossier) . Le doit "lecture" sur un dossier ne permet que de voir la liste des *noms* des objets (dossiers et ou fichiers) contenus par ce dernier. Tout dépend ce que tu veux faire exactement. Il est probable que des que tu va vouloir mettre en place une matrice de droits d’accès (utilisateurs X groupes X dossiers) plus complexe tu atteignes les limites du modèle basé sur [propriétaire, groupe, autres]. La solution serait alors d'activer les ACL sur le dossier partagé. Mais attention c'est plus compliqué. J'ai participé récemment à un fil sur le sujet, je pense que sa lecture pourra t’intéresser C'est ici:

Alors commencer par mettre le logging en place comme j'ai indiqué déjà pour y voir plus clair. NB: mettre des fichiers perso dans la hiérarchie "/usr/syno" est casse-gueule car ils seront irrémédiablement supprimés lors de toute mise à jour DSM (mais à priori pas dans le cas de simple correctifs). Il est bien plus approprié de choisir l'arborescence "/usr/local" qui est toujours préservée (c'est documenté).

Non, la ça indique juste que le PATH est toujours incorrect Que donne "echo $PATH" ?

On ne pouvait pas deviner Il est important de bien comprendre la différence entre ne pas voir la *présence* d'un dossier et ne pas avoir *acces* à un dossier (en lire le contenu): Quand l'utilisateur *voit* un dossier cela signifie qu'il a un droit de lecture au dossier qui le contient. Les droits du dossier lui-même ne sont pas pertinents dans ce cas. Avoir *acces* à un dossier nécessite que l'on ait au moins les droits d'exécution (et lecture en plus dans le cas de filestation) à tous les dossiers de niveau supérieur jusqu’à la racine (le dossier partagé) et au moins droit de lecture au dossier lui-même. Par suite, la seule façon vraiment efficace pour cacher la présence d'un dossier est de le situer dans un autre dossier auquel l'utilisateur n'a pas accès en lecture. Prendre l'analogie avec une armoire fermée a clé (pas d'acces) mais dont la porte est transparente (droit de lecture: on voit les dossiers qu'elle contient mais le contenu de ces derniers) NB: ce n'est pas tout a fait exact sous DSM car il existe une option pour cacher automatiquement les éléments auquel on n'a pas accès mais me semble avoir lu qu'elle ne s'applique pas très bien à tous les modes de partage réseau

Tu as pourtant écrit *exactement* le contraire: "En fait si je copie mes dossiers et sous dossiers dans un autre répertoire que photo tout fonctionne mais je ne sais pas pourquoi..." Tout dépend des droits des dossiers, je ne vois rien d'étonnant là. Les droits de ces différents dossiers (ou d'un de leur dossiers parents) doivent être différents. Faut les vérifier. Pas trop moi non plus j'avoue, ça manque peut-être de détail et de plus c'est pas facile à suivre.

Maintenant que ça devient plus spécifique, pour haproxy, faudrait plutôt poster dans cette section: http://www.nas-forum.com/forum/forum/210-paquets-fournis-par-synocommunitycom/

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.