CoolRaoul

Ne pas confondre l'utilisateur "root" de mariadb et celui de DSM. Me semble bien que phpmyadmin refuse la connexion avec un mot de passe vide, mais j'ai pas envie de tester et de me retrouver coincé.

Ma question s'applique aussi a celui qui n'utilisait pas MySQL précédemment et installe directement MariaDB. Comment celui-la fait-il pour changer le mot de passe "root" de la base?

Et si ça résout le problème, tu nous feras 100 lignes de "Have you tried turning it off and on again" http://youtu.be/C2Ph8zwpNyI

Oui:

Merci de m'ajouter au club. Question subsidiaire: qui saurait quelle est la méthode préconisée comment modifier le mot de passe du compte "root" de la base? Si on fait un reset via le bouton ci-dessous, ça met un mot de passe vide et on ne peut plus se connecter à phpmyadmin qui refuse les mot de passe vides. **EDIT** Suffirait d’arrêter/redémarrer MariaDB d’après ce post.

Il semblerait que ce soit le cas: http://www.neverstopbuilding.com/mount-ssh-on-osx

L'approche "nominale" préconisée par Synology serait a mon avis d'utiliser le SDK ("toolchain") officiel pour cross compiler sur un Linux de son choix. En effet "optware" (AKA "ipkg") n'est pas officiellement supporté et c'est d’ailleurs la première chose que le support officiel demande de désinstaller en cas de problème avant d'accepter d'investiguer. C'est pas forcément trivial mais documenté La doc est à prendre ici ("guide des développeurs tiers") Pour la toolchain, c'est au même endroit en choisissant le lien "Trousses à outils et source GPL" en et ensuite "DSM 5.0 Tool Chains" Pour simplifier le travail, l'équipe "synocommunity" (dont les membres sont très actifs dans ce forum) met à disposition un "framework" de developpement ("spksrc") qu'on peut trouver ici: https://github.com/SynoCommunity/spksrc qu'on peut utiliser si on le souhaite.

Mais Emacs ce n'est pas la pomme (et d'ailleurs "GNU is Not Unix" -private joke pour les initiés-) : ca existe depuis les années 1970! Comme je l'ai écris ça serait plutot un truc de vieux barbus, pas réservés aux d'Apple fanboys. Il se trouve que ça été porté sur un nombre incalculable d'O.S. y compris OS X donc.

Ça te permet de jeter un oeil aux logs (centre des journaux) déjà. Rien de ce coté? Ah voila, c'était donc bien ça.

Ca ressemble à un blocage IP Essaie de changer provisoirement l'IP de ton PC. Si ça permet de te connecter tu pourra effacer le blocage Faudra ensuite comprendre ce qui l'a provoqué, tu verra ça dans les logs DSM.

Commencer par activer les différents journaux de modifications de fichiers, on sait jamais ça peut donner des indications si ça se reproduit: FileStation: Paramètres -> Général -> Activer le journal de File Station SMB (CIFS): panneau de conf -> Service de fichiers -> Win/Mac/NFS -> Service de fichiers Windows -> activer le journal des transferts Webdav (ce qui inclue DSFile): panneau de conf -> Service de fichiers -> Webdav -> Paramètres Avancés -> Activer le journal Webdav (peut-être que j'en oublie) **EDIT** Et en effet, j'ai oublié les module "FTP" et "TFTP" de la catégorie "Service de fichiers" qui, eux aussi, disposent chacun d'une option journal.

Ce n'est pas parce que c'est un peu moche que ça ne mérite pas le nom de GUI Suffit d'activer la toolbar et on dispose des éléments principaux d'un GUI: Et sous OS X il y a Aquamacs qui a quand même de la gueule non? (pas vérifié si tramp était compatible avec ce dernier toutefois)

Pas exactement, regarde: Non:j'utilise emacs (sous Windows dans mon cas mais il existe aussi sous OS X)Par contre, comme j'ai dis; faut pas mal de temps et de patience pour le prendre en main. **EDIT** Je réalise que, vu comme ça, ça ne ressemble pas forcément à un GUI pour file manager distant. En fait emacs c'est bien plus que ça, au départ c'est un editeur de texte mais qui embarque des centaines de modules complémentaires tels qu'un file manager ("dired" ici) et sait s'interfacer avec des modules d'accès à distance ("tramp" qui rend quasi transparent l'acces aux fichiers à travers différents types de transport, ssh/scp, ssh/sftp et même un simple telnet)

