macOS Tahoe 26.4 a cassé les sauvegardes Time Machine SMB : correction nsmb.conf jusqu'à la version 26.5

Si vous avez installé macOS Tahoe 26.4 fin mars 2026 et que vos sauvegardes Time Machine vers un NAS Synology, QNAP, UGREEN, TrueNAS ou Asustor se sont brusquement interrompues, vous n'êtes pas seul. La version 26.4 d'Apple a silencieusement renforcé les paramètres par défaut de signature SMB du système d'exploitation, et cette modification a cassé les connexions Time Machine vers pratiquement tous les périphériques de stockage réseau tiers du marché. Le correctif 26.4.1 publié le 9 avril a résolu plusieurs bugs, mais n'a pas traité la régression SMB de Time Machine.

La bonne nouvelle est qu'il existe une solution de contournement connue que vous pouvez appliquer ce soir même, et qu'Apple a déjà corrigé le comportement dans macOS 26.5 bêta 4 (build 25F5068a, diffusée le 27 avril 2026). La mauvaise nouvelle est que la version publique 26.5 n'est pas attendue avant fin mai, juste avant la WWDC 2026 du 8 juin. Cela laisse la plupart des propriétaires de NAS sans sauvegardes fonctionnelles pendant plusieurs semaines, sauf s'ils interviennent manuellement.

Ce guide explique précisément ce qui a changé en interne, détaille la solution de contournement /etc/nsmb.conf avec le texte exact à coller, résume l'état de chaque grand vendeur de NAS, évalue les compromis sécuritaires liés à l'assouplissement de la signature SMB sur un réseau local domestique ou professionnel, et présente des stratégies de sauvegarde intermédiaires plus sûres à utiliser pendant l'attente. À la fin, vous devriez avoir une sauvegarde fonctionnelle, une compréhension claire de ce que vous avez accepté de céder et la méthode pour annuler la modification dès que macOS 26.5 sera disponible.

Points clés

• Ce qui s'est cassé : macOS Tahoe 26.4 a rendu la signature SMB obligatoire par défaut pour les connexions Time Machine. La plupart des NAS tiers n'annoncent pas la signature SMB d'une manière que macOS 26.4 accepte, donc la session SMB est rejetée avant que Time Machine puisse monter le sparsebundle.
• Vendeurs concernés : Synology DSM 7.2 et antérieur, QNAP QTS 5.1.x, UGREEN UGOS 1.x, Asustor ADM 4.x, TrueNAS SCALE 24.x par défaut, et bien d'autres cibles SMB tierces. Time Machine de macOS à macOS via SMB fonctionne toujours.
• Symptômes : « Time Machine n'a pas pu terminer la sauvegarde », « opération non autorisée », invites d'informations d'identification en boucle, sparsebundle monté mais signalé comme illisible, tentatives de resauvegarde complète qui s'arrêtent en quelques secondes.
• La solution : Créez /etc/nsmb.conf avec signing_required=no et protocol_vers_map=7 jusqu'à la mise à jour du firmware de votre NAS ou la sortie de macOS 26.5.
• Risque : La désactivation de la signature SMB expose la session SMB aux manipulations MITM sur le réseau local. Acceptable sur un réseau local domestique de confiance, moins acceptable sur un Wi-Fi de bureau partagé ou un espace de coworking.
• Calendrier du correctif : La bêta 4 de macOS 26.5 résoudrait la régression. La version publique 26.5 est attendue fin mai 2026 avant la WWDC.

Ce qui s'est cassé et quand

Apple a publié macOS Tahoe 26.4 fin mars 2026 comme deuxième mise à jour de fonctionnalités du cycle Tahoe. Les notes de version mettaient en avant les améliorations d'Apple Intelligence, une refonte de l'application Calendrier et une longue liste de correctifs de sécurité. Enfoui dans cette liste de sécurité se trouvait une modification du client SMB intégré à macOS, renforçant la façon dont le noyau négocie les sessions SMB. Apple n'a pas mis en avant ce changement dans les notes de version principales, mais l'effet pratique a été immédiat pour quiconque avait un NAS tiers comme destination Time Machine.

Dans les 48 heures suivant le déploiement de la version 26.4, le fil de discussion Apple Community numéroté 256221835 a commencé à recueillir des rapports de propriétaires Synology et QNAP décrivant des symptômes identiques. Une discussion parallèle sur Hacker News, élément 46848699, a accumulé des centaines de réponses d'utilisateurs exploitant toutes sortes de NAS grand public et prosumer. Le schéma était indéniable : des sauvegardes qui s'effectuaient chaque nuit depuis des années refusaient soudainement de s'initialiser à la première tentative après la mise à jour 26.4.

