CoolRaoul

https://www.synology.com/fr-fr/support/developer#tool "Guide des développeurs tiers" "Ce guide fournit des détails sur la création de paquets pour les produits Synology DiskStation. Il présente la structure, la compilation, la sélection du langage, l'interface utilisateur et la publication du paquet - tout ce dont vous avez besoin pour commencer à créer un paquet." Pour simplement compiler, s'en tenir à la section "Compile Applications". NB: La toolchain doit être installée sur une plateforme Linux (une VM fera l'affaire)

Aucune idée, d'ailleurs les commandes que je me suis compilé sont essentiellement celles qui me faisaient défaut sur le DSM de base (exemple: "lsof", "strace", "inotify*",...), de plus c'est uniquement pour mon architecture (armada370), et enfin ça n'est absolument pas diffusable en l'état (structure un peu rigide et pas vraiment portable).

Comme tu l'as sans doute noté j'ai indiqué que j'ai laissé tomber optware (et ça fait un bail). Ce projet me semble plus vraiment vivant. Je préfère me me compiler avec le SDK les outils dont j'ai besoin. Je ne sais pas de quoi il s'agit

Il y a peu de systèmes permettant de modifier le nom du compte "super administrateur", du moins sans effets de bords. Par exemple, à ma connaissance, renommer "root" sur un unix n'est pas vraiment prévu (je ne connais personne qui le fasse et ça m'étonnerait que ça soit possible sans casse). Egalement, sous Windows, le compte "Administrateur" ("Administrator" sur les version en anglais) n'est simplement pas modifiable. Voila pourquoi je suis étonné du nombre de personnes (car c'est une question récurrente) demandant à faire pareil sur DSM.

Autant que je me souvienne, à l'époque ou je n'avais pas encore abandonné optware, la commande "file" me faisait déjà ça. D’après ce que je vois dans les repositories le package "file" n'a pas eu de mise a jour depuis 2 ans (dans le meilleurs des cas: dernière update datée de 2010 pour certaines architectures). Pas gagné à mon avis.

Un peu hard ta solution Je préfère attendre que le bug soit corrigé, je peux patienter.

Voir ici:

Oh, j'avais oublié de la mettre a jourJe le fait sur le champ

Malheureusement pour moi, Synology refuse de m'apporter la moindre assistance: des qu'ils constatent la présence d'un point de montage "/opt" sur ma machine (ce n'est même pas optware mais c'est là que je déploie mes propres outils cross compilés) ils sortent leur Joker et me demandent de faire un reset usine avant d'investiguer plus avant. Après deux dossiers terminés en eau de boudin pour ce motif j'ai renoncé à faire appel au support (à l'exception des applis mobiles). Et donc je suis ce fil en espérant que d'autres puissent contribuer à trouver une solution.

J'ai aussi ceci dans la log ("/var/log/synodtv.log"): synodtvd: synodtvd.cpp:963 [streaming] Bad signal - ffmpeg dvblast > feed.ffm terminates with exit(1) Et pourtant, mon antenne est juste dans l'axe de l’émetteur et j'au toujours un un signal au top. (Il me semblait être revenu a une ancienne version, mais j'ai du merder et réinstaller la plus récente.)

A savoir: cette mise à jour réinitialise le contenu de "/root" et de "/etc/profile" (comme souvent mais certaines ne le font pas) Pensez à sauvegarder si nécessaire.

Seuls certains modèles sont concernés: http://usdl.synology.com/download/DSM/5.1/5022/

Sinon il y a la solution du simple reset : https://www.synology.com/fr-fr/knowledgebase/tutorials/493 A part ca et a mon avis c'est pas une bonne idée de ne pas mettre d'expiration des blocages. Dans le cas par exemple d'un un blocage à 24 heures, comment peux-t-on imaginer que quelqu'un qui fait des essais en mode force brute passe le cap en n'ayant droit qu'a deux essais par jour? Autre chose, je conseillerai de mettre en "whitelist" (bouton autoriser/bloquer) l'IP d'un ou plusieurs PC du réseau local pour ne pas se retrouver bloqué comme ici.

Bon, moi aussi j'ai des probleme (avec videostation Tout à coup il se met a boucler, CPU au taquet et me pollue les logs avec ceci: synodtvd: synodtvd.cpp:1949 (auto) tuner 0 updating epg of channel France 2 synodtvd: synodtvd.cpp:334 [synodvbepg(automatically)] tuner 0 child process 25963 synodtvd: synodtvd.cpp:3013 daemon sleep: 1 day, because no recording event synodtvd: synodtvd.cpp:3078 Stop auto update epg, frontend busy synodtvd: synodtvd.cpp:1949 (auto) tuner 0 updating epg of channel France 2 synodtvd: synodtvd.cpp:334 [synodvbepg(automatically)] tuner 0 child process 25995 synodtvd: synodtvd.cpp:3013 daemon sleep: 1 day, because no recording event synodtvd: synodtvd.cpp:3078 Stop auto update epg, frontend busy synodtvd: synodtvd.cpp:1949 (auto) tuner 0 updating epg of channel France 2 synodtvd: synodtvd.cpp:334 [synodvbepg(automatically)] tuner 0 child process 26023 synodtvd: synodtvd.cpp:3013 daemon sleep: 1 day, because no recording event synodtvd: synodtvd.cpp:3078 Stop auto update epg, frontend busyetc etc ... Je vais essayer de downgrader aussi

Je suis tout a fait d'accord sur ton étonnement mais mon protocole de test me semble indiscutable: j'ai fait participer des membres d'un forum android contactés en privé ainsi que que des collègues, tous utilisant strictement les mêmes settings (me suis fendu d'une petite doc dont je leur avais communiqué l'url) *Aucun* Xperia tournant Android 4.4 et + n'a pu se connecter alors que *tous* les autres appareils androids l'on fait sans coup férir. Bien entendu je suis prêt à communiquer le lien en MP a tout propriétaire d'Xperia passant par ici et souhaitant faire le test.

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