Depuis des années j’utilise mon ordi principal pour partager des fichiers vers mes autres machines, machines virtuelles pour les tests, NVidia Shield pour les vidéos, ou mon laptop sous Linux pour récupérer des fichiers de travail. A un moment, ça a arrêté de fonctionner. J’ai enfin compris pourquoi et c’est le sujet de cet article.
Avec ma Shield, j’utilisais Kodi pour accéder à mes fichiers, sans problème puis d’un coup cela s’est arrêté. J’ai pensé qu’il s’agissait d’un problème avec une nouvelle version de Kodi, donc en attendant j’utilisais VLC en direct qui lui fonctionnait sans problème.
Parallèlement, je joue beaucoup avec des distributions Linux, mais à chaque fois que je voulais m’en servir pour de vrai (par exemple sur mon laptop, sur lequel je ne joue pas), j’avais des soucis. Ce qui me heurte beaucoup en temps que libriste convaincu et qui constitue une vraie barrière pour moi à la démocratisation de Linux sur les machines de Bureau. Soit il s’agit d’un problème de son, ou de drivers vidéos ou surtout d’accès au réseau. Bref, jamais tranquille.
Pourtant, sur les réseaux je suis des libristes et de plus en plus d’entre disent s’ennuyer maintenant parce que tout fonctionne chez eux out-of-the-box. Et pas chez moi, pourquoiii ?
Bref, je profitais récemment d’un nouveau test, cette fois de la distribution FerenOS qui fait sensément tout plus mieux que les autres et le café avec.
Encore une fois le parcours du réseau était impossible, message d’erreur et tout et tout. Sauf que cette fois, j’ai fait une réussite critique en Google-Fu et que j’ai trouvé la solution. Et si le problème vient bien de Linux, la solution se trouve côté Windows.
En effet, suite à un bug dans le backend GVFS, les versions supérieures à smb1 (le protocole utilisé pour la découverte du réseau et le partage de fichier) ne sont pas prises en charge par Linux.
Or, les versions récentes de Windows 10, pour des raisons de sécurité, désactivent smb1, vieux de 30 ans, ce qui est normalement une excellent idée, mais qui dans notre cas précis casse, sans prévenir, l’autre côté.
La solution tient en une ligne.
Ouvrez un terminal Powershell en mode Admin et tapez la commande ci-dessus. L’ordi va redémarrer (violemment et sans vous demander votre avis, GG MS), puis smb1 sera activé.
De retour dans ma VM de test FerenOs, le gestionnaire de fichier Nemo voit instantanément la machine de partage, les partages eux-mêmes et après une demande légitime d’authentification me donne enfin accès aux fichiers convoités, et un double-clic lance une vidéo avec VLC très rapidement et sans buffering.
Je suis un peu embêté pour la conclusion.
En effet, Windows a colmaté un trou de sécurité important, et un bug dans Linux fait qu’on ne peut plus s’y connecter, du coup MS 1 – Linux 0
La correction serait problématique dans un environnement moins personnel que le mien et ne fonctionnera pas dans un environnement où je n’ai pas la maîtrise du serveur.
Il existe des solutions de contournement (notamment monter le partage distant en ligne de commande, ou en passant par le fichier /etc/fstab) mais ce n’est absolument pas user-friendly et contredit, à mon sens, la facilité supposée d’utilisation du bureau Linux.
Si quelqu’un a trouvé une solution plus élégante que la mienne, n’hésitez pas à m’en faire part, en attendant je vais pouvoir remater mes films de vacances, tranquillement, dans mon canap’ jusqu’à la prochaine fois.
Ressources
Un point global sur le sujet
https://forums.linuxmint.com/viewtopic.php?t=322404
Stop using SMB1
https://techcommunity.microsoft.com/t5/storage-at-microsoft/stop-using-smb1/ba-p/425858