Apple a publié la version 26.4.1 le 9 avril 2026 pour traiter quelques régressions sans rapport, dont un problème d'itinérance Wi-Fi et un bug d'affichage de Mail. Le problème SMB de Time Machine n'était pas dans les notes de correctif 26.4.1, et les tests ont confirmé que la régression a survécu à la version intermédiaire. Les utilisateurs qui espéraient que la version 26.4.1 rétablirait silencieusement l'ancien comportement ont été déçus, et le ton du fil de discussion Apple Community est passé de « est-ce que je suis le seul » à « Apple doit reconnaître ce problème ».

Pour un aperçu plus large du cycle de publication 26.4 et des autres régressions à connaître, consultez notre guide complet de mise à jour pour macOS Tahoe 26.4 et 26.4.1.

La galerie des symptômes

La régression SMB de Time Machine se manifeste de plusieurs façons distinctes selon le vendeur NAS, la version du firmware et la configuration de Time Machine avant la mise à niveau. Les symptômes les plus courants sont listés ci-dessous dans l'ordre approximatif où ils apparaissent dans les rapports d'utilisateurs.

Time Machine échoue à s'initialiser lors de la première sauvegarde planifiée après la version 26.4. L'icône Time Machine dans la barre de menus tourne quelques secondes, puis affiche « Time Machine n'a pas pu terminer la sauvegarde vers [nom du partage] ». L'ouverture de Time Machine dans les Réglages Système montre que la destination est toujours configurée, mais la tentative de sauvegarde suivante échoue de manière identique.

Invites d'informations d'identification en boucle. macOS demande le nom d'utilisateur et le mot de passe du partage SMB, accepte les informations d'identification, puis les redemande immédiatement. Enregistrer les informations d'identification dans le Trousseau ne sert à rien car la session SMB elle-même est rejetée à une couche inférieure à l'authentification.

« Opération non autorisée » ou erreur POSIX 1. Il s'agit de la chaîne d'erreur la plus courante dans les journaux sous-jacents. Elle apparaît parce que le sparsebundle sur le NAS est techniquement accessible, mais macOS refuse de le monter parce que la session SMB a été déclassée ou négociée sans les propriétés de signature que macOS 26.4 exige désormais.

Sparsebundle monté mais signalé comme illisible. Un petit sous-ensemble d'utilisateurs voit le volume de sauvegarde monté dans le Finder, mais Time Machine signale que le volume ne peut pas être utilisé. Cela se produit généralement lorsque le partage négocie une session SMB1 ou SMB2 non signée en repli et que macOS refuse d'y écrire.

Tentatives de resauvegarde complète qui s'arrêtent en quelques secondes. Certains utilisateurs ont essayé de « résoudre » le problème en supprimant la destination et en la rajoutant, espérant qu'une nouvelle sauvegarde fonctionnerait. Au lieu de cela, la resauvegarde négocie la même session SMB défectueuse et s'arrête presque immédiatement, laissant parfois un sparsebundle vide sur le NAS.

Entrées du journal Console référençant smbfs, signature mismatch ou STATUS_ACCESS_DENIED. L'ouverture de Console.app et le filtrage sur smb pendant l'échec révèlent des messages du noyau sur la négociation des signatures. Il s'agit de la preuve irréfutable du changement de signature.

Si vous constatez plusieurs de ces symptômes simultanément, vous êtes presque certainement victime de la régression de signature SMB 26.4 plutôt que d'une panne matérielle NAS, d'un problème réseau ou d'un sparsebundle corrompu. Pour des diagnostics Time Machine plus larges qui s'appliquent quel que soit le niveau SMB, le guide complet de dépannage Time Machine couvre le reste du domaine.

Pourquoi ça s'est cassé : explication du changement de signature SMB d'Apple

Pour comprendre pourquoi la solution de contournement fonctionne, il est utile de savoir ce qu'est réellement la signature SMB et pourquoi Apple a décidé de changer le paramètre par défaut dans la version 26.4.

La signature SMB est une fonctionnalité du protocole Server Message Block, le protocole de partage de fichiers que macOS utilise lorsque vous vous connectez à un partage Windows, un serveur Samba ou un NAS. Lorsque la signature SMB est activée, chaque paquet que le client envoie au serveur inclut une signature cryptographique dérivée de la clé de session. Le serveur vérifie la signature sur chaque paquet et signe ses réponses de la même façon. Il en résulte qu'un attaquant sur le même réseau ne peut pas falsifier le contenu des fichiers en transit sans que la signature échoue et que la connexion soit coupée.

