macOS Tahoe 26.4でTime MachineのSMBバックアップが壊れた：26.5までのnsmb.conf修正方法
macOS 26.4の厳格化されたSMB署名がSynology、QNAP、UGREEN NASのTime Machineを壊しました。nsmb.confの回避策、ベンダー情報、26.5の修正スケジュールを詳しく解説します。
2026年3月下旬にmacOS Tahoe 26.4をインストールしてから、Synology、QNAP、UGREEN、TrueNAS、AsustorのNASへのTime Machineバックアップが突然停止したという方は、あなただけではありません。Appleの26.4リリースは、オペレーティングシステムのSMB署名のデフォルト設定を静かに厳格化し、その変更により市場に出回っているほぼすべてのサードパーティ製ネットワークアタッチドストレージデバイスへのTime Machine接続が壊れました。4月9日にリリースされた26.4.1パッチはいくつかのバグを修正しましたが、Time MachineのSMBの問題は対処されませんでした。
良いニュースは、今夜でも適用できる既知の回避策があること、そしてAppleがすでにmacOS 26.5ベータ4（ビルド25F5068a、2026年4月27日シード）でその動作を修正したことです。悪いニュースは、公開版26.5のリリースが2026年6月8日のWWDC 2026直前の5月下旬になる見込みで、手動で対処しない限りほとんどのNASオーナーは数週間バックアップが壊れた状態に置かれることです。
このガイドでは、内部で何が変わったかを正確に説明し、貼り付けるべき正確なテキストと共に/etc/nsmb.confの回避策を詳しく説明し、主要なNASベンダーごとの状況をまとめ、ホームまたはオフィスのLANでSMB署名を緩和するセキュリティ上のトレードオフを評価し、待っている間に実行できるより安全な暫定バックアップ戦略を概説します。最終的に、バックアップが再び機能するようになり、何を犠牲にしたかが明確に理解できると共に、macOS 26.5がリリースされた瞬間に変更を元に戻す方法もわかるようになります。
重要なポイント
- 壊れたもの： macOS Tahoe 26.4はTime Machine接続でSMB署名をデフォルトで必須にしました。ほとんどのサードパーティNASはmacOS 26.4が受け入れる方法でSMB署名をアドバタイズしておらず、SMBセッションはTime MachineがスパースバンドルをマウントするよりもWhile前に拒否されます。
- 影響を受けるベンダー： Synology DSM 7.2以前、QNAP QTS 5.1.x、UGREEN UGOS 1.x、Asustor ADM 4.x、TrueNAS SCALE 24.x（デフォルト設定）、およびその他多くのサードパーティSMBターゲット。macOS同士のTime Machine over SMBは引き続き機能します。
- 症状： 「Time Machineがバックアップを完了できませんでした」、「操作が許可されていません」、ループする資格情報プロンプト、マウントはされるが読み取り不能と報告されるスパースバンドル、数秒以内に中止される完全な再バックアップの試み。
- 修正方法： NASファームウェアが更新されるかmacOS 26.5がリリースされるまで、
signing_required=noとprotocol_vers_map=7を指定した/etc/nsmb.confを作成します。 - リスク： SMB署名を無効にすると、ローカルネットワーク上でSMBセッションがMITM改ざんにさらされます。信頼できるホームLANでは許容可能ですが、共有オフィスのWi-Fiやコワーキングネットワークでは許容度が下がります。
- 修正のスケジュール： macOS 26.5ベータ4がリグレッションを解消したと報告されています。公開版26.5はWWDCに先立って2026年5月下旬に予定されています。
何がいつ壊れたか
Appleは2026年3月下旬にmacOS Tahoe 26.4をTahoeサイクルの2番目の機能アップデートとしてリリースしました。リリースノートでは、Apple Intelligenceの改善、カレンダーアプリのリフレッシュ、長いセキュリティ修正のリストが強調されていました。そのセキュリティリストの中に、macOSに組み込まれたSMBクライアントへの変更が隠れており、カーネルがSMBセッションをネゴシエートする方法を強化していました。Appleはヘッドラインのリリースノートではこれを強調しませんでしたが、Time Machineの宛先がサードパーティNASだった人には即座に影響が出ました。
26.4ロールアウトから48時間以内に、Appleコミュニティスレッド256221835が同一の症状を説明するSynologyとQNAPオーナーからの報告を収集し始めました。Hacker Newsのアイテム46848699では、あらゆる種類のコンシューマーおよびプロシューマーNASを使用しているユーザーから数百件の回答が集まりました。パターンは明白でした：何年もの間毎晩動いていたバックアップが、26.4アップデート後の最初の試みで突然初期化を拒否したのです。
Appleは2026年4月9日に26.4.1をリリースし、Wi-Fiローミングの問題やメールのレンダリングバグを含むいくつかの無関係なリグレッションに対処しました。Time MachineのSMBの問題は26.4.1のパッチノートには含まれておらず、リグレッションがポイントリリースで存続していることがテストで確認されました。26.4.1が静かに以前の動作を復元してくれると期待していたユーザーは失望し、Appleコミュニティスレッドのトーンは「これは自分だけなのか」から「Appleはこれを認める必要がある」に変わりました。
26.4リリースサイクルと知っておくべきその他のリグレッションの詳細については、macOS Tahoe 26.4と26.4.1の完全なアップデートガイドをご覧ください。
症状一覧
Time MachineのSMBリグレッションは、NASベンダー、ファームウェアバージョン、およびアップグレード前のTime Machineの設定方法によって、いくつかの異なる方法で現れます。最も一般的な症状は、ユーザーレポートに現れる順序でおおよそ以下のように列挙されます。
26.4後の最初のスケジュールされたバックアップでTime Machineが初期化に失敗します。 Time Machineのメニューバーアイコンが数秒間回転し、その後「Time Machineが[共有名]へのバックアップを完了できませんでした」と表示されます。システム設定でTime Machineを開くと、宛先はまだ設定されたままですが、次のバックアップの試みも同じように失敗します。
ループする資格情報プロンプト。 macOSがSMB共有のユーザー名とパスワードを要求し、資格情報を受け入れ、その後すぐに再び要求します。Keychainに資格情報を保存しても役に立ちません。SMBセッション自体が認証よりも低いレイヤーで拒否されているためです。
「操作が許可されていません」またはPOSIXエラー1。 これは基礎となるログで最も一般的なエラー文字列です。NAS上のスパースバンドルは技術的に到達可能ですが、macOS 26.4が現在要求する署名プロパティなしにSMBセッションがネゴシエートまたはダウングレードされたため、macOSがそれをマウントすることを拒否するために発生します。
マウントされるが読み取り不能と報告されるスパースバンドル。 ユーザーの一部には、バックアップボリュームがFinderでマウントされるものの、Time Machineがボリュームを使用不能と報告します。これは通常、共有がフォールバックとして未署名のSMB1またはSMB2セッションをネゴシエートし、macOSがそこへの書き込みを拒否する場合に発生します。
数秒以内に中止される完全な再バックアップの試み。 一部のユーザーは、宛先を削除して再追加することで問題を「修正」しようとし、新鮮なバックアップが機能することを期待しました。しかし、再バックアップは同じ壊れたSMBセッションをネゴシエートして、ほぼすぐに中止され、場合によってはNASに空のプレースホルダースパースバンドルを残します。
smbfs、signature mismatch、またはSTATUS_ACCESS_DENIEDを参照するコンソールログエントリ。 Console.appを開いてsmbでフィルタリングしながら障害が発生すると、署名ネゴシエーションに関するカーネルメッセージが表示されます。これが署名変更の確かな証拠です。
これらのいくつかが同時に発生している場合、NASハードウェア障害、ネットワーク問題、またはスパースバンドルの破損ではなく、26.4のSMB署名リグレッションにほぼ確実にぶつかっています。SMBレイヤーに関係なく適用されるより広範なTime Machine診断については、完全なTime Machineトラブルシューティングガイドが残りの領域をカバーしています。
なぜ壊れたか：AppleのSMB署名変更の解説
回避策がなぜ機能するかを理解するには、SMB署名とは実際何であるか、そしてAppleが26.4でデフォルトを変更することを決めた理由を知ることが役立ちます。
SMB署名は、Windowsの共有、Sambaサーバー、またはNASに接続する際にmacOSが使用するファイル共有プロトコルであるServer Message Blockプロトコルの機能です。SMB署名が有効な場合、クライアントがサーバーに送信するすべてのパケットには、セッションキーから派生した暗号署名が含まれます。サーバーは各パケットの署名を検証し、同じ方法でレスポンスに署名します。結果として、同じネットワーク上の攻撃者は、署名が失敗して接続が切断されることなしに、転送中のファイルコンテンツを改ざんすることができません。
SMB署名はSMB1以来存在しており、多くのWindowsワークロードでは既定でSMB3で必須です。クライアントとサーバー間のプロトコルネゴシエーションにより、署名が「使用されない」、「有効だがオプション」、または「必須」のいずれかが決まります。macOS 26.4まで、macOS SMBクライアントはサーバーが署名を要求しない場合に未署名セッションをネゴシエートするのに満足しており、これはほとんどのコンシューマーNASデバイスがパフォーマンス上の理由から取っていた経路でした。
26.4では、AppleはmacOSのデフォルトを変更し、明示的に指示されない限りクライアントがセッションで署名を要求するようになりました。クライアントが署名を利用可能だが必須ではないとアドバタイズするNASに接続すると、macOSは未署名モードへのフォールバックを拒否するようになりました。セッションネゴシエーションはエラーで完了し、SMBマウントは失敗し、Time Machineには書き込む宛先がなくなります。
なぜAppleはこれを行ったのでしょうか？この変更は、SMBを強化するための多年にわたる業界の取り組みと一致しています。MicrosoftはWindows 11 24H2で既定で署名を必須にし、SMBコミュニティは必須署名付きSMB 3.1.1への移行を進めており、Appleの企業顧客も同じことを要求してきました。ランサムウェアの脅威モデルには、侵害されたエンドポイントからファイル共有に移動して転送中のバックアップファイルを改ざんする攻撃者が含まれており、SMB署名は最もクリーンな緩和策の一つです。
問題は、NASベンダーに明確な廃止予告が与えられていなかったことです。Synology、QNAP、UGREENのデバイスは、古いWindowsクライアントや組み込みデバイスがまだ接続できるように、署名を利用可能だが必須ではないとして出荷しています。macOS 26.4は実質的にこれらのベンダーに自分自身のデフォルトを変更することを要求しますが、これは同じネットワーク上の他のクライアントを壊す可能性があるため、ほとんどのプラットフォームでの1回のファームウェアアップデートでの修正ではありません。
macOS TahoeのSMBスタックと、SMB接続が失敗するその他の多くの方法の詳細については、完全なSMBとNASトラブルシューティングガイドがTime Machine以外の接続問題をカバーしています。
nsmb.confの修正、ステップバイステップ
最もクリーンな回避策は、信頼している接続に対して署名なしのSMBセッションを受け入れる意思があることをmacOSに伝えることです。macOSはすべてのSMBセッション設定時に/etc/nsmb.confの設定ファイルを読み取り、そこに26.4以前の動作を復元するグローバルフラグを設定できます。
始める前に、2つの警告があります。まず、この変更はTime Machineだけでなく、MacがするすべてのSMB接続に適用されますので、この記事の後半で説明するセキュリティ上のトレードオフに問題ないことを確認してください。次に、/etc/nsmb.confへの編集には管理者権限が必要であり、形式が誤ったファイルはSMB接続を異なるより分かりにくい方法で失敗させるため、慎重に行う必要があります。
クイック修正：ワンライナー
バックアップを寝る前に動かしたいだけで、Terminalに問題ない場合、次のコマンドで必要な設定を含むファイルを一発で作成できます。アプリケーション→ユーティリティからTerminalを開き、コマンドを正確に貼り付けます。管理者パスワードを求められます。
sudo tee /etc/nsmb.conf >/dev/null <<'EOF'
[default]
signing_required=no
protocol_vers_map=7
EOFsigning_required=noの行は、SMB署名が必須ではなくオプションであることをmacOS SMBクライアントに伝えます。protocol_vers_map=7の行は、SMB 1、SMB 2、SMB 3のネゴシエーションを許可するビットマスクで、これはレガシーデフォルトです。ほとんどの最新のNASデバイスでは実際にはSMB 2とSMB 3のみが使用されますが、マップにSMB 1を含めることで、ネゴシエーションがプロトコルなしに完全に失敗するエッジケースを防ぎます。
コマンドを実行した後、現在マウントされているSMB共有をFinderからイジェクトし、10秒待ってから共有に名前で再接続します。次のTime Machineバックアップの試みは進むはずです。
恒久的な修正：/etc/nsmb.confを手動で編集する
コミットする前にファイルを見たい場合、または後でサーバーごとの上書きを追加したい場合は、sudoを使ってテキストエディタでファイルを作成または編集します。好みのエディタを使用してください。nanoはmacOSに含まれており、ときどきTerminalを使うユーザーには最も使いやすいオプションです。
sudo nano /etc/nsmb.conf次の内容を貼り付け、Control-OとReturnで保存し、Control-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[default]セクションはすべてのSMB接続に適用されます。オプションの2番目のセクションは単一のホスト名のデフォルトを上書きします。これは、NASのみで署名を緩和し、企業のファイルサーバーへの接続では厳格を維持したい場合に便利です。
より細かいコントロールが必要なユーザーには、/Library/Preferences/com.apple.NetworkAuthorization.plistのプロパティリストまたはあまり知られていないserverMarkers.plistメカニズムを使って特定のサーバーを「レガシー」とマークし、新しい署名ロジックをバイパスする代替アプローチがあります。plistアプローチはより侵襲的でnsmb.confよりドキュメントが少ないため、特定のNASファームウェアの組み合わせでnsmb.confが問題を解決しない場合にのみお勧めします。
修正が機能したことを確認する
ファイルを保存した後、Macがネゴシエートする次のSMBセッションは新しいデフォルトに従います。ファイルが正しく読み取られていることを確認するには、Terminalから次のワンライナーを実行します。
cat /etc/nsmb.conf書いた内容と正確に一致するものが表示されるはずです。ファイルが空か異なる[default]ブロックが表示される場合は、以前の回避策の試みによる古いコピーがある可能性があります。
SMBネゴシエーションがリアルタイムで起こるのを見るには、Console.appを開き、検索フィールドにsmbと入力し、Time Machineバックアップをトリガーするか共有を手動でマウントします。共有名へのツリー接続に続く成功したセッション設定が表示されるはずです。修正前の失敗は同じストリームに署名または署名エラーを記録しており、修正を適用した後にそれらのエラーがないことは回避策が有効になったことの明確な指標です。
ネゴシエートされたSMBプロトコルバージョンを確認したい場合は、アクティビティモニターを開き、ネットワークタブに切り替えると、smbd接続が表示されます。Terminalからsmbutil statshares -aを実行することもできます。これにより、すべてのアクティブなSMB共有とネゴシエートしたSMBダイアレクトが一覧表示されます。SMB_VERSION SMB_3_0_2以上でSIGNING_SUPPORTED TRUEという行が読める場合、署名は必須ではなくなっても日和見的に使用されており、これが両方の利点を持つ最良の状態です。
Time Machineが最初のバックアップを正常に完了したら、macOS 26.5がリリースされるまで設定をそのままにしておけます。ロールバックするには、/etc/nsmb.confを削除するか、signing_required=noをsigning_required=yesに変更して共有を再接続します。
NASベンダーごとの状況
リグレッションの深刻さとベンダー側の修正の可用性は、NASプラットフォームによって異なります。2026年5月初旬現在の状況を以下に示します。
Synology DSM。 Synologyは2026年4月中旬にDSM 7.2.2アップデート4をリリースし、サーバー側でSMB署名を要求するための設定トグルを追加しました。コントロールパネルの「ファイルサービス」→「SMB」→「詳細設定」でトグルを有効にすると、Mac側のnsmb.confの回避策なしにTime Machine機能が復元されます。古いDSM 7.1およびDSM 6.2システムにはトグルがなく、クライアント側の回避策が必要です。Synologyはコミュニティポストで、DSM 7.2.3が新規インストールで署名必須をデフォルトにすることを確認しています。
QNAP QTS。 QTS 5.1.7は「コントロールパネル」→「ネットワークとファイルサービス」→「Win/Mac/NFS/WebDAV」→「SMBの詳細オプション」に同様の設定を追加しました。トグルは「SMB署名を強制」とラベル付けされています。有効にすることでほとんどのユーザーで機能しますが、一部はQTS SMBスタックが共有自体を再作成した後のみ正しくネゴシエートすると報告しています。QTS 5.2.0ベータがテスト中で、署名必須をデフォルトにする予定です。
UGREEN UGOS。 UGREENは対応が遅れました。2026年4月下旬現在、UGOS 1.4は署名必須でSMB 3.1.1を有効にするベータファームウェアを追加しましたが、ファームウェアはまだGAではなく、ベータチャンネル経由でオプトインです。安定版UGOSファームウェアのUGREENオーナーは、今後数週間はnsmb.confの回避策を計画する必要があります。
TrueNAS。 TrueNAS SCALE 24.10はSamba 4.20と共に出荷され、これはデフォルトで署名必須をサポートしています。設定はSMBサービスの補助パラメータを編集してserver signing = mandatoryを追加することで有効にできます。変更を適用した後にSMBサービスを再起動します。古いSambaバージョンのTrueNAS COREユーザーは、サーバー側の修正が利用可能になる前にアップデートが必要かもしれません。
Asustor ADM。 ADM 4.3.1は「サービス」→「Win/Mac/NFS」に「SMB署名を強制」トグルを追加しましたが、低エンドCPUを搭載した古いAsustorユニットでこれを有効にすると、パケットごとの署名オーバーヘッドによりSMBスループットが20〜30%低下すると報告されています。このトレードオフにより、AsustorユーザーはMac側のクライアント側の回避策を選ぶかもしれません。
その他のベンダー。 Drobo、WD My Cloud Pro、およびいくつかの小規模ベンダーはまだファームウェアアップデートをリリースしていません。nsmb.confの回避策はすべての場合に適用されます。NASが最新のSamba（4.18以降）を実行している場合、デバイスのsmb.confでserver signing = mandatoryを有効にすることも機能するはずですが、自分でSamba設定を管理することに問題ない場合のみ試みてください。
単一の脆弱なポイントに依存しない長期的なバックアップ戦略を検討しているユーザーには、2026年のベストMacバックアップ戦略がTime MachineとiCloudおよびローカルクローンを組み合わせてレジリエンスを実現する方法を解説しています。
SMB署名を緩和するセキュリティ上のトレードオフ
nsmb.confでsigning_requiredを無効にすることは、コスメティックなトグルではなく、セキュリティポジチャーへの実際の変更です。何を取引しているかについて正直に評価する価値があります。
SMB署名が必須の場合、ローカルネットワーク上で中間者として配置された攻撃者は、転送中のSMBトラフィックを改ざんすることができません。署名なしでは、同じレイヤー2ネットワーク上で十分な動機を持つ攻撃者がSMBパケットを傍受し、NASに書き込まれるファイルコンテンツを変更する可能性があります。攻撃者は有線LAN、Wi-Fiネットワーク、または同じブロードキャストドメインを共有するVPN上にある必要があります。また、SMB MITMツールを実行するための技術的な洗練度も必要で、これは些細ではありませんが珍しくもありません。
自分が管理する単一のWi-Fiネットワーク、信頼するルーター、LAN上に信頼されていないデバイスがない典型的なホーム環境では、SMB MITM攻撃の実際的なリスクは非常に低いです。ホームLAN上で最も一般的な攻撃者は、所有している別のデバイスで実行されているマルウェアであり、そのシナリオはSMB署名の範囲外です。マルウェアは独自の資格情報を持ち、Macを中間者攻撃する必要がないからです。
オフィス環境、コワーキングスペース、または信頼されていないデバイスが定期的にネットワークに参加する設定では、計算が異なります。Raspberry Piを接続した同僚、マルウェアを持つゲストデバイス、または侵害されたIoTカメラはすべて、署名されていないSMBトラフィックに対して攻撃を行う可能性があります。そのような環境では、Mac側で署名を緩和するのではなく、NASファームウェアを更新して署名がエンドツーエンドで必須であり続けるようにするのが正しい答えです。
合理的な中間の道は、nsmb.confでサーバーごとのセクションを使用して、Time Machineターゲットのみ署名を緩和し、グローバルデフォルトはsigning_required=yesのままにすることです。そうすることで、他のSMB接続は保護されたままになり、緩和はLAN上で信頼しているホストにのみ適用されます。
また、サーバーがSMB暗号化（署名とは別の機能）を明示的に有効にしない限り、macOS上のすべてのSMBトラフィックはデフォルトで暗号化されていないことも注目に値します。ネットワーク上のバックアップコンテンツの機密性が心配な場合は、NAS側でSMB暗号化を有効にする方がより効果的であり、26.4リグレッションとは相互作用しません。
待っている間の代替手段
システム設定ファイルの編集がリラックスした週末のアイデアではない場合、またはセキュリティ上のトレードオフに不快感がある場合は、NASベースのTime Machineと並行または代わりに実行できるいくつかの代替バックアップ戦略があります。そのうちの2つを組み合わせると、問題が解決するまで冗長性が得られます。
外部SSDを使ったTime Machine。 USB-C直結SSDは単一のNASドライブベイとほぼ同じコストで、SMBレイヤーなしにネイティブで署名されたTime Machineバックアップを提供します。2TBのSamsung T7またはCrucial X9 Proは、ほとんどのユーザーの数ヶ月分の増分バックアップを保持できます。毎晩接続し、Time Machineを完了させ、ランサムウェアのレジリエンスのためにオフサイトに保管します。欠点は手動での取り扱いで、ほとんどの人が2週間以内にやめてしまいます。
Carbon Copy Cloner。 Bombich SoftwareのCarbon Copy Cloner（CCC）は、SMB共有を含む任意の宛先にMacのブータブルまたはノンブータブルクローンを作成します。CCCはTime Machineとは独立してSMBセッションのセットアップを処理し、26.4リグレッションに対してTime Machine自体よりも回復力がある独自のリトライロジックを含んでいます。ライセンスは一回払いで試用は寛大です。CCCは、Appleがtime Machineを修正するのを待っている間に本格的なバックアップツールが必要なユーザーに最も人気のある選択肢です。
SuperDuper。 Shirt Pocket SoftwareのSuperDuperはmacOS用のもう一つの長年のクローンツールです。CCCよりシンプルで機能が少ないですが、価格が安く、「どこかに最近のディスクのコピーを保持する」という目標のみのユーザーには十分以上です。SuperDuperはSMB共有よりローカルの宛先への書き込みの方が信頼性が高いため、外部SSDアプローチとうまく組み合わせられます。
Arqバックアップのクラウドストレージへ。 Arqは、Backblaze B2、Wasabi、AWS S3、および独自のSFTPサーバーを含むクラウドの宛先をターゲットとするバージョン管理バックアップツールです。オフサイトバックアップ用に設計されており、アップロード前にクライアント側でデータを暗号化し、macOS SMBスタックへの依存関係がありません。Arqはローカルバックアップの強力な補完であり、完全な代替ではありません。大規模なデータセットのクラウドリストアは遅いからです。
Time Machineの宛先として2台目のMac。 古いMacがある場合は、それでファイル共有を有効にして、プライマリMacのTime MachineをセカンダリMacのフォルダに向けることができます。macOS同士のSMB接続は26.4でも引き続き機能します。両端が同じダイアレクトを話すからです。これはニッチなオプションですが、ハードウェアが利用可能であれば無料です。
修正を待っている間に多くのユーザーが落ち着く組み合わせは、NASへのCarbon Copy Clonerジョブと週次の外部SSDスワップです。CCCは毎日の増分作業を処理し26.4で信頼性があり、外部SSDはNASドライブの障害からネットワーク共有を暗号化するランサムウェアまですべてから保護するエアギャップのフォールバックを提供します。
macOS 26.5はいつ実際にこれを修正するか？
Appleは2026年4月27日にビルド番号25F5068aのmacOS 26.5ベータ4を開発者にシードしました。ベータのリリースノートはまだNDA下にありますが、ベータテスターからの報告は、手動の介入なしに一般的なNAS設定へのTime Machine接続が成功するようにSMB署名のデフォルトが調整されたことを確認しています。
修正の正確なメカニズムは公式に文書化されていません。SMBネゴシエーションログで観察された変更からの最良の推測は、Appleがサーバーが署名をサポートとしてアドバタイズするが必須ではないSMBセッションのフォールバックパスを再導入し、フォールバックをTime Machineスパースバンドルアクセスに限定したということです。これにより、影響を受けるNAS集団のバックアップ機能を復元しながら、一般的なSMB使用のセキュリティ向上が保持されます。
26.5の公開リリーススケジュールは未確認ですが、予測可能なパターンに従います。Appleは通常、macOSのメジャーバージョンの最終WWDC前のポイントリリースを5月下旬に目標としており、WWDC 2026は6月8日月曜日から始まる予定です。4月下旬のベータ4、5月上旬のベータ5、5月中旬のリリース候補という流れは、公開リリースを5月19日から5月26日の窓に数日の誤差内で置きます。
26.5サイクルに含まれる他のもの（新しいApple Intelligence機能、再設計されたリマインダー、待望のMailの書き直しなど）の詳細については、macOS Tahoe 26.5ベータ1の完全ガイドをご覧ください。
26.5がリリースされ、回避策なしにTime Machineが機能することを確認したら、すべてのネットワーク接続でSMB署名のデフォルトが復元されるように/etc/nsmb.confを削除または元に戻すことを忘れないでください。
トラブルシューティングチェックリスト
nsmb.confの回避策が最初の試みでTime Machineを修正しない場合は、問題がより特殊なものであると仮定する前に、このチェックリストを確認してください。
共有をイジェクトして再マウントします。 macOSは共有が完全にイジェクトされるまで、共有のネゴシエートされたSMBセッションをキャッシュします。FinderでNAS共有をイジェクトし、10秒待ってから、Finderから共有パスを手動で入力して再接続します。その後のみTime Machineバックアップをトリガーします。
Macを再起動します。 一部のユーザーは、SMBクライアントが次の起動まで新しいnsmb.confを拾わないと報告しています。再起動は問題をさらに追跡するよりも速いです。
NASファームウェアを更新します。 NASにTahoe固有の修正がない場合でも、最近のファームウェアアップデートにより、macOSの変更と相互作用する方法でSMBネゴシエーションが改善されている可能性があります。Synology DSM 7.2.2u4、QNAP QTS 5.1.7、TrueNAS SCALE 24.10が最小推奨バージョンです。
共有の権限を確認します。 Time MachineがNASで使用するユーザーアカウントがTime Machine共有への読み取りおよび書き込み権限を持っていることを確認します。一部のNASファームウェアアップデートはアップデートプロセス中に権限をリセットします。
スパースバンドルの整合性を確認します。 以前のバックアップの試みが部分的なスパースバンドルを残した場合は、手動でマウントしてhdiutil verifyを実行します。破損したスパースバンドルはSMBレイヤーが修正された後でもTime Machineを失敗させます。深刻なケースでは、スパースバンドルを削除して最初からやり直すことが最もクリーンな方法です。
Time Machineの宛先が認識されていることを確認します。 システム設定→一般→Time Machineを開き、宛先がリストにまだ表示されていることを確認します。ドロップオフした場合は、SMBレイヤーが機能してから再追加します。
ネットワーク接続を確認します。 TerminalからNASにpingを実行して、MacがNASにまったく到達できることを確認します。SMBはIPレベルの接続とSMBポート（通常は445）の両方が到達可能である必要があります。
カーネルログを見ます。 バックアップが失敗した後、log show --last 5m --predicate 'process == "kernel"' | grep smbを実行します。カーネルレベルのSMBエラーは、障害が署名ネゴシエーション、認証、ツリー接続、またはファイル操作レイヤーのどこにあるかを明らかにします。
これらすべての後でもバックアップが失敗する場合、特定のNASファームウェアの組み合わせがserverMarkers.plistアプローチまたはNAS側のsmb.confの変更を必要とするアウトライアーである可能性があります。NASモデル、ファームウェアバージョン、正確なカーネルログの行を関連するベンダーフォーラムに投稿することが、通常は機能する修正への最速の道です。
よくある質問
Q: nsmb.confの回避策はWindowsパソコンへのSMB接続に影響しますか？
A: はい。[default]セクションの変更はMacが行うすべてのSMB接続に適用されます。Windows接続を厳格にしたままにしたい場合は、NASホスト名をセクション名として使用して、変更をサーバーごとのセクションに限定します。
Q: 修正を適用した後、Time Machineのバックアップを全部やり直す必要がありますか？ A: いいえ。SMBセッションが正しく確立されると、Time Machineは中断したところから再開し、次の増分バックアップを書き込みます。スパースバンドル自体が以前の失敗した試みによって破損していた場合のみ、完全な再バックアップが必要です。
Q: 修正を試みましたが、Time Machineが引き続き失敗します。次はどうすればいいですか？ A: 上記のトラブルシューティングチェックリストを確認し、カーネルログの行に特に注意を払ってください。最も一般的なフォローアップの原因は、残留するSMBの問題ではなく、以前の失敗した試みからの破損したスパースバンドルです。
Q: コワーキングスペースに持っていくMacに修正を適用しても安全ですか？
A: コワーキングネットワークからホームNASへの未署名SMBを実行するよりは安全ですが、最もクリーンな答えは、NASファームウェアを更新してサーバー側の署名が必須になるようにするか、ホームNASのホスト名にのみnsmb.confの例外を限定することです。
Q: macOSのアップデートごとに修正を繰り返す必要がありますか？
A: /etc/nsmb.confファイルはアップデートにわたって持続します。アップデートが特定のシステム設定ファイルをリセットしない限り、再適用する必要はありません。これは稀なことです。
Q: 修正はiCloudバックアップ、AirDrop、または他のAppleサービスを壊しますか？
A: いいえ。これらのサービスはSMBを使用せず、nsmb.confの変更による影響を受けません。
Q: macOS SequoiaまたはSonomaで同じ修正を使用できますか？ A: ファイル形式は同じで、同じ行が機能しますが、SequoiaまたはSonomaでは必要ないはずです。SMB署名の変更はTahoe 26.4に固有であるためです。古いmacOSバージョンに修正を適用しても無害ですが不要です。
Q: NASベンダーがこれを修正するファームウェアアップデートがあると言っています。それでもnsmb.confを保持すべきですか？
A: ファームウェアアップデートが適用され、回避策なしにTime Machineが機能することを確認したら、nsmb.confを削除します。緩和を継続して保持することは不要であり、セキュリティベースラインを下げます。
Q: nsmb.confを編集するGUIツールはありますか？
A: Appleからの公式ツールはありません。GitHubにいくつかのサードパーティツールが存在しますが、2行のファイルのためにTerminalアプローチは新しいユーティリティをインストールするよりも速く低リスクです。
Q: 26.5がリリースされたとき、Appleは修正を26.4にバックポートしますか？ A: AppleはSMBリグレッションに対処する26.4.2パッチにコミットしていません。歴史的に、Appleは特に非セキュリティリグレッションについてはバックポートよりも次のメジャーポイントリリースに修正を組み込むことを好みます。26.5を解決策として計画してください。
結論
macOS Tahoe 26.4のSMB署名変更はセキュリティの観点からは正しい決断でしたが、ベンダーの調整不足により、NASベースのTime Machineバックアップは数週間困難な状況に置かれています。/etc/nsmb.confの回避策は短く、可逆的で、即座のニーズに対応します。より永続的な答えは、NASファームウェアを最新の状態に保ち、サーバー側で署名が必須になるようにして、接続全体で厳格な署名が復元されるようにすることです。
2026年5月下旬以降にこれを読んでいる場合は、回避策を適用する前にmacOS 26.5がリリースされているかどうかを確認してください。26.5が利用可能であれば、インストールするとシステムファイルの変更なしにTime Machineバックアップが再開されるはずです。回避策を適用して26.5がインストールされている場合は、5分かけてnsmb.confをロールバックし、厳格な署名が復元されてもバックアップが機能することを確認します。
バックアップは何かが壊れたときにのみ考えるインフラの種類であり、26.4リグレッションは単一のバックアップ宛先に依存することがリスクであることの有用なリマインダーです。今週どの修正パスを取っても、次のmacOSアップデートが来る前に2番目の独立したバックアップターゲットを追加することを検討してください。