朝、コーヒーを淹れながらニュースを追っていたら、macOS 27の開発者ベータからAFPクライアントが消えた、という記事が目に入りました。AFPで繋がるTime Capsuleや古いNASへのTime Machineバックアップは、次のmacOSで終わり。うちのバックアップはNAS宛です。SMBで繋いだ記憶はあるけれど、記憶と現実が一致している保証はどこにもない。コーヒーが冷める前に確かめることにしました。
まず、何で繋がっているのかを見た
Time Machineのバックアップ先が何のプロトコルで登録されているかは、ターミナルで一発です。
| 1 | tmutil destinationinfo |
手元の出力はこうでした。
| 1 2 3 4 5 | ==================================================== Name : TimeMachine01 Kind : Network URL : smb://***@NAS01._smb._tcp.local./TimeMachine01 ID : F1E12376-92AB-4B62-BC14-C20C9A93594B |
見るのはURLの頭だけです。smb:// で始まっていれば生き残る側、afp:// で始まっていたら移行が必要な側。うちはSMBでした。記憶は合っていた。ここが afp:// だった人は、この記事の後半の移行の話へ飛んでください。
ちなみに mount | grep smb で今のマウントを見ようとしても、待機中は何も出ません。Time Machineのネットワークディスクはバックアップが走るときだけ自動でマウントされる仕組みなので、空でも慌てなくて大丈夫です。
SMBなら安心、とは言い切れなかった
macOS 27のTime Machineが求めるのはSMBの中でもv2/v3です。SMBには1987年生まれのSMBv1という骨董品があって、Time Capsuleが話せたのはAFPとこのSMBv1だけでした。つまり「SMBで繋がっている」ことと「SMBv2/v3で繋がっている」ことの間には、まだ一段あります。実際に何バージョンで会話しているか、ダイアレクトと呼ばれる交渉結果を見にいきます。
バックアップを手動で走らせて、その間に確認します。
| 1 2 | tmutil startbackup smbutil statshares -a |
Permission denied に弾かれた
ここでいきなりつまずきました。
| 1 2 3 | stat_share : SMBOpenServerWithMountPoint() failed for /Volumes/.timemachine/NAS01._smb._tcp.local./…/TimeMachine01 smbutil: unknown status -1073741766: Permission denied |
smbutilが、マウントは見えているのに中を覗かせてくれない。種を明かすと、Time Machineのマウント（/Volumes/.timemachine/ 以下）はログイン中のユーザーではなく、バックアップのデーモンが自分の持ち物として張っている特殊なマウントです。だからユーザー権限の道具は届かない。以前、消えないゴミ箱と格闘した記事で lsof が同じ場所に警告を吐いていたのですが、あれも原因は同根でした。
対処は単純で、sudoを付けるだけです。
| 1 | sudo smbutil statshares -a |
SMB_3.1.1、合格だった
今度は通りました。出力は長いので、判定に効く行だけ抜きます。
| 1 2 3 4 5 6 7 8 | TimeMachine01 SERVER_NAME NAS01._smb._tcp.local. SMB_VERSION SMB_3.1.1 SMB_ENCRYPT_ALGORITHMS AES_128_CCM_ENABLED SMB_ENCRYPT_ALGORITHMS AES_256_GCM_ENABLED SMB_CURR_ENCRYPT_ALGORITHM OFF SMB_CURR_SIGN_ALGORITHM AES_128_GMAC SIGNING_SUPPORTED TRUE |
SMB_VERSION が SMB_3.1.1。SMBの現行最新ダイアレクトで、macOS 27の要件（v2/v3）はお釣りが来る水準です。これで、うちのTime MachineはmacOS 27に上げても止まらない、と実測で言えるようになりました。
ただ、眺めていると気になる行がひとつありました。SMB_CURR_ENCRYPT_ALGORITHM が OFF。署名（改ざん検知）はAES_128_GMACで効いているのに、転送そのものの暗号化は使われていません。SMB 3.1.1なのでAES-GCM/CCMの暗号化能力は両者とも持っている、でも交渉の結果オフになっている、という状態です。自宅LAN内のバックアップなら実害はまずありませんが、NAS側で「転送の暗号化を強制」を有効にすれば載せられます。速度と引き換えなので、私は宅内運用を理由にオフのままにしました。
NAS側からも裏を取った
Mac側の交渉結果だけでなく、サーバが何を提供しているかも見ておきます。SynologyならDSMのコントロールパネル > ファイルサービスです。SMBタブで有効化の状態と、詳細設定の最小/最大SMBプロトコルを確認します。手元の設定は最小SMB2 / 最大SMB3でした。骨董品のSMBv1は最初から受け付けず、上限のSMB3設定が3.x系ダイアレクトを含むので、Mac側で見えたSMB_3.1.1という交渉結果ときれいに辻褄が合います。
同じ画面のAFPタブも見ます。こちらはすでに無効になっていました。もしまだ有効で、しかもどの機器も使っていないなら、これを機に無効化しておくと古いプロトコルの口が閉じます。macOS 27を待たずにできる片付けです。
最後に、日本語の罠をひとつ確かめた
Appleのコミュニティに、TahoeでNASへのバックアップがエラー終了し続け、原因を追い詰めたらmacOSが自動付与したシステムイメージボリューム名に濁点の「バ」が含まれていた、という報告があります。濁点・半濁点はNFC/NFDという正規化形式の食い違いを起こしやすい文字で、しかもこのボリューム名はFinderには出てきません。日本語環境だけが踏む種類の穴なので、うちではどうなっているか見ておくことにしました。
確認は、バックアップが走っている間にディスクユーティリティを開くだけです。サイドバーにバックアップ用のシステムイメージボリュームが現れるので、その名前を見ます。選んで情報ボタン（またはCmd+I）を押せば、名前・マウントポイント・接続がディスクイメージであることまで一覧できます。うちの名前は「Lynxのバックアップ」。日本語入りで、しかも報告の犯人だった濁点の「バ」までしっかり含まれています。それでバックアップは正常に回っている。
だから「日本語名なら即アウト」ではありません。かといって「もう直った」と言い切るのも早い。先の失敗報告も同じTahoe世代で起きていて、環境によって出たり出なかったりする種類の問題、と読むのが正確なところだと思います。NAS側のファイル名正規化の実装差あたりが怪しいのですが、そこまでは追い切れていません。バックアップが正常に動いているなら、日本語名でも触らなくていい。原因不明のエラー終了が続いているなら、この見えない名前を容疑者リストに入れる。そのときはディスクユーティリティから英数字に変えるだけで直った実例があります。
afp:// だった人へ
最初の tmutil destinationinfo で afp:// が出た場合、macOS 27に上げる前にバックアップ先の作り直しが要ります。相手が現行のNASなら、NAS側でSMBを有効にしてTime Machineの共有を作り直し、Macのバックアップ先を登録し直すだけです。過去の履歴は新しい接続には引き継がれず、新規のバックアップチェーンとして始まる点だけ覚悟してください。相手がTime Capsuleなら、機器ごと引退が素直です。Samba 4.24.3を直接載せて延命するTimeCapsuleSMBという有志プロジェクトも存在しますが、再起動後に自動復帰するのは2013年の第5世代のみ、履歴は引き継げず、長期のリストア実績も未知数。愛着がある人の実験としては面白く、バックアップという用途の本線には勧めにくい、というのが私の見立てです。
tmutilで接続先、sudo付きのsmbutilでバージョン、ディスクユーティリティで名前。確認は本当にこれだけで終わって、机に戻ったら、コーヒーはまだ少し温かいままでした。
関連: ゴミ箱の消えないフォルダと半日格闘した話（今回のPermission deniedの伏線はここにありました）／Rosetta 2が消える前に、Macの中のIntelをコマンドで棚卸しした（macOS 27で変わるもの、もう一つの棚卸し）
コメント