La signature SMB existe depuis SMB1 et est obligatoire dans SMB3 par défaut pour de nombreuses charges de travail Windows. La négociation de protocole entre client et serveur détermine si la signature est « non utilisée », « activée mais facultative » ou « obligatoire ». Jusqu'à macOS 26.4, le client SMB macOS acceptait de négocier une session non signée si le serveur n'exigeait pas la signature, ce qui était le chemin emprunté par la plupart des NAS grand public pour des raisons de performance.

Dans la version 26.4, Apple a modifié le paramètre par défaut de macOS de sorte que le client exige désormais la signature sur la session, sauf instruction contraire explicite. Lorsque le client se connecte à un NAS qui annonce la signature comme disponible mais non obligatoire, macOS refuse désormais de revenir au mode non signé. La négociation de session se termine par une erreur, le montage SMB échoue et Time Machine n'a aucune destination vers laquelle écrire.

Pourquoi Apple a-t-il fait cela ? Ce changement est cohérent avec une initiative industrielle pluriannuelle visant à renforcer SMB. Microsoft a rendu la signature obligatoire par défaut dans Windows 11 24H2, la communauté SMB migre vers SMB 3.1.1 avec signature obligatoire, et les clients enterprise d'Apple demandaient la même chose. Le modèle de menace des ransomwares inclut des attaquants qui pivotent d'un endpoint compromis vers un partage de fichiers et manipulent les fichiers de sauvegarde en transit, et la signature SMB est l'une des mesures d'atténuation les plus propres.

Le problème est que les vendeurs de NAS n'avaient pas bénéficié d'un délai de dépréciation clair. Les appareils Synology, QNAP et UGREEN sont livrés avec la signature disponible mais non obligatoire afin que les anciens clients Windows et les appareils embarqués puissent encore se connecter. macOS 26.4 demande effectivement à ces vendeurs de changer leurs propres paramètres par défaut, ce qui n'est pas une correction possible en une seule mise à jour de firmware sur la plupart des plateformes car cela casserait d'autres clients sur le même réseau.

Pour un aperçu plus large de la pile SMB sur macOS Tahoe et des nombreuses autres façons dont les connexions SMB peuvent échouer, le guide complet de dépannage SMB et NAS couvre les problèmes de connexion en dehors de Time Machine.

La correction nsmb.conf, étape par étape

La solution de contournement la plus propre consiste à indiquer à macOS que vous acceptez les sessions SMB sans signature pour les connexions auxquelles vous faites confiance. macOS lit un fichier de configuration à l'emplacement /etc/nsmb.conf à chaque configuration de session SMB, et vous pouvez y définir un indicateur global qui rétablit le comportement antérieur à la version 26.4.

Avant de commencer, deux mises en garde. Premièrement, ce changement s'applique à toutes les connexions SMB que votre Mac établit, pas seulement à Time Machine, alors assurez-vous que vous acceptez le compromis sécuritaire décrit plus loin dans cet article. Deuxièmement, les modifications de /etc/nsmb.conf nécessitent des privilèges administrateur et doivent être effectuées avec soin, car un fichier malformé fera échouer les connexions SMB de manières différentes et moins évidentes.

Correction rapide : une commande unique

Si vous voulez juste que les sauvegardes fonctionnent avant de vous coucher et que vous êtes à l'aise dans le Terminal, la commande suivante crée le fichier avec les paramètres nécessaires en une seule fois. Ouvrez le Terminal depuis Applications puis Utilitaires, et collez la commande exactement. Votre mot de passe administrateur vous sera demandé.

sudo tee /etc/nsmb.conf >/dev/null <<'EOF'
[default]
signing_required=no
protocol_vers_map=7
EOF

La ligne signing_required=no indique au client SMB macOS que la signature est facultative plutôt qu'obligatoire. La ligne protocol_vers_map=7 est un masque de bits qui autorise la négociation SMB 1, SMB 2 et SMB 3, ce qui correspond au paramètre par défaut hérité. Sur la plupart des NAS modernes, seuls SMB 2 et SMB 3 seront réellement utilisés, mais l'inclusion de SMB 1 dans le masque évite un cas marginal où la négociation échoue complètement sans aucun protocole.

Après avoir exécuté la commande, éjectez les partages SMB actuellement montés depuis le Finder, attendez dix secondes, puis reconnectez-vous au partage par son nom. La prochaine tentative de sauvegarde Time Machine devrait se dérouler normalement.

Correction permanente : modifier /etc/nsmb.conf manuellement

Si vous préférez voir le fichier avant de vous engager, ou si vous souhaitez ajouter des remplacements par serveur ultérieurement, créez ou modifiez le fichier dans un éditeur de texte avec sudo. Utilisez l'éditeur de votre choix ; nano est inclus avec macOS et est l'option la plus conviviale pour les utilisateurs occasionnels du Terminal.

