Series · The Quiet Machine · Part 6

Making the Box and Mac a Symmetric Server, No macFUSE

August 24, 2026 · 6 min read · The Quiet Machine · Part 6

Finder showed me exactly one shared folder from the box, the share I’d set up weeks earlier. Not the D:\ drive underneath it, where every project and every build lived, just that one folder. I wanted the whole drive in Finder, drag-and-drop, like a local disk — one more piece of turning this into a symmetric server, box and Mac each fully reachable from the other.

The rest of the box was already locked down: RDP, SMB, SSH, all riding a private WireGuard mesh. The file share alone hadn’t kept up.

The answer every forum post gives you is SSHFS: mount the remote filesystem over the SSH connection you already trust. So I went to install it and walked straight into the Apple Silicon wall.

The macFUSE ordeal I didn’t finish

SSHFS on macOS needs macFUSE, a kernel extension. On an Intel Mac that’s mildly annoying. On Apple Silicon it means booting into Recovery, lowering the kernel-extension security policy, approving the kext, and rebooting twice. It stays loosened until you go back into Recovery to undo it.

I’d spent days making the box airtight so the Mac could stay the trusted brain, and here was a “convenient” filesystem mount asking me to downgrade the Mac’s own posture, a Recovery-mode kernel policy change, just to save myself a config edit. I backed out before the first reboot.

The lighter win: share more of what already works

The realization was almost embarrassing. I already had a working, kernel-free file path: SMB. The box was already sharing one folder over it, and nothing stopped me from sharing the whole drive. I broadened the existing share from that one folder to the whole D: drive, full access locked to a separate share account, and mounted it in Finder over the tailnet.

Whole drive, read/write, in Finder: no macFUSE, no Recovery mode, no reboot. I almost never need C:\ in Finder, and when I do, RDP already gives me the full desktop; the dev life lives on D:\, so D:\ is what gets mounted.

I was moving files between two machines on the same network, exactly what SMB was built for. SSHFS was solving a problem I didn’t have (an untrusted network with no SMB) at a price I didn’t want to pay: a kernel extension.

Then it flipped: the Mac needs the same treatment

Up to here every arrow pointed one way, Mac reaching into box. But the goal had quietly gotten bigger: driving Claude and the agents from my phone too, eventually from a chat app where texting a message kicks off an agent run at home.

A chatbot that “runs an agent” is, underneath, nothing more than SSHing in and running a command. That means the Mac has to be the reachable one, not the box: the machine that talks to Claude and orchestrates the agents.

So the Mac got the same server treatment, pointed inward:

  • Remote Login (SSH): the phone SSHes into the Mac over the tailnet and runs claude. This is the whole end-game in one line; the chatbot is just a thin wrapper over it.
  • File Sharing (SMB): one shared Mac folder shows up in the iOS Files app. Deliberately one: share the common bucket, don’t expose the machine.
  • Screen Sharing (VNC): see and control the Mac’s screen from the iPhone when only a GUI will do.

Same three surfaces I’d opened on the box, now mirrored on the laptop.

The laptop problem: it sleeps when you close it

Close the lid and the MacBook sleeps: the tunnel drops, the phone can’t reach it. macOS has the switch:

sudo pmset -c disablesleep 1

That -c matters: on charger only. Lid shut, on power, no external display, and the laptop stays awake like a desktop box.

I refused to flip it globally: the battery math is bad. Keeping a laptop awake lid-closed in a bag, on battery, until it hits 0% traps heat with no airflow and forces a full drain-cycle, real harm to the battery. So I scoped it to AC; on battery it still sleeps, with an on-demand road mode for when I need it:

sudo pmset -b disablesleep 1   # battery too — for the road, then turn it back OFF

That buys meaningful unplugged runtime, with no timer to save you. A deliberate, temporary choice I flip back off once I’m home.

The keychain gotcha macOS won’t let you around

I wanted the phone’s SMB folder to auto-mount on the Mac at login, password-free, via a LaunchAgent. It kept failing, but only as a background agent; mounted by hand in Finder, it worked instantly.

The reason is a macOS security boundary: the login keychain belongs to the GUI session, and macOS won’t hand it to a background LaunchAgent, so the agent can’t read the stored password. The fixes are a Login Item, which does run in the GUI session, or an inline credential in the mount config.

Writing that inline credential is exactly where my own tooling stopped me again. The same guardrail that refused to write ~/.ssh/config earlier now refused to inline a share password. Third time this build, and third time it was right.

Locking the Mac to the tailnet, and proving it

Opening SSH, SMB, and VNC on my daily-driver laptop is a bigger deal than on a headless box in a closet: anyone on the café Wi-Fi could knock on those ports. So I did to the Mac what I’d done to the box: tailnet-only, with a pf firewall anchor.

# /etc/pf.anchors/tailnet-lock — pass the tailnet + localhost, block the rest
pass in quick proto tcp from <tailnet-range> to any port {22, 445, 5900}
pass in quick proto tcp from 127.0.0.1 to any port {22, 445, 5900}
block drop in quick proto tcp to any port {22, 445, 5900}

Loaded and persistent at boot. I didn’t take it on faith. I proved it from the box, hitting the Mac two different ways: over plain LAN, on the Mac’s own subnet address, all three ports timed out; over the tailnet, on the Mac’s tailnet address, all three came back open.

LAN blocked, tailnet open, on all three ports. Reachable over the tailnet, not over the plain LAN address it also sits on.

Next up: turning the box into a real dev workstation, and the “install once, for everyone” discipline that turned out to be harder than any install command.