CoolRaoul

Oui mais je ne vois pas trop l'intéret (moins performant et moins de fonctionnalités que SMB/CIFS ou NFS). L'intéret de webdav est qu'étant encapsulé sur du http, il est bien approprié pour les connexions distantes, et supporte quasiment tous les proxies de façon transparente. Pourrais-tu nous donner le lien de la page donnant ce "conseil"? Ca me semble vraiment surprenant à moins qu'il n'y soit suggéré que dans des conditions bien spécifiques (telles que celles que j'ai évoqué au début) En ce qui concerne webdav et avec Windows 7 j'essaie de privilegier le client intégré (pour ne pas avoir à ajouter un logiciel de plus) mais celui-ci peut necessiter certaines bidouilles dans la base de registre pour accepter de se connecter à un serveur Webdav Syno. Netdrive fonctionne sans manips particulière.

fserv> ls /var/log/upstart/http-user.log ls: cannot access /var/log/upstart/http-user.log: No such file or directory

Erreur de destination pour le post?

Quelqu'un sur le forum US a pris la peine de traduire la manip en anglais, les liens sont dans ce message: http://forum.synology.com/enu/viewtopic.php?f=108&t=84383&start=75#p317723

Directement via le menu de DS cloud tu as accès à un formulaire "contacter l'assistance", mais sur un mobile ça risque de ne pas être trop pratique. Le mieux est de le faire en ligne La procédure est expliquée dans l'aide DSM, rubrique "contacter l'assistance":

un petit test Création d'un dossier partagé en lecture seule pour un utilisateur donné DScloud, en se connectant avec ce compte, le voit bien tant qu'on ne modifie pas les droits des fichiers et/ou dossiers (par filestation par exemple) Dès que les droits sont modifiés en mettant lecture seule pour l'utilisateur il n'est plus "liable" par dscloud. Donc, en se qui concerne la visiblilté, dscloud ne prend en compte que le doit du partage et pas les droits au niveau fichier Me semble raisonnable de considérer ça comme un bug de DScloud

Tu as raison; Je viens de faire un test d'ajout de dossier partagé à la liste cloudstation et ca m'affiche ce message. Donc normalement les dossiers en lecture seule doivent bien être sélectionnables (je vais vérifier et je repasse )

DSCloud propose est une synchronisation *bidirectionnelle*. Par suite un dossier en lecture seule ne peut être utilisé. C'est logique. Faut peut-être chercher des solutions du coté de bittorrent sync (package DSM et client android sont disponibles, mais je ne saurais pas aider dans l'immédiat par contre).

C'est ce que je déduis du post dont voici le lien: http://forum.synology.com/enu/viewtopic.php?f=108&t=84383&start=30#p317506 "The update firmware has been fixed and you should be able to run the update-2 on your DS112j without any problem."

Pour les impatients, Il existe une autre option que j'ai mentionnée ici:

Voila: "ps" affiche la liste des processus en cours (sur d'autres versions de linux il aurait été necessaire d'ajouter des arguments pour l'avoir complète) "grep" filtre son entrée (qui ici est la sortie de la commande "ps" qui lui est connectée par "|" dit "pipe"), et ne laisse passer que les lignes contenant la chaîne de caractère spécifiée ("crond" dans ce notre cas)

Sympa le nom. Pour un euro (en bitcoins via le port USB) il éjecte une mousse bien fraîche je suppose?

La mienne ou ce qui est listé ci dessous? On voit deux process cron en cours d’arrêt et un autre en cours de démarrage. Rédémarre le NAS pour mettre tout ça propre

Tout est normal et j'en perd mon latin (j'ai pourtant un peu de bouteille dans le domaine) Ah moins que l'explication soit si grosse et devant mes yeux que je ne la voir même pas.

Tu n'aurais pas 5 services cron démarrés par hasard? (un "restart" qui ne parviendrai pas à arréter l'instance en cours) Que donne cette commande? /bin/ps | grep crond

Au passage je n'ai toujours pas trouvé comment visualiser la sortie d'erreur de ces commandes. Tout se passe "en aveugle" et je trouve ça un peu dommage (une erreur dans la conf apache et il ne redémarre pas mais rien n'est signalé dans le terminal). Si tu as une piste je suis preneur.

Pas facile de comprendre ce qui se passe: le shell effectue le parsing des arguments indépendamment de la commande. A tout hasard, vérifie ce que donnent chez toi les commandes type ls et type rm Ben moi, je pratique cet environnement (AIX et ksh) tout les jours depuis des années et je n'ai jamais rencontré cette anomalie. Bien entendu (tu penses que j'ai vérifié avant de répondre), comme sur tous les autres shells unix que je pratique d'ailleurs.

D'apr

Ca défie toute logique! Je n'ai *jamais* rencontré un tel comportement en shell (et je suppose que tu utilise bien le shell standard, "/bin/ash" je suppose ?)

Mais ça ne marchera pas pour le find car les espaces sont dans les chemins de fichiers trouvés par le find lui même. Dans ce cas, la bonne approche est: find . -name @eaDir -type d -print0 | xargs -0 rm -rf (les "0" sont des zeros, pas la lettre "O") A tester une fois "a blanc" (avec un "rm" on ne sait jamais) avec un echo: find . -name @eaDir -type d -print0 | xargs -0 echo rm -rf

Voila déjà la commande pour redémarrer apache: /usr/syno/sbin/synoservicecfg --restart httpd-user et pour le cron je ne serais pas surpris que: /usr/syno/sbin/synoservicecfg --restart crond fonctionne. PS: pourquoi avoir posté cette question dans ce fil? Pas terrible pour sa visibilité je trouve.

petit d

Non, ça c'était avant (avant DSM 5) Mais c'est bon, j'ai temporisé jusqu'au soir (et le fichier est n'est pas touché par l'update)

J'ai voulu en avoir le coeur net. Et en fait il existe de subtiles différences (pour le compte root en tout cas) lorsque une tache programmée est exécutée en mode programmé (planification) et quand on utilise juste le bouton "exécuter" (pour un simple test) Ce n'est que dans le premier cas que $HOME est bien positionné, et par suite "~" bien étendu. Je dirai volontiers que c'est un bug