sudo nano /etc/nsmb.conf

Collez le contenu suivant, enregistrez avec Contrôle-O suivi de Entrée, et quittez avec Contrôle-X.

[default]
signing_required=no
protocol_vers_map=7

# Optional: target a specific NAS by hostname.
# Replace synology.local with your NAS hostname.
[synology.local]
signing_required=no

La section [default] s'applique à toutes les connexions SMB. La deuxième section optionnelle remplace les paramètres par défaut pour un seul nom d'hôte, ce qui est utile si vous souhaitez assouplir la signature uniquement pour le NAS et la maintenir stricte pour les connexions à un serveur de fichiers d'entreprise.

Pour les utilisateurs qui ont besoin d'un contrôle plus fin, une approche alternative utilise une liste de propriétés à l'emplacement /Library/Preferences/com.apple.NetworkAuthorization.plist ou le mécanisme moins connu serverMarkers.plist pour marquer des serveurs spécifiques comme « hérités » et contourner la nouvelle logique de signature. L'approche plist est plus invasive et moins bien documentée que nsmb.conf, nous la recommandons donc uniquement si nsmb.conf ne résout pas le problème avec votre combinaison spécifique de firmware NAS.

Vérification que la correction a fonctionné

Après avoir enregistré le fichier, la prochaine session SMB que votre Mac négocie respectera les nouveaux paramètres par défaut. Pour vérifier que le fichier est correctement lu, exécutez la commande suivante depuis le Terminal.

cat /etc/nsmb.conf

Vous devriez voir exactement le contenu que vous avez écrit. Si le fichier est vide ou affiche un bloc [default] différent, vous avez peut-être une ancienne copie d'une tentative de correction précédente.

Pour observer la négociation SMB en temps réel, ouvrez Console.app, tapez smb dans le champ de recherche, puis déclenchez une sauvegarde Time Machine ou montez le partage manuellement. Vous devriez voir une configuration de session réussie suivie d'une connexion d'arborescence au nom du partage. Les échecs précédents auront enregistré des erreurs de signature dans le même flux, et l'absence de ces erreurs après l'application de la correction est un indicateur clair que la solution de contournement a pris effet.

Si vous souhaitez confirmer la version du protocole SMB négociée, ouvrez le Moniteur d'activité, passez à l'onglet Réseau, et vous verrez la connexion smbd. Vous pouvez également exécuter smbutil statshares -a depuis le Terminal, ce qui liste tous les partages SMB actifs et le dialecte SMB négocié. Une ligne indiquant SMB_VERSION SMB_3_0_2 ou supérieur avec SIGNING_SUPPORTED TRUE signifie que la signature est toujours utilisée de façon opportuniste même si elle n'est plus obligatoire, ce qui est le meilleur des deux mondes.

Une fois que Time Machine a terminé avec succès sa première sauvegarde, vous pouvez laisser la configuration en place jusqu'à la sortie de macOS 26.5. Pour annuler, supprimez /etc/nsmb.conf ou changez signing_required=no en signing_required=yes et reconnectez le partage.

Statut par vendeur NAS

La gravité de la régression et la disponibilité d'un correctif côté vendeur varient selon la plateforme NAS. Voici l'état des choses début mai 2026.

Synology DSM. Synology a livré DSM 7.2.2 mise à jour 4 mi-avril 2026 avec une option de configuration pour exiger la signature SMB côté serveur. L'activation de l'option dans le Panneau de configuration sous Services de fichiers puis SMB puis Paramètres avancés restaure la fonctionnalité Time Machine sans la solution de contournement nsmb.conf sur le Mac. Les anciens systèmes DSM 7.1 et DSM 6.2 n'ont pas cette option et nécessitent la solution côté client. Synology a confirmé dans des publications communautaires que DSM 7.2.3 rendra la signature obligatoire par défaut pour les nouvelles installations.

QNAP QTS. QTS 5.1.7 a ajouté un paramètre similaire sous Panneau de configuration, Services réseau et de fichiers, Win/Mac/NFS/WebDAV, puis Options avancées SMB. L'option est étiquetée « Appliquer la signature SMB ». L'activation fonctionne pour la plupart des utilisateurs, bien qu'un sous-ensemble ait signalé que la pile SMB QTS ne négocie correctement qu'après la recréation du partage lui-même. La bêta QTS 5.2.0 est en cours de test et devrait rendre la signature obligatoire par défaut.

UGREEN UGOS. UGREEN a été plus lent à réagir. Fin avril 2026, UGOS 1.4 a ajouté un firmware bêta qui active SMB 3.1.1 avec signature obligatoire, mais le firmware n'est pas encore en GA et est optionnel via le canal bêta. Les propriétaires UGREEN sur le firmware UGOS stable devraient prévoir d'utiliser la solution de contournement nsmb.conf pendant les prochaines semaines.

