Mac
Mac Screen Sharing Fails After Restart (FileVault)
Your headless Mac won't accept Screen Sharing until someone logs in locally. macOS Tahoe 26 fixes this: unlock FileVault over SSH, then reconnect.
Problem summary
I'm here because I rebooted a Mac I run headless — a Mac mini server, a machine in another room, a box I only reach over the network — and now Screen Sharing (and often SSH and Finder file sharing) refuses to connect until somebody walks over and types a password at the login screen. This is not a Screen Sharing bug and not a network fault. FileVault means the Mac has not finished booting: the Data volume is still locked, so the OS and its sharing services do not exist yet. macOS Tahoe 26 added the first real fix — you can now unlock FileVault over SSH — and this page sets that up, plus the fallbacks for planned reboots and for Macs not yet on Tahoe.
From another machine, run `ping <host>.local` while the Mac is in the failed state.
sudo fdesetup status
The host answers, proving it is powered on and has an IP — so this is not a power or cable fault.
Do not rely on this as your outage plan — it only covers the restart it performs.
Layer path
Step-by-step runbook
Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.
Establish which of the three states the Mac is in
Check: Ping the host, then try SSH, then test port 5900.
Expected result: Pings but refuses sharing ports = pre-boot locked. All answer = booted. Nothing answers = power or network.
If not: If nothing answers, stop here and resolve power and link before touching any sharing setting.
Enable Remote Login while you still have access
Check: System Settings → General → Sharing → Remote Login on, with your admin user in the allowed list.
Expected result: Remote Login is on; this is what makes every future reboot recoverable remotely.
If not: If the machine is already locked you need physical access once to do this — after that it stops blocking you.
Unlock over SSH after the restart
Check: SSH in with a local account name and password, and read the confirmation.
Expected result: The system reports that it unlocked successfully and boot completes.
If not: No prompt means Remote Login was not on beforehand, the OS predates Tahoe 26, or there was no network at boot.
Reconnect for a real session
Check: Close the unlock session and connect again over SSH or Screen Sharing.
Expected result: You get an ordinary session on the fully booted machine.
If not: If Screen Sharing alone still refuses, enable it in Sharing settings — it is a separate service from Remote Login.
Use an authenticated restart for reboots you plan
Check: Run `sudo fdesetup authrestart` instead of a normal restart.
Expected result: The Mac returns unlocked and immediately reachable.
If not: If it errors that FileVault is off, encryption was never the blocker.
Safe stop: Do not rely on this as your outage plan — it only covers the restart it performs.
Make the encryption decision deliberately and write it down
Check: Choose one: FileVault plus SSH unlock, FileVault plus manual unlock, or FileVault off on a fixed non-sensitive machine.
Expected result: A documented choice, with the recovery key stored somewhere other than the encrypted disk.
If not: If the machine holds anything personal or ever leaves the house, keep FileVault on.
Safe stop: Stop before disabling FileVault on a laptop, or on any Mac holding financial, medical or identity documents.
Reduce how often you land in this state at all
Check: Put the Mac on wired Ethernet and on a UPS, and configure automatic power-on after a power failure.
Expected result: Unplanned reboots become rare, and the ones that happen are recoverable without a trip to the machine.
If not: If Ethernet is genuinely impossible, plan for manual unlock after outages.
Decision tree
If: Host pings but SSH and port 5900 both refuse, and FileVault is on
Then: Classic pre-boot locked state after a restart.
Action: Use the SSH unlock on Tahoe 26; on earlier macOS, unlock physically once and then use authrestart for planned reboots.
If: SSH answers with a lock prompt
Then: You are talking to the pre-boot unlock path, exactly as designed.
Action: Supply a local account name and password, then close and reopen the connection.
If: SSH unlock succeeds but Screen Sharing still refuses
Then: The Mac booted; Screen Sharing itself is off or your account is not permitted.
Action: Enable Screen Sharing in Sharing settings and add your user to its allowed list.
Safe stop: Do not disable FileVault chasing this — encryption is no longer the blocker at this point.
If: Nothing answers at all, including ping
Then: Power, network, or a failed startup — not a FileVault symptom.
Action: Check power, the Ethernet link light, and whether automatic power-on after an outage is configured.
If: Machine is pre-Tahoe and must reboot unattended
Then: No remote unlock path exists on that OS.
Action: Either upgrade to Tahoe 26, accept manual unlock, or make a deliberate decision about FileVault on that machine.
Safe stop: Stop before disabling FileVault on any Mac that leaves the house or holds personal records.
Evidence table
| Symptom | Evidence to collect | Likely layer | Next action |
|---|---|---|---|
| Screen Sharing worked yesterday, fails after a reboot | Whether the Mac pings, and what SSH says | Boot state (FileVault pre-boot), not the sharing service | Unlock over SSH, then reconnect |
| Finder shows the Mac but connecting fails | Result of `nc -vz <host>.local 5900` versus a successful ping | Service discovery advertises the host while the OS is still locked | Treat discovery as unrelated to reachability; unlock first |
| SSH reports that the system is locked | The literal prompt text, and whether a second connection then succeeds | Tahoe 26 pre-boot unlock path | Enter the local password, then reconnect for a real session |
| Unlock works over Ethernet but not Wi-Fi | Which interface is active, and the exact macOS point release | Network availability during the pre-boot stage | Move the machine to wired networking |
| Works after a planned reboot, fails after a power cut | Whether `fdesetup authrestart` was used for the planned one | authrestart covers only the restart it triggers | Set up the SSH unlock path, and add a UPS to reduce abrupt reboots |
Commands and settings paths
Confirm FileVault state
sudo fdesetup status
Where: Terminal on the Mac once it has booted
Expected: Reports whether FileVault is On or Off.
Failure means: On confirms encryption is what gates the boot; Off points at a different cause.
Safe next step: If On, enable Remote Login so the next reboot can be unlocked remotely.
Unlock a locked Mac remotely
ssh <localuser>@<host>.local
Where: Terminal on another machine, target running macOS Tahoe 26 or later
Expected: A message that the system is locked, a password prompt, then confirmation that it unlocked.
Failure means: Connection refused means Remote Login was off before the reboot, or the OS predates Tahoe 26.
Safe next step: After a successful unlock, close the session and connect again for a normal shell.
Test the Screen Sharing port without a GUI client
nc -vz <host>.local 5900
Where: Terminal on another machine
Expected: Succeeds only once the Mac has fully booted with Screen Sharing enabled.
Failure means: Closed while the host still pings is the signature of the locked pre-boot state.
Safe next step: Use this to separate a boot problem from a Screen Sharing configuration problem.
Authenticated restart for planned reboots
sudo fdesetup authrestart -delayminutes 0
Where: Terminal on the Mac, before you reboot it
Expected: The Mac restarts and comes back unlocked without anyone at the keyboard.
Failure means: An error that FileVault is not enabled means encryption is not your blocker.
Safe next step: Remember this covers exactly one restart; it does nothing for a later power cut.
Check the exact macOS release
sw_vers
Where: Terminal on the target Mac
Expected: ProductVersion of 26.0 or later means the SSH unlock path exists.
Failure means: An earlier version means no remote unlock is available on that machine.
Safe next step: Use the version to choose between the SSH unlock and the authrestart workaround.
Hardware and platform boundary
Change only when
- You are buying a Mac to run headless and remote reboots are part of the job — start on macOS Tahoe 26 or later so the SSH unlock path exists.
- You keep making physical trips to a machine in another room or building purely to type an unlock password.
Evidence that matters
- Wired Ethernet on the machine that must unlock remotely.
- A UPS sized to ride out short outages, so most reboots are planned rather than abrupt.
- macOS Tahoe 26 or later, for FileVault unlock over SSH.
Evidence that does not matter
- CPU, RAM and storage speed — none of them affect whether a locked Mac can be unlocked remotely.
- Third-party remote-desktop software; it cannot run before the OS boots either.
Avoid
- Avoid disabling FileVault on portable Macs, or on any machine holding personal records, just to get unattended boot.
- Avoid relying on `fdesetup authrestart` as your outage plan — it only covers the restart it triggers.
- Avoid assuming Screen Sharing, Remote Login and Remote Management are one setting; they are three, with separate allowed-user lists.
Related tool/checklist
Use the linked tool when you need a guided plan from your exact symptoms instead of a static checklist.
Device setup troubleshooterRelated problems
Last reviewed
2026-08-04 · Reviewed by HomeTechOps. Written against Apple's macOS Tahoe 26 enterprise release notes, which document FileVault unlock over SSH when Remote Login is enabled, and Apple's Screen Sharing documentation for the separate sharing services. The page deliberately declines the common forum advice to simply switch FileVault off, and frames it as an explicit trade-off instead. The Wi-Fi-versus-Ethernet caveat is reported operator experience from early Tahoe point releases rather than documented Apple behaviour, and is labelled as such on the page.
Sources/assumptions
- The SSH-unlocks-FileVault behaviour is specific to macOS Tahoe 26 and later; on earlier macOS a FileVault-locked Mac genuinely requires physical access at the login screen.
- Assumes Apple silicon or a T2 Mac, where the internal drive is always encrypted at rest and FileVault adds the credential requirement at boot.
- The Wi-Fi-versus-Ethernet behaviour in the pre-boot unlock stage was reported by operators during early Tahoe point releases and has improved since; verify on your own point release rather than assuming.
- Screen Sharing, Remote Login (SSH) and Remote Management are three separate services with separate allowed-user lists; this page assumes you want Screen Sharing but enables Remote Login as the unlock channel.
Source-backed checks
HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.