Attention: sous DSM, SFTP ne permet l’accès qu'aux dossiers partagés. Si on veut (notamment par le compte root) accéder aux dossiers systèmes, SCP est nécessaire. Enfin le lien date un peu (de l'époque ou sftp n'était pas nativement supporté par DSM et il fallait bidouiller le sshd-config)

Vu la question je pense qu'il cherche un GUI pour SCP et qu'une méthode ligne de commande risque de le décevoir (bien que cela à l'avantage d'être natif sous OSX). D’après ce que je lis ici, en gratuit sur Mac il n'y pas vraiment d'alternatives. Ou alors, oserai-je proposer Emacs + Tramp? Mais j'ai bien peur que ce soit plus une solution pour les vieux barbus et si on ne connait pas emacs, la "learning curve" risque d'être un peu raide.

Tu n'a pas bien compris le principe: une redirection de port implique une IP cible, hors, par définition, on suppose que le NAS est *éteint* lorsque le routeur (ou la box) reçoit le paquet WOL. Il n'a donc pas d'IP à ce moment (et qu'il soit configuré en IP statique n'y change rien). Comme je l'ai dit plus haut, les routeurs (box) qui supportent le "proxy WOL" retransmettent coté LAN le paquet reçu sur le WAN en mode "broadcast", pas besoin d'IP cible dans ce cas. Dans ce mode, toutes les cartes ethernet du LAN vont voir passer le paquet et c'est l’adresse MAC qui est dans la partie données qui identifie l’équipement à réveiller (pas dans l'en tête puisque en mode broadcast le champ MAC cible contient FF:FF:FF:FF:FF:FF (*) Si le routeur n'a pas la fonction "Proxy WOL", Il peut quand même y avoir une possibilité si il supporte l'ajout d'entrées statiques dans sa table ARP pour y mettre celle du NAS associée à son IP (qui doit être fixe donc). C'est expliqué dans le paragraphe "Paquet magique" de l'article Wikipedia. Dans ce cas, bien que le paquet ne sera retransmis en mode broadcast, il jouera quand même son rôle si le firmware de la carte ethernet de l'équipement à réveiller traite aussi les paquets WOL non broadcast.

Le blocage au niveau de la commande "LIST" indique que le flux "data" est coincé quelque part, ce qui peut être le symptôme d'un défaut de redirection de ports ou bien d'un oubli de l'utilisation du mode passif (je laisse de coté les interactions avec un firewall, coté client ou coté serveur qui la aussi peut bloquer les ports du canal data). Là apparemment tu as vérifié les deux pistes, donc je ne vois pas trop.

Suis un peu confus là: quand tu parle de "ton PC" sur lequel la connexion marche tres bien il s'agit bien de ton PC du travail alors? **edit oups en effet

Tu as probablement oubli

Ah pardon, j'avais répondu un peu vite. Mais ce n'est pas normal ce plantage. Essayer de chercher le message d'erreur dans google peut-être que d'autre l'ont déjà rencontré (et résolu). En tout cas utf8 est bien le codage à utiliser. Tout dans netdrive plus précisément: il doit bien y avoir deux niveau d'options, globales (générales) et spécifiques (à chaque dossier webdav ). Le problème est que je ne me souviens pas (je n'utilise plus netrive depuis un bout de temps)

Ah je n'ai plus netdrive installé pour vérifier ça mais peut-être dans les options (globales ou spécifique au dossier webdav) on peut forcer le jeux de caractères en utf8?

Je suis surpris par le préfixe "@": il normalement réservé aux dossiers systèmes et je pensais qu'il n'était pas possible d'avoir des dossiers partagés nommés ainsi (et par suite de les sauvegarder avec le sauvegarde DSM). Comment as-tu ben pu t'y prendre pour qu'un tel dossier soit pris en compte par la sauvegarde?

Mapper un chemin webdav à une lettre de lecteur c'est possible en utilisant netdrive a la place du webdav intégré à windows. Prendre netdrive en version 1.X (cf ici: )

/usr/syno/sbin/synoservicecfg --restart crond