TrueNAS. TrueNAS SCALE 24.10 est livré avec Samba 4.20, qui prend en charge la signature obligatoire par défaut. Le paramètre peut être activé en modifiant les paramètres auxiliaires du service SMB et en ajoutant server signing = mandatory. Redémarrez le service SMB après avoir appliqué la modification. Les utilisateurs TrueNAS CORE avec des versions Samba plus anciennes peuvent avoir besoin d'une mise à jour avant que le correctif côté serveur soit disponible.

Asustor ADM. ADM 4.3.1 a ajouté une option « Appliquer la signature SMB » dans Services puis Win/Mac/NFS, mais l'activation sur les anciens appareils Asustor avec des processeurs bas de gamme aurait réduit le débit SMB de 20 à 30 % en raison de la surcharge de signature par paquet. Ce compromis peut pousser les utilisateurs Asustor vers la solution côté client sur le Mac.

Autres vendeurs. Drobo, WD My Cloud Pro et plusieurs vendeurs plus petits n'ont pas encore publié de mises à jour de firmware. La solution de contournement nsmb.conf s'applique dans tous les cas. Si votre NAS exécute un Samba moderne (4.18 ou plus récent), l'activation de server signing = mandatory dans le smb.conf de l'appareil devrait également fonctionner, mais ne tentez cela que si vous êtes à l'aise pour maintenir votre propre configuration Samba.

Pour les utilisateurs envisageant une stratégie de sauvegarde à long terme qui ne dépend pas d'un seul point vulnérable, le guide de la meilleure stratégie de sauvegarde Mac pour 2026 explique comment combiner Time Machine avec iCloud et un clone local pour plus de résilience.

Compromis sécuritaires liés à l'assouplissement de la signature SMB

La désactivation de signing_required dans nsmb.conf est un véritable changement de votre posture sécuritaire, pas un simple commutateur cosmétique. Il vaut la peine d'être honnête sur ce que vous échangez.

Lorsque la signature SMB est obligatoire, un attaquant qui s'est positionné sur votre réseau local en tant qu'homme du milieu ne peut pas falsifier le trafic SMB en transit. Sans signature, un attaquant suffisamment motivé sur le même réseau de couche 2 pourrait intercepter des paquets SMB et modifier le contenu des fichiers tels qu'ils sont écrits sur le NAS. L'attaquant devrait se trouver sur votre réseau local filaire, votre réseau Wi-Fi ou un VPN partageant le même domaine de diffusion. Il faudrait également qu'il dispose du savoir-faire technique pour exécuter un outil SMB MITM, ce qui n'est pas anodin mais pas non plus exotique.

Pour un environnement domestique typique avec un seul réseau Wi-Fi que vous contrôlez, un routeur auquel vous faites confiance et aucun appareil non fiable sur le réseau local, le risque pratique d'une attaque SMB MITM est très faible. L'attaquant le plus courant sur un réseau local domestique est un malware s'exécutant sur un autre appareil que vous possédez, et ce scénario est largement hors de portée de la signature SMB car le malware aurait ses propres informations d'identification et n'aurait pas besoin de faire une attaque de l'homme du milieu sur votre Mac.

Pour un environnement de bureau, un espace de coworking ou tout cadre où des appareils non fiables rejoignent régulièrement le réseau, le calcul est différent. Un collègue branchant un Raspberry Pi, un appareil invité avec malware ou une caméra IoT compromise pourraient tous concevoir une attaque contre le trafic SMB non signé. Dans ces environnements, la bonne réponse n'est pas d'assouplir la signature sur le Mac mais de mettre à jour le firmware du NAS pour que la signature reste obligatoire de bout en bout.

Une voie intermédiaire raisonnable est d'utiliser la section par serveur dans nsmb.conf pour assouplir la signature uniquement pour le nom d'hôte NAS que Time Machine cible, et de laisser le paramètre global à signing_required=yes. Ainsi, vos autres connexions SMB restent protégées, et l'assouplissement ne s'applique qu'à l'hôte auquel vous acceptez de faire confiance sur votre réseau local.

Il convient également de noter que tout le trafic SMB sur macOS est non chiffré par défaut, sauf si le serveur active explicitement le chiffrement SMB (une fonctionnalité distincte de la signature). Si vous vous préoccupez de la confidentialité du contenu de sauvegarde sur le fil, l'activation du chiffrement SMB côté NAS est plus impactante que la signature, et n'interagit pas avec la régression 26.4.

Alternatives pendant l'attente

