【Macのファイル共有領域にWindowsからアクセスできない】macOS Tahoe 26.5（M1 Mac mini）のファイル共有（SMB）、起動時にデスクトップ画面からログインもしくはSSHでログインしないとSMBプロセス（デーモン？）が立ち上がらない？【FileVault有効時の仕様？】

現在、ファイルサーバーに
★Mac mini（Mac mini (M1, 2020) Macmini9,1）のmacOS Monterey Ver 12.7.6をmacOS Tahoe 26.4.1へアップデート（2026年5月4日(月曜日)）
★Mac mini（Mac mini (M1, 2020) Macmini9,1）のmacOS Tahoe 26.4.1をmacOS Tahoe 26.5へアップデート（2026年5月12日(火曜日)）
この環境で使っております。で、夜中に使ってないのに動かしててもという事で
★M1 Mac mini(macOS Tahoe 26.5)で決まった時間に自動起動してもらい、決まった時間に自動でシャットダウン（電源断）してもらいたい時の設定【CUIのみ設定可、ターミナルでpmsetコマンド使用】（2026年5月30日(土曜日)）
macOS Monterey Ver 12.7.6の時にもやっていた特定の時間になったら自動でシャットダウン（電源を切り）、特定の時間になったら電源ONになる設定にしました。

で、ファイル共有やSSHで共有している時はダイアログが出て電源断にならない、なんてのはまあいいとして自動電源Onで起動した場合、Windowsからファイル共有領域にアクセスできないのに気がつきました。え？デーモンというかサービスなんだから別にログインしなくてもSMBのプロセスは立ち上がるでしょ？と思いましたが何度やってもデスクトップからログインしないとSMBプロセスが立ち上がらない。
何？OSアップデートの仕様で
★launchctl でサービスを自動起動する - koba::blog

man 8 launchd
~/Library/LaunchAgents Per-user agents provided by the user.
/Library/LaunchAgents Per-user agents provided by the
administrator.
/Library/LaunchDaemons System-wide daemons provided by the
administrator.
/System/Library/LaunchAgents Per-user agents provided by Apple.
/System/Library/LaunchDaemons System-wide daemons provided by Apple.q

OS管理の定期起動サービスもしくはOS管理の常駐サービスから各ユーザー管理の定期起動サービスもしくは管理者管理の定期起動サービス・常駐サービスに仕様が変った？
SSHは問題なし、Google Chrome リモートデスクトップも問題なし、なぜSMBによるファイル共有だけが？

GUIの設定を見てもファイル共有はOnになっております。
ログイン後に
sudo launchctl print system/com.apple.smbd
と現状を確認すると
state = running
となっており起動状態。

サービスが有効化（Enable）されているか確認で
sudo launchctl print-disabled system | grep smbd
とすると
"com.apple.smbd" => enabled
Onになっております。

いろいろAIも含めて調べると

https://share.google/aimode/H3qHSzAm9QvFfjkmc
https://share.google/aimode/8VH35vtTlL93yOuMi

macOSのSMBファイル共有（com.apple.smbd）は、システム起動時（ログイン前）ではなく、最初のユーザーがログインしたタイミング（または、暗号化されたディスクが解除されたタイミング）で実質的にアクティブ化する仕様になっています。
FileVaultが有効な状態でSSHのリモートログインができるということは、まさにmacOS Tahoe（macOS 26）から導入された「Preboot（起動前）のSSHサーバー」経由でMacに繋がっている状態です。この状態のとき、Macはまだ「データボリューム（ストレージのメイン領域）」を暗号化解除しておらず、OSのフル機能が起動していません。そのため、いくら launchctl でSMBを叩いても、共有すべきユーザーデータにシステムがアクセスできないためSMBは起動しません。つまり、解決手順は「SMBを無理やり起動させる」のではなく、「SSH経由でFileVaultを解除して、OSをフルブートさせる」ことになります。以下の手順で、ログイン画面にいる状態からSMBを起動可能な状態まで移行させることができます。ステップ1：SSH経由でFileVaultのロックを解除するリモートのターミナルからMacにSSH接続した状態で、以下のコマンドを実行してメインディスクを復号（アンロック）します。bashsudo fdesetup unlock

そんな仕様なの？そういやOSアップデート時にFileVaultが強制的にOnになってた気がしますがそれのせいなのか。ただWindowsだって暗号化しますよね？Windowsのファイル共有でもそんな仕様？そんなわけないよね？macはもうサーバー用OSはないわけですがそれでもこの仕様はどうなの？

macOSをファイル共有サーバーにするな、というAppleから意思表明なのかもしれませんが、サーバーOSっぽいところは残していただきたいなぁ・・・・・まあ一度ログインしてその後、ログオフ、ロックでもいいのでしょうが暗号化前（OSアップデート前）に比べると一手間増えますなぁ・・・自動ログインか起動スクリプトでどうにかするという手もありますが・・・・・

SSHで一度ログインしようとすると

This system is locked. To unlock it, use a local account name and password. Once successfully unlockd, you will be able to connect normally.（このシステムはロックされています。ロックを解除するには、ローカルアカウント名とパスワードを使用してください。ロック解除が成功すると、通常どおり接続できるようになります。）
こういう画面が出て一度、外からSSH接続したターミナルが終了し、この時点でほぼロックが解除されたようでWindowsファイル共有が使えるようにSMBのプロセスが起動開始しておりました。なのでSSHでログインして更にbashsudo fdesetup unlockコマンドを実行する、は必要ないようです。

Macをヘッドレスサーバー（ディスプレイなし）として運用の場合は自動ログインを有効化しろとかはまあサーバーではやりたくないし、コマンドで明示的にバックグラウンド起動を叩くが現実的な対応かしら？

ひとまずそんなに手間じゃないのでSSHでのログインで今の環境では対応できそうではありますが・・・・・