This site uses cookies! Learn More

Ce site utilise des cookies !

En continuant à utiliser ce site, vous vous engagez à nous permettre de stocker des cookies sur votre ordinateur.

CoolRaoul

Membres
  • Compteur de contenus

    5 532
  • Inscription

  • Dernière visite

  • Jours gagnés

    41

CoolRaoul a gagné pour la dernière fois le 23 avril

CoolRaoul a eu le contenu le plus aimé !

À propos de CoolRaoul

  • Rang
    Brigade Synophile

Profile Information

  • Gender
    Male
  • Location
    Marseille

Visiteurs récents du profil

4 800 visualisations du profil
  1. Pourquoi parles-tu de Windows 7 , 8 etc ???? Je suis sous windows 10 (pas pro) et je serais surpris que, sur ce point, le fonctionnement soit différent sous home. M'étonnerais pas que tu n'ai pas testé exactement dans le même contexte. Enfin, bref, à part ça, je constate que tu es parvenu à épuiser la patience de @Lucien77 @Mic13710 (qui pourtant en ont vu d'autres!) et les autres participants à ce fil. Mon tour est venu de lâcher prise. Bonne continuation.
  2. je n'ai jamais dis le contraire. J'ai pris le temp de tester (ce que tu aurais pu également faire de ton côté avant d"émettre des hypothèses): en fait ça n'a aucun rapport avec le fait d'être ou pas sur un compte admin. C'est uniquement quand on se connecte, dans le contexte de sa session Windows, au NAS avec une compte (username) *différent* du celui de la session windows qu'un mapping (net use) est créé (peut-être également si le mot de passe est différent, j'ai pas testé jusque là) Donc dans ton cas, puisque apparement c'est de cette façon que tu pratiques (username NAS <> username Windows) la solution donnée par @Fenrir me semble la plus rapide. Suffit juste d'ajouter juste un "/yes" à la commande net use pour se passer de confirmation: net use * /delete /yes
  3. Ca à toujours fonctionné comme ça pour moi sur tous les Windows que j'utilise, que ce soit à domicile ou au travail Je suis connecté à mon Windows sur un compte simple utilisateur avec les même identifiants (user/pass) que mon compte DSM et je n'utilise pas le mappage de lecteur (n'en ai jamais eu le besoin), uniquement les chemins UNC (format "\\nom\..."). Me semble que c'est une pratique courante. Les compte admin Windows et du NAS je les réserve pour des actions nécessitant des privilèges, ponctuellement donc. Si on relit ton premier message, il n'était pas question de serveur distant que je sache je cite: Ce qui rend encore plus inexplicable d'avoir dit un peu plus haut que tu ne connaissais pas cette méthode
  4. Bien entendu: je le fais régulièrement et ça marche aussi bien avec juste le nom du serveur ou avec un chemin complet.
  5. Comme pour toute connexon à un dossier réseau partagé sous Windows Et il existe plusieurs méthodes: démarrer -> exécuter -> "\\<monas>\<partage>\<chemin>" Dans la branche "réseau" de l'explorateur, en dépliant l'entrée correspondant au NAS Ou directement en tapant dans le champ adresse de l'explorateur:
  6. Merci de me prendre pour un newbie ... J'ai écrit "dans l'explorateur" et pas "dans le navigateur".
  7. Je ne pense pas que cette solution s'applique à tous les cas. Je suis actuellement connecté dans une session windows 10, via l'explorateur j'ai bien accès à mon nas en utilisant sur mon compte DSM et malgré ça, voici ce que "net use" dans une boite de commande me répond: $> net use Les nouvelles connexions seront mémorisées. La liste est vide.
  8. Normalement faudrait ouvrir un ticket de support chez Syno. Mais mes deux dernières expériences m'ont franchement découragé. Je laisse ça aux plus patients que moi (d'autant plus que, la commande n'étant pas documenté et donc pas officiellement supportée, ça leur serait encore plus facile de botter en touche)
  9. Les différents modèles de freebox font du proxy WOL (si configuré). Pour les autres, même d'éventuelles méthodes détournées ne peuvent s'appliquer de façon fiable car les entrées de la table ARP expirent assez vite, quelques minutes typiquement.
  10. En fait j'ai dis ça car à ma connaissance aucune box ni routeur envoie spontanément un "paquet magique" lors d'une simple tentative de connexion externe vers une IP du LAN déclarée dans la table de redirection de ports (faudrait déjà qu'elle en mémorise l'adresse MAC de façon permanente pour ça)
  11. Je ne pense pas que ce soit suffisant: il se réveille uniquement sur réception d'un "Magic Packet" (broadcast, UDP, port 0, 7 ou 0 et contenant l'adresse MAC du NAS)
  12. Faudrait qu'un cador du debug http/javascript (F12 dans la plupart des navigateurs) puisse analyser en live ce qui se passe dans ce genre de situation pour avoir des pistes.
  13. Mon petit grain de sel pour témoigner que je fais face (depuis toujours il me semble) au même phénomène, particulièrement quand la connexion doit traverser un proxy. @crunch ne serait-ce pas dans ce cas également que tu le constate? A noter également qu'une fois loggé la réactivité est tout à fait correcte.
  14. Pas constaté chez moi, mais faut dire que mon script de démarrage dans "/etc/local/etc/rc.d" est en réalité un lien symbolique vers un fichier situé ailleurs. C'est peut-être grâce à ça que j'ai été épargné.
  15. Parfait Éventuellement si ça t’intéresse je pourrais t'expliquer plus tard comment rendre cette clé SSH dédiée exclusivement aux commandes "synoservice --pause samba" et "synoservice --resume samba". C'est pas indispensable mais un peu plus propre, en particulier dans le cas comme ici d'une clé "passwordless".