Si la modification de fichiers de configuration système n'est pas votre idée d'un week-end détendu, ou si vous n'êtes pas à l'aise avec le compromis sécuritaire, il existe plusieurs stratégies de sauvegarde alternatives que vous pouvez exécuter en parallèle ou à la place de Time Machine basé sur NAS. Combiner deux d'entre elles vous donne une redondance jusqu'à la résolution du problème.

SSD externe via Time Machine. Un SSD USB-C coûte à peu près autant qu'un seul compartiment de disque NAS et vous donne des sauvegardes Time Machine natives et signées sans couche SMB. Un Samsung T7 ou Crucial X9 Pro de 2 To contiendra des mois de sauvegardes incrémentielles pour la plupart des utilisateurs. Branchez-le chaque soir, laissez Time Machine se terminer, puis débranchez-le et rangez-le hors site pour une résilience contre les ransomwares. L'inconvénient est la manipulation manuelle, que la plupart des gens arrêtent de faire en deux semaines.

Carbon Copy Cloner. Carbon Copy Cloner (CCC) de Bombich Software crée des clones démarrables ou non démarrables de votre Mac vers n'importe quelle destination, y compris les partages SMB. CCC gère la configuration de session SMB indépendamment de Time Machine et inclut sa propre logique de relance qui s'est avérée plus résiliente à la régression 26.4 que Time Machine lui-même. La licence est unique et l'essai est généreux. CCC est le choix le plus populaire pour les utilisateurs qui souhaitent un véritable outil de sauvegarde en attendant qu'Apple corrige Time Machine.

SuperDuper. SuperDuper de Shirt Pocket Software est l'autre outil de clonage de longue date pour macOS. Il est plus simple que CCC avec un ensemble de fonctionnalités plus restreint, mais il est aussi moins cher et plus que suffisant pour les utilisateurs dont l'unique objectif est de « conserver une copie récente de leur disque quelque part ». SuperDuper écrit plus fiablement vers des destinations locales que vers des partages SMB, il se combine donc bien avec l'approche SSD externe.

Arq Backup vers le stockage cloud. Arq est un outil de sauvegarde versionné qui cible des destinations cloud dont Backblaze B2, Wasabi, AWS S3 et votre propre serveur SFTP. Il est conçu pour les sauvegardes hors site, chiffre les données côté client avant l'upload et n'a aucune dépendance vis-à-vis de la pile SMB macOS. Arq est un complément solide à une sauvegarde locale plutôt qu'un remplacement complet, car les restaurations cloud de grands ensembles de données sont lentes.

Un deuxième Mac comme destination Time Machine. Si vous avez un vieux Mac qui traîne, vous pouvez activer le partage de fichiers dessus et pointer Time Machine de votre Mac principal vers un dossier du Mac secondaire. Les connexions SMB de macOS à macOS fonctionnent toujours bien dans la version 26.4 car les deux extrémités parlent le même dialecte. C'est une option de niche mais gratuite si le matériel est disponible.

La combinaison sur laquelle la plupart des utilisateurs se stabilisent en attendant le correctif est un travail Carbon Copy Cloner vers le NAS plus un échange hebdomadaire de SSD externe. CCC gère le travail incrémental quotidien et est fiable sur 26.4, et le SSD externe fournit le repli isolé qui protège contre tout, depuis une panne de disque NAS jusqu'au ransomware chiffrant le partage réseau.

Quand macOS 26.5 va-t-il vraiment corriger cela ?

Apple a diffusé macOS 26.5 bêta 4 aux développeurs le 27 avril 2026 avec le numéro de build 25F5068a. Les notes de version bêta sont toujours sous NDA, mais les rapports des bêta-testeurs confirment que le paramètre par défaut de signature SMB a été ajusté afin que les connexions Time Machine vers les configurations NAS courantes réussissent sans intervention manuelle.

Le mécanisme exact du correctif n'a pas été documenté publiquement. La meilleure hypothèse d'après les modifications observées dans les journaux de négociation SMB est qu'Apple a réintroduit un chemin de repli pour les sessions SMB où le serveur annonce la signature comme prise en charge mais non obligatoire, avec le repli limité à l'accès au sparsebundle Time Machine. Cela préserverait les améliorations de sécurité pour une utilisation SMB générale tout en restaurant la fonctionnalité de sauvegarde pour la population NAS concernée.

Le calendrier de publication publique de la version 26.5 n'est pas confirmé mais suit un schéma prévisible. Apple cible généralement la fin mai pour la version intermédiaire finale avant la WWDC d'une version majeure de macOS, et la WWDC 2026 est prévue pour commencer le lundi 8 juin. La bêta 4 fin avril, suivie de la bêta 5 début mai et d'une version Release Candidate mi-mai, placerait la version publique dans la fenêtre du 19 au 26 mai, à quelques jours près.

