Pourquoi il faut désactiver le protocole SMB1 sous macOS
Si vous utilisez des partages réseau avec votre Mac, il y a une petite manipulation qui semble nécessaire, parce qu'Apple a décidé pour des raisons obscures de ne pas le faire pour vous : désactiver la prise en charge du protocole SMB "1".
Un protocole abandonné par Microsoft
La première version du protocole SMB — Server Message Block — est très ancienne et son développement a commencé dans les années 80. Elle a été popularisée par Windows 2000 et considérée comme obsolète dès 2013. Dans les faits, Microsoft a commencé à désactiver le protocole par défaut dès 2017 avec Windows 10, et les NAS et autres serveurs (comme les Freebox) ont peu à peu laissé le protocole sur le côté avec le temps pour forcer SMB2 et SMB3. Sauf Apple.
Une question de sécurité
Comme l'explique bien Microsoft sur son site, SMB1 est obsolète, peu sécurisé — il existe de nombreuses failles — et plus lent que les autres versions. La société recommande donc de ne plus l'utiliser.
Mais macOS, par défaut, emploie encore le SMB1. Une page du site d'Apple explique heureusement comment le faire, en espérant qu'une prochaine version de l'OS ne nécessite plus cette manipulation. Dans le Terminal, il faut simplement taper les deux lignes qui suivent, avant de redémarrer le Mac.
echo "[default]" | sudo tee -a /etc/nsmb.conf
echo "protocol_vers_map=6" | sudo tee -a /etc/nsmb.conf
Si vous avez l'habitude de la ligne de commande, les deux lignes vont créer le fichier /etc/nsmb.conf (absent par défaut) et ajouter deux lignes.
[default]
protocol_vers_map=6
La valeur par défaut est 7 et indique que les protocoles SMB1, SMB2 et SMB3 sont acceptés. La valeur 6 n'active que les variantes SMB2 et SMB3 et si vous êtes certains que vos périphériques supportent tous SMB3, il est même possible de forcer la valeur 4 (SMB3 uniquement). Si jamais vous avez des soucis de connexions à de vieux NAS ou à des partages réseau, il demeure possible de réactiver la prise en charge de SMB1 — même si c'est une mauvaise idée — en remplaçant le 6 par un 7 dans le fichier ou en supprimant le fichier en question dans le Terminal avant de redémarrer, avec la commande suivante.
rm /etc/nsmb.conf
A noter que les échanges de fichier vont plus vite en SMB2/3 qu'en SMB1.
Autre point, VLC sur tvOS n'enregistre pas le user/password si le serveur est SMB1, alors que ca passe en SMB2/3
Pour un système sensé ultra simple, c’est pas le genre de manip a demander aux utilisateurs, 99% d’entre eux n’utilisent pas le shell.
Apple doit faire ça dans un update !
@melaure
#Team99% 😁
quand on a un Mac à l'électricité pas besoin d'aller chez Shell ... ou Total ou BP
Euh ... ah ? ce n'est pas ça
OK je =>
@melaure
Ou alors expliquer comment le faire avec vi... heu TextEdit.app
@koko256
Ou alors expliquer comment saisir des [ ] sur un clavier Apple (il a fallu que je cherche, jeune padawane que je suis - premier Mac depuis 2j 🤓)
@Deuxbase
Pour info
[] et {} avec alt () et alt-shift ()
| avec alt-shift L (le l ressemble au |)
~ avec alt-n puis espace
\ avec alt-shift : (le shift-: fait /)
Et pas moyen de lancer SIGQUIT avec ctrl-\ ou ctrl-| cela ne marche pas. Il faut changer avec stty (j'ai mis ctrl-N)
« Apple a décidé pour des raisons obscures de ne pas le faire pour vous »
La raison n’a rien d’obscur. Elle est même indiquée à la fin de l’article : « Si jamais vous avez des soucis de connexions à de vieux NAS ou à des partages réseau, il demeure possible de réactiver la prise en charge de SMB1 ».
Conserver la prise en charge de cette version dans son client SMB, ça permet d’éviter que des clients se retrouvent brusquement incapable d’accéder à certains de leurs appareils, alors que ça fonctionnaient jusque là. Et ces appareils ne se retrouveraient pas plus sécurisés pour autant, vu que ce sont eux qui font tourner un serveur SMB1.
Désactiver la prise en charge de ce protocole dans les serveurs, c’est parfaitement normal.
Du côté des clients, je trouve que ça l’est moins. Je trouverais plus intéressant d’avoir une fenêtre d’avertissement, qui pourrait inciter l’utilisateur à reconfigurer son serveur ou à en changer.
@BeePotato
On peut dire que c’est pour des raisons obscures étant donné leur habitude à faire des changements qui laisse de côté du plus ou moins ancien matériel/logiciel de manière général sans prévenir.
@ DrStax : « On peut dire que c’est pour des raisons obscures étant donné leur habitude à faire des changements qui laisse de côté du plus ou moins ancien matériel/logiciel de manière général sans prévenir. »
Le jour où ils décideront de larguer SMB1, ce sera en effet sûrement fait « sans prévenir » (guillemets, car en fait on est généralement prévenu quelques mois à l’avance avec les versions beta — mais c’est à la fois un délai bien court et un mode d’information très léger et peu grand public).
Ça ne signifie par pour autant que c’est bizarre qu’ils l’aient gardé pour l’instant.
Ce qui serait bizarre vis-à-vis de l’habitude que tu cites, ce serait qu’Apple prévienne une ou deux versions à l’avance que ça va être abandonné.
@BeePotato
"Conserver la prise en charge de cette version dans son client SMB, ça permet d’éviter que des clients se retrouvent brusquement incapable d’accéder à certains de leurs appareils, alors que ça fonctionnaient jusque là."
non mais LOL
Si il y a bien un truc dont Apple se tape COMPLET, c'est les histoires de rétro-compatibilité avec les anciennes technos ... ou connectiques
Je suis pas sur que ce soit l'argument le plus pertinent. "Osef" serait une meilleure explication
@BeePotato
En fait il suffit bien souvent de remplacer le nom réseau par exemple \\DiskStation\ par son IP locale \\192.168.1.200\ en refaisant les raccourcis qui y mènent, pareil pour l’imprimante.
.
Certes c’est moins parlant mais ça fonctionne.
@ FrDakota : « Certes c’est moins parlant mais ça fonctionne. »
Je ne vois pas bien pourquoi le fait d’utiliser l’IP au lieu du nom provoquerait un changement de protocole de partage de fichiers.
@ Pierre Dandumont : « Non. C'est une mauvaise idée parce que SMB1 n'est pas sûr, lent, daté. »
C’est au contraire une bonne idée, car ça permet de continuer à utiliser des appareils anciens qui ne seront jamais mis à jour pour proposer un autre protocole.
« Microsoft l'a fait, et sur le coup, c'est passé parfaitement »
Peut-être parce que Microsoft ne l’a pas supprimé complètement : dans la mise à jour de Windows 10 qui a « supprimé » SMB1, le client est toujours installé par défaut dans l’édition Famille (celle utilisée dans les cadres où on veut aider des gens à continuer à utiliser les appareils en leur possession alors qu’ils ne disposent pas d’un service informatique pour les y aider), et n’est supprimé automatiquement qu’au bout d’un certain temps s’il n’est jamais utilisé.
Et bien sûr, sur toutes les éditions, il peut être réinstallé au besoin.
Pas vérifié pour Windows 11, mais j’imagine que c’est pareil.
Et sinon il y aura quand un correctif sur le bug des fichiers bloqués après les avoir déplacés dans un sous dossier ? Bug depuis macOS 12 et toujours présent dans macOS 13 quelque soit le serveur ( testé sur dossier partagé depuis un autre Mac, un nas synology ou Qnap et idem sur un dossier windows server…)
Tiens c'est quoi le bug dont vous parlez exactement ?
Je ne le rencontre pas perso.
Par contre depuis Big Sur Apple a viré l'icône représentant un serveur dans le Finder, et on a donc une icône générique toute moche.
Il serait bien de remettre une icône plus adaptée.
@Musyanon
Ça ne me dit rien non plus ce bug, tu peux détailler pour que j'essaie ?
[edit] je viens de me rappeler que via le Finder j'utilise AFP que j'avais trouvé beaucoup plus fiable lors des tests (mais j'étais sûrement en SMB1)
@Yohmi
Depuis le serveur monté en smb, lorsque tu glisse un fichier depuis un dossier du serveur dans un sous dossier tu ne peux plus l’ouvrir sans relancer le Finder :(
Ça se produit à chaque fois. Il n’y avait pas le souci dans big sur, c’est arrivé avec monterey…
Je trouve aucune solution à ce problème !
Édite: j’avais fait le test en afp et même souci.
@Musyanon
Je viens de faire le test.
Il me dit "élément introuvable" si j'essaie de l'ouvrir. Y'a bien un problème visiblement. Par contte, si je renomme le fichier, là il s'ouvre sans problème et sans relancer le Finder.
@Yohmi
Oui en dirait que le Finder n’actualise pas le déplacement des fichiers mais en renommant ça fonctionne en effet…
Ah oui tiens, je viens d'essayer aussi. Par contre dans le cas d'une vidéo, avec QuickLook il sait encore la lire, mais si on double-clique dessus on a un message d'erreur.
Et moi qui ai supprimé des fichiers il y a quelques jours en pensant qu'ils étaient corrompus... en fait c'est simplement ce bug qui se présentait mais dont je n'avait jamais entendu parler.
Et visiblement le même bug se présente quand on remonte un fichier dans l'arborescence (donc passage d'un sous-dossier au dossier parent par exemple).
@LolYangccool
Oui et c’est bien relou :(
Oui, c'est pénible.
Encore un bug qu'Apple doit juger comme « non prioritaire » et qui va perdurer pendant 10 ans dans macOS. :(
@LolYangccool
j'ai un autre bug il arrive que aperçu, excel ou word ne puissent pas ouvrir les fichier sur le NAS bien que quickLook fonctionne.
dans ce cas il faut redémarrer
@Musyanon
j'ai constaté ce genre de chose au travail le Mac écrivait des fichiers sans aucun droit sur des volumes de notre serveur WIN 2012 R2. Excel ou Word pouvait faire la même chose. J'ai compris tardivement après avoir perdu des heures de travail, que les fichiers n'étaient pas perdu définitivement. depuis le serveur Windows, il suffisait de remettre les droits sur le fichier. ces problèmes ont disparu quand j'ai décider de migrer toutes les données du serveur vers un gros NAS synology RS1221+
J'ai un DS1621+ et le bug décrit par @Musyanon est présent aussi.
Il faudrait que j'essaye avec un serveur Windows mais à priori ça n'a rien à voir avec le système du serveur, mais c'est bien macOS qui est buggé.
@iKalimero
Pourtant le bug que je cite est présent aussi sur c’est Nas. Le problème est vraiment lié au Finder depuis monterey. Si on utilise un explorateur de fichier autre que le Finder cela fonctionne…
Tant qu’Apple ne corrige pas c’est foutu, sauf s’il y’a une correction qu’on peut appliquer par ligne de commande ou autre, mais je ne trouve pas.
@Musyanon
Oui c'est vraiment lié au Finder, et pas au serveur en face.
Plutôt étrange un tel oubli, merci pour l’info.
“Les récentes mises à jour de macOS semblent écraser le fichier /etc/auto_master”
Voir ici (Restoring autofs after macOS updates) :
https://gist.github.com/rudelm/7bcc905ab748ab9879ea?permalink_comment_id=3897636
Pourquoi désactiver SMB1? Il ne sera utilisé, de toutes façons, que si on accède à un serveur l'utilisant, non? Donc un cas de figure où on devrait le réactiver!
Si les serveurs auxquels on accède utilisent SMB2 ou 3, le fait d'avoir SMB1 activé ne gêne pas, si?
J'ai exactement le même point de vue.
C'est côté serveurs qu'il faut abolir SMB1, pas forcément côté clients pour lesquels il peut être judicieux de garder une rétrocompatibilité.
C'est comme pour les suites cryptographiques. Les OS modernes bannissent toutes les suites jugées obsolètes, mais le jour où tu dois justement te connecter à un très vieil équipement qui utilise ces suites obsolètes (soit parce qu'il est incompatible soit justement pour le remettre à niveau) tu dois bidouiller ton OS pour contourner toutes les protections et là potentiellement tu réduis la sécurité de ton système.
Alors qu'en soit, ça ne change rien côté client d'autoriser des protocoles obsolètes qui ne seront utilisés que dans les rares cas où les protocoles plus récents sont incompatibles.
A la rigueur mettre un message d'information lors de l'utilisation de ces protocoles, pourquoi pas.
@idhem59
un des cas les plus fréquent c'est le cas d'un NAS type Syno. Et en un clic on force le SMB2/3 et zou
@ Pierre Dandumont : « Mais le désactiver permet de se rendre compte que des appareils utilisent encore SMB1... et régler ça. »
Un client qui afficherait un message d’avertissement (prévenant de l’obsolescence du truc, mais aussi d’une possible fin de support dans le futur) permettrait tout autant cette détection, tout en permettant de continuer à utiliser les machins qui ne peuvent pas être mis à jour.
Pourquoi ne faites vous pas plus souvent d’articles plus techniques, tel que celui-ci ?
@BarbATruc
"Pourquoi ne faites vous pas plus souvent d’articles plus techniques, tel que celui-ci ?"
Je vais être très très critique sur ce sujet : Oubliez ça ! Ça fait des siècles que j'attends ça (20 ans) mais non... des articles sur des... (auto-censuré pour l'instant)
Bon je me suis calmé là...
Un poil hors sujet mais je profite de ce topic pour lancer une bouteille à la mer. J'ai énormément de bugs d'affichages lorsque je navigue et travaille sur des fichiers présents sur un serveur MS (SMB3) :
- Fichiers récents qui erratiquement ne sont pas visibles dans le finder bien que présents sur le serveur
- Lenteurs dans l'enregistrement de fichiers : 30secondes de beach ball pour un simple fichier excel et créations de dossiers et fichiers temporaires qui ne sont pas systématiquement supprimés.
- Problèmes de droits divers et variés avec des fichiers qui passent en lecture seule ou des fichiers qui "peuvent être enregistrés mais pas réouverts car violation de partage"
...
J'ai essayé diverses lignes de commandes pour empêcher l'écriture de .DS_Store sur disques réseaux, désactiver la la signature des paquets pour les connexions SMB 2 et SMB 3, et maintenant forcer le SMB 3, mais rien n'y fait. Dès que je dois faire quoi que ce soit sur le serveur de mon entreprise c'est la foire aux bugs.
Est-ce que quelqu'un ici est déjà passé par là ou connaitrait une solution ? (macOS 13.0.1 (22A400) sur Macbook Pro M1)
@Louno
Est-ce que ces lenteurs existent aussi sur les ordi de ton boulot ?
Ça ressemblerait plus à un problème de configuration de partage de ton serveur (lenteurs …)
@Louno
je poste la même réponse faite @Musyanon
j'ai constaté ce genre de chose au travail le Mac écrivait des fichiers sans aucun droit sur des volumes de notre serveur WIN 2012 R2. Excel ou Word pouvait faire la même chose. J'ai compris tardivement après avoir perdu des heures de travail, que les fichiers n'étaient pas perdu définitivement. depuis le serveur Windows, il suffisait de remettre les droits sur le fichier. ces problèmes ont disparu quand j'ai décider de migrer toutes les données du serveur vers un gros NAS synology RS1221+
De nombreuse imprimante multifonctions réseau scanne sur le réseau via le protocole SMB1, quand ce n'est pas du FTP.
Sauf que si vous avez encore une Time Capsule Apple, comme elles ne causent qu'en SMB1 avec votre Mac, si vous désactivez ce protocole, alors vous n'y aurez plus accès via le partage de fichiers !!!
Malheureusement il semblerait qu'Apple n'ait pas l'intention de mettre à jour ses Time Capsules. 😠
Rq: Je ne sais pas si les sauvegardes TimeMachine ont besoin de ce protocole.
Sinon, je suis justement à la recherche d'une librairie open source en C (ou C++ ou Objective-C) pour justement utiliser ce foutu protocole. Quelqu'un aurait-il une piste ?
@marc_os
https://github.com/sahlberg/libsmb2
Y'a un wrapper en Swift il me semble.
Edit: libsmb2 ne supporte pas SMB1, attention.
Et le wrapper Swift est ici :
https://github.com/amosavian/AMSMB2
@ byte_order
> Y'a un wrapper en Swift il me semble.
Merci, mais je connaissais cette lib et le wrapper.
Si j'ai posé la question ici, même avec peu d'espoir, c'est justement parce que libsmb2 ne supporte pas SMB V1... Reste à étudier le code open source de VLC. Mais c'est une sinécure.
@marc_os
Ah pardon, je n'avais pas compris que c'était spécifiquement pour supporte la v1 de SMB.
> Reste à étudier le code open source de VLC. Mais c'est une sinécure.
Ou juste la librarie DSM qu'ils utilisent :
https://github.com/videolabs/libdsm
Mais j'imagine que vous connaissez déjà également.
Quid de cela, plutôt que de devoir étudier le code C pour faire votre propre wrapper :
https://github.com/naxos/SMBClient
?
@ byte_order
Je ne connaissais pas naxos, merci !
Je vais regarder ça avec grand intérêt.
(Je dois recourir à ce genre de chose car c'est pour une app pour ATV et tvOS ne propose pas NetFS comme du côté de macOS.)
PS: Je vois que naxos utilise aussi libdsm.
(j'avais oublié que VLC utilisait libdsm, car ça fait un moment que mon projet est en pause.)
Bon, quand je vais m'y remettre, ce sera probablement soit libdsm, soit naxos, mais je crois que je vais devoir recourir à libdsm car je veux faire du "streaming". En même temps, le code de naxos pourrait me fournir de bons exemples de l'utilisation de libdsm si nécessaire...
@marc_os
Les sauvegardes Time Machine (sur un NAS, Time Capsule) utilisent le protocole SMB ou AFP. (Historiquement AFP, et c’est possible en SMB depuis Sierra)
@ maxou56
> Les sauvegardes Time Machine (sur un NAS, Time Capsule) utilisent le protocole SMB ou AFP
Donc si on coupe SMB1, il faut utiliser l'AFP ! Si tant est que cela soit possible avec les dernières versions de macOS;
@marc_os
Les sauvegardes TM fonctionne parfaitement en SMB3
Pages