CoolRaoul

Déterrage du sujet pour mise à jour et conclusion en ce qui me concerne: de multiples tests m'ont amené a la conclusion que le VPN DSM en mode LP2P est incompatible avec la gamme de smartphones Sony Xperia Z tournant une version d'android > à 4.3 (a moins que ce soit le contraire ) J'avais contacté le support Syno sur ce point qui, sans grande surprise, ont renvoyé la balle chez Sony. Et quant au support Sony ils n'ont même pas daigné répondre à mes demandes. Je viens récemment de changer d'appareil pour une marque concurrente et là plus de problème. Voici le récapitulatif définitif de mes tests;

Non seulement ce n'est pas possible, mais vu le système shadok et propriétaire que Mega impose d'utiliser pour simplement télécharger (extension du navigateur), tout espoir de voir survenir des outils tiers d'acces à Mega me semble faible.

Ce n'est pas un réellement un "mount" au sens unix: ca reste accessible uniquement via filestation (et peut-être DSFile, ça j'ai pas vérifié). Mais sinon, si tes transferts sont "entrants" (de l'extérieur vers le NAS), peut-être chercher du coté de wget qui supporte nativement ftp lui (sera moins efficace que rsync bien entendu car ne fait pas de delta transferts): fserv> wget --help | grep -i ftp --user=USER set both ftp and http user to USER. --password=PASS set both ftp and http password to PASS. FTP options: --ftp-user=USER set ftp user to USER. --ftp-password=PASS set ftp password to PASS. --no-glob turn off FTP file name globbing. --no-passive-ftp disable the "passive" transfer mode. --follow-ftp follow FTP links from HTML document

Ah oui! comme dirait l'autre ... "c'est du brutal" Mais c'est le résultat qui compte après tout

Solution radicale: le supprimer ("rm /etc/crontab") ou mieux le renommer ("mv /etc/crontab /etc/crontab.bak"). Nous poster une copie pourrait être utile aussi (mais ça peux être juste un pb d'espaces à la place de tabulations, vu que le cron DSM y est très sensible, et un copier/coller risque de masquer ça) redémarrer le NAS (pour faire bon poids) Retourner dans le gestionnaire de tache et faire une modification bidon (changer la minute par exemple) des taches programmées pour s'assuré qu'il soit re-écrit Attention de vérifier aussi les éventuels jobs de sauvegarde programmés.

600Mo c'est encore beaucoup trop si tu veux mon avis, le mien se contente de moins de 10Mb (7380Ln ici): fserv> /bin/ps | grep dms 9691 root 112m S /var/packages/MediaServer/target/sbin/dms 23416 root 4000 S grep dms fserv> grep RSS /proc/9691/status VmRSS: 7380 kB ^^^^^^^

Le dossier "Photo" est géré de façon spéciale par DSM. On en a parlé a plusieurs reprises. Dans par exemple. Pour résumer le dossier "Photo" est prévu pour être accédé uniquement par Photostation (en accès http) et/ou DSPhoto (via smartphone). Et dans ce cas on peut gérer les droits finement. Si on n'utilise aucune de ces deux applications, alors il sera plus approprié d'utiliser un *autre* dossier (par exemple "Photos" au pluriel, qui sera géré comme tous les autres dossiers partagés de DSM). Mais si on souhaite utiliser photostation, en mode partage de fichier (réseau windows, ftp, webdav, ...) il est conseillé d'en laissé réservé l’accès au seul administrateur.

Plus ou mois aussi (mais pas étonnant vu que DSM est made in Taiwan) Blague à part, tu peux encore encore tenter de désinstaller puis réinstaller le package Serveur Multimedia. Et si le problème persiste, je crois que tu coupera pas à une ouverture de ticket au support. Ca peut maintenant se faire directement dans DSM, via le centre de paquets, en cliquant sur "commentaire":

Dans ce cas met directement le code du script dans la fenêtre du planificateur de tache et oublie le script shell. Comme cela: Attention aux retours de ligne dans l'interface, il doit y avoir *exactement* 3 lignes (PATH, [ -t ...] et php) **EDIT** le préfixe "[ -t 0 ] ||" peut même être omis puisque dans ce mode ca c'exécutera toujours en tache de fond: **EDIT#2** Mais qu'il y ait une différence dans le cas d'une exécution avec le bouton "exécuter" et par heure programmée me laisse vraiment perplexe... On dirait que le fichier /etc/crontab a été corrompu **EDIT#3** Bon, la nuit porte conseil comme on dit ... A suivre

Ben alors, c'est quoi qui ne fonctionne pas? Dans ton message initial tu disais "la tâche en elle-même n'est pas exécutée !" Si le log est rempli c'est bien la preuve que la tache s'éxécute.

Quel est le contenu du fichier log? Peut-être que le script n'est pas exécutable? (en ligne de commande, faire un chmod +x du fichier) Je suis en 5.1 Je ne me souviens plus trop comment fonctionne le gestionnaire de taches en 4.3 en fait, mais en 5.0 et + on se retrouve au final avec une utilisation du cron Mais l'article que tu cites explique *justement* la manière de faire en utilisant le cron! Tu t'y prend comment toi alors? **EDIT** Me suis trouvé un acces à un DSM 4.2, je vais pouvoir reproduire exactement ta situation.

Ah non, là c'est pas tout à fait pareil: ici tu logge *uniquement* la sortie standard de la commande php, alors qu'avec mon approche ce sont les sortie standard *et d'erreur* de *tout* le script (y compris php bien entendu) Ta ligne shebang est incomplète déjà (mais c'est vrai que je m'était mal exprimé en y faisant référence) Et pour la redirection fait utiliser l'approche que j'ai conseillée. La bonne syntaxe est donc #!/bin/sh PATH=/bin:/usr/bin:/usr/syno/bin [ -t 0 ] || exec >/volume1/web/Moulin/logE.log 2>&1 php /volume1/web/Moulin/ecod2sql.php La je ne saurais dire, je ne suis pas spécialiste php.

Assure-toi d'être bien connecté avec le compte "root" (même mot de passe que le compte admin). La commande à taper est: tail /var/log/dms.log Ça va afficher les dernières lignes du fichier. Ensuite nous donner le résultat. Mais si ça n'affiche rien il ne te restera plus qu'a contacter le support Synology. Je suppose que tu as déjà essayé de simplement redémarrer le NAS sinon?

Comme dans 99% des cas ou on rencontre ce symptôme, il est fort probable que ce soit une un problème de "PATH". Il faut *toujours* spécifier le PATH dans les scripts, et plus particulièrement ceux qui sont susceptibles d'être exécutés en cron (ce qui est le cas via le planificateur de taches). Un shell interactif exécute "/etc/profile" et "$HOME/.profile" ce qui n'est pas le cas de ceux lancés par cron. Par suite, comme sous DSM le binaire php est dans "/usr/syno/bin", ajouter en début de script (après la ligne shebang, "#!): PATH=/bin:/usr/bin:/usr/syno/bin Et puisque tu y es, pense à ajouter la génération d'un fichier log quand le script s'exécute en mode non interactif, comme ceci: [ -t 0 ] || exec > /tmp/runmoulin.log 2>&1 ou bien, plus traditionnel mais plus verbeux (et pas tout à fait équivalent mais c'est sans importance): case $- in *i*) : ;; *) exec > /tmp/runmoulin.log 2>&1 ;; esac comme ça, si d'autres erreurs se présentent tu pourra en voir le détail et ça simplifiera le diagnostic

DMS c'est le proccess du package Mediaserver Pour avoir une piste, faudrait commencer par aller voir (en se connectant en root par ssh ou telnet) ce que contient son fichier log ("/var/log/dms.log")

Et si tu avais commencé par expliquer précisément ce que tu cherches a faire? Tel que spécifié, le premier "cp" va copier sur la cible tous les fichiers dont le nom correspond à "*Toto*.*" Maintenant, veux-tu en fait copier *tous* les sous-répertoires de "FromSeedbox" et les fichiers nommés "*Toto*.*" qui s'y trouvent, ou simplement *tous* les sous-répertoires de "FromSeedbox" avec *tous* leurs fichiers, quel que soit leur nom? (ou toute autre combinaison...)

Si, dans les deux commandes de ton exemple, tu remplaces "cp" par "rsync -u" ça fera exactement ce que tu souhaites. **EDIT** pour info: fserv> rsync --help | grep -e --update -u, --update skip files that are newer on the receiver

Essayer plutôt avec rsync alors (/usr/syno/bin/rsync) , encore plus économique en I/O avec les bonnes options.

Il existe encore des équipements avec des ports ethernet ne gérant pas le "Auto MDI-X" ? Car ça fait un bail que je ne suis plus posé la question câble croisé vs câble droit (d'autant plus qu'il suffit qu'un seul des deux équipements de chaque extrémité soit compatible pour que ça fonctionne)

Vu que ce n'était pas spécifié (il n'était question que de d'une "certaine fonction web" ) on ne pouvait pas deviner Oui: https://www.synology.com/fr-fr/knowledgebase/tutorials/493

En connexion root via SSH ou telnet, regarder le contenu de "/var/log/upstart/httpd-user.log". Il y a des chances d'y trouver une piste.

L'*endroit* c'est justement cette section "présentation" ou nous sommes. Suffit de poster un message en texte libre. Mais bon, on peut dire que tu es présenté maintenant Par contre cette question-ci aurait mieux sa place ici: NAS-Forum → Support des logiciels Synology → Partage de fichiers et privilèges → Win/Mac/NFS A part ça je te conseille de faire ceci: créer sur le NAS un compte *non administrateur* au libellé identique à celui utilisé sur ton PC Windows et avec le *même* mot de passe que sous Windows. toujours sous Windows, aller dans "Panneau de configurationTous les Panneaux de configurationGestionnaire d'identification" et supprimer toutes les entrées relatives au compte "admin" initial du NAS ainsi que celles du compte admin alternatif que tu as créé ensuite. déconnecter et reconnecter la session windows la connexion au NAS en en partage fichier se fera avec ce compte. (si ça ne marche toujours pas ou si tu as besoin de précisions complémentaires enchaîne avec un nouveau sujet dans la section dont j'ai donné le lien ci dessus)

Merci du feedback, le Cloud a peut-être du avoir des vapeur passagères. Tu verras à l'usage KeyPass est un super outil.

Je n'ai jamais rencontré le genre de dysfonctionnement que tu décris (mais quand j'utilisais CloudStation c'était uniquement pour des accès en lecture) Déjà faut bien comprendre que Keypass ne garde pas le fichier ouvert: à l'ouverture il constitue une copie en mémoire de la base kdbx et referme le fichier aussitôt. Au moment de la sauvegarde il fusionne les modifications qu'il a dans sa copie en mémoire avec celles du fichier sur le disque. Toutes ces opérations sont bien entendu protégées par un système de verrou pour éviter des écritures simultanées. Je pense qu'il est possible que ce soit CloudStation qui interfère dans ton cas. Mieux vaut sans doute s'en tenir (comme moi) à un accès direct en partage réseau et laisser Keypass s'occuper de la synchro.

A partir du moment ou tu utilises la version 2 de Keypass (dite "pro") tu n'as pas à t'inquiéter : chaque sauvegarde est en fait une synchro. Donc aucun risque qu'une sauvegarde d'un PC écrase des nouvelles entrées créés avec l'autre. En plus il gère automatiquement un historique au niveau de chaque entrée. Le mettre dans un dossier synchronisé par CS à l'avantage de disposer de ce fait d'une historisation de ta base Keypass mais rien ne l'oblige. Dans mon cas j'accède à mon Keypass en local directement en SMB/CIFS à partir de plusieurs postes Windows. A distance je me connecte en webdav, aussi bien via l'application Android que par un Keypass installé en mode portable sur une clé USB. **edit** A noter que depuis mon message initial j'ai laissé tomber dscloud à cause de défauts rédhibitoires pour moi mais ce n'est pas le sujet ici.