Pour un aperçu plus approfondi de ce qui se trouve dans le cycle 26.5, y compris les nouvelles fonctionnalités Apple Intelligence, les Rappels repensés et une réécriture très attendue de Mail, consultez notre guide complet de macOS Tahoe 26.5 bêta 1.

Lorsque la version 26.5 sera disponible et que vous confirmerez que Time Machine fonctionne sans la solution de contournement, pensez à supprimer ou rétablir /etc/nsmb.conf afin que les paramètres par défaut de signature SMB soient restaurés pour toutes vos connexions réseau.

Liste de contrôle de dépannage

Si la solution de contournement nsmb.conf ne corrige pas Time Machine au premier essai, parcourez cette liste de contrôle avant de supposer que le problème est plus exotique.

Éjectez et remontez le partage. macOS met en cache la session SMB négociée pour un partage jusqu'à ce qu'il soit complètement éjecté. Utilisez le Finder pour éjecter le partage NAS, attendez dix secondes, puis reconnectez-vous depuis le Finder en tapant manuellement le chemin du partage. Déclenchez ensuite seulement la sauvegarde Time Machine.

Redémarrez le Mac. Certains utilisateurs ont signalé que le client SMB ne prend pas en compte le nouveau nsmb.conf jusqu'au prochain démarrage. Un redémarrage est plus rapide que de continuer à chercher le problème.

Mettez à jour le firmware NAS. Même si votre NAS n'a pas encore de correctif spécifique à Tahoe, une mise à jour récente du firmware peut avoir amélioré la négociation SMB d'une façon qui interagit avec le changement macOS. Synology DSM 7.2.2u4, QNAP QTS 5.1.7 et TrueNAS SCALE 24.10 sont les versions minimales recommandées.

Vérifiez les autorisations du partage. Vérifiez que le compte utilisateur que Time Machine utilise sur le NAS a la permission de lecture et d'écriture sur le partage Time Machine. Certaines mises à jour du firmware NAS réinitialisent les autorisations pendant le processus de mise à jour.

Vérifiez l'intégrité du sparsebundle. Si une tentative de sauvegarde précédente a laissé un sparsebundle partiel, montez-le manuellement et exécutez hdiutil verify dessus. Les sparsebundles corrompus feront échouer Time Machine même après la correction de la couche SMB. Dans les cas graves, la suppression du sparsebundle et le démarrage de zéro est le chemin le plus propre.

Confirmez que la destination Time Machine est reconnue. Ouvrez Réglages Système puis Général puis Time Machine, et vérifiez que la destination apparaît toujours dans la liste. Si elle a disparu, rajoutez-la après que la couche SMB fonctionne.

Vérifiez la connectivité réseau. Confirmez que le Mac peut atteindre le NAS en le pingant depuis le Terminal. SMB nécessite à la fois la connexion au niveau IP et les ports SMB (445 généralement) pour être accessibles.

Consultez le journal du noyau. Exécutez log show --last 5m --predicate 'process == "kernel"' | grep smb après un échec de sauvegarde. Les erreurs SMB au niveau du noyau révèleront si l'échec se situe au niveau de la négociation de signature, de l'authentification, de la connexion à l'arborescence ou de la couche des opérations sur les fichiers.

Si après tout cela la sauvegarde échoue encore, votre combinaison particulière de firmware NAS peut être un cas particulier qui nécessite l'approche serverMarkers.plist ou une modification de smb.conf côté NAS. La publication de votre modèle NAS, de la version du firmware et des lignes exactes du journal du noyau sur le forum approprié du vendeur est généralement le moyen le plus rapide d'obtenir un correctif fonctionnel.

FAQ

Q : La solution de contournement nsmb.conf affecte-t-elle les connexions SMB à mon PC Windows ? R : Oui. Tout changement dans la section [default] s'applique à toutes les connexions SMB que votre Mac établit. Si vous souhaitez laisser les connexions Windows strictes, limitez le changement à une section par serveur en utilisant votre nom d'hôte NAS comme nom de section.

Q : Devrai-je refaire ma sauvegarde Time Machine complète après avoir appliqué le correctif ? R : Non. Une fois la session SMB correctement établie, Time Machine reprendra là où il s'était arrêté et écrira la prochaine sauvegarde incrémentielle. Vous n'avez besoin d'une resauvegarde complète que si le sparsebundle lui-même a été corrompu par un échec antérieur.

Q : J'ai essayé la correction et Time Machine échoue encore. Que faire maintenant ? R : Parcourez la liste de contrôle de dépannage ci-dessus, en prêtant une attention particulière aux lignes du journal du noyau. La cause de suivi la plus courante est un sparsebundle corrompu par une tentative précédente qui a échoué plutôt qu'un problème SMB persistant.

Q : Est-il prudent d'appliquer le correctif sur un Mac que j'amène dans un espace de coworking ? R : C'est plus sûr que d'exécuter SMB non signé vers votre NAS domestique depuis le réseau de coworking, mais la réponse la plus propre est soit de mettre à jour le firmware de votre NAS pour que la signature côté serveur soit obligatoire, soit de limiter l'exception nsmb.conf uniquement au nom d'hôte de votre NAS domestique.

Q : Dois-je répéter le correctif après chaque mise à jour macOS ? R : Le fichier /etc/nsmb.conf persiste à travers les mises à jour. Vous ne devriez pas avoir besoin de le réappliquer sauf si une mise à jour réinitialise spécifiquement les fichiers de configuration système, ce qui est rare.

Q : Le correctif va-t-il casser les sauvegardes iCloud, AirDrop ou d'autres services Apple ? R : Non. Ces services n'utilisent pas SMB et ne sont pas affectés par les modifications de nsmb.conf.

Q : Puis-je utiliser la même correction sur macOS Sequoia ou Sonoma ? R : Le format de fichier est le même et les mêmes lignes fonctionnent, mais vous ne devriez pas en avoir besoin sur Sequoia ou Sonoma car le changement de signature SMB est spécifique à Tahoe 26.4. Appliquer le correctif sur les versions macOS plus anciennes est inoffensif mais inutile.

Q : Mon vendeur NAS dit qu'il dispose d'une mise à jour de firmware qui corrige cela. Dois-je quand même garder nsmb.conf en place ? R : Après l'application de la mise à jour du firmware et la confirmation que Time Machine fonctionne sans la solution de contournement, supprimez nsmb.conf. Maintenir l'assouplissement est inutile et réduit votre niveau de sécurité de base.

Q : Existe-t-il un outil GUI pour modifier nsmb.conf ? R : Pas officiellement de la part d'Apple. Quelques outils tiers existent sur GitHub, mais pour un fichier de deux lignes, l'approche Terminal est plus rapide et moins risquée que l'installation d'un nouvel utilitaire.

Q : Lorsque la version 26.5 sera disponible, Apple va-t-il rétroporter le correctif vers la version 26.4 ? R : Apple ne s'est pas engagé sur un correctif 26.4.2 qui traite la régression SMB. Historiquement, Apple préfère intégrer les corrections dans la prochaine version intermédiaire majeure plutôt que de rétroporter, surtout pour les régressions non liées à la sécurité. Comptez sur la version 26.5 comme résolution.

Conclusion

Le changement de signature SMB de macOS Tahoe 26.4 était la bonne décision du point de vue de la sécurité, mais le manque de coordination avec les vendeurs a mis les sauvegardes Time Machine basées sur NAS dans une situation difficile pendant plusieurs semaines. La solution de contournement /etc/nsmb.conf est courte, réversible et répond au besoin immédiat. La réponse plus durable est de maintenir le firmware de votre NAS à jour afin que la signature soit obligatoire côté serveur, rétablissant ainsi une signature stricte sur toute la connexion.

Si vous lisez ceci fin mai 2026 ou plus tard, vérifiez si macOS 26.5 a été publié avant d'appliquer la solution de contournement. Si la version 26.5 est disponible, installez-la et vos sauvegardes Time Machine devraient reprendre sans aucune modification de fichiers système. Si vous avez appliqué la solution de contournement et que la version 26.5 est maintenant installée, prenez cinq minutes pour annuler nsmb.conf et confirmez que les sauvegardes fonctionnent toujours avec la signature stricte restaurée.

Les sauvegardes sont le genre d'infrastructure auquel on ne pense qu'en cas de problème, et la régression 26.4 est un rappel utile que dépendre d'une seule destination de sauvegarde est risqué. Quelle que soit la voie de correction que vous prenez cette semaine, envisagez d'ajouter une deuxième cible de sauvegarde indépendante avant l'arrivée de la prochaine mise à jour macOS.

Lectures associées

• Le guide complet de dépannage Time Machine pour macOS Tahoe
• Dépannage SMB et NAS sur macOS Tahoe
• La meilleure stratégie de sauvegarde Mac pour 2026 : Time Machine, iCloud et outils de clonage
• Guide complet de mise à jour macOS Tahoe 26.4 et 26.4.1
• macOS Tahoe 26.5 bêta 1 : nouveautés et correctifs
• Guide complet de createinstallmedia : retour à une installation macOS propre