Config macOS to boot headless - with some user accounts protected by FileVault

I recently wrote about some challenges using FileVault on a headless Mac.

And later experimented with a way of getting:

• both headless (including a full boot, headless)
• and FileVault

Which amounts to this:

• Configure the boot volume without FileVault.
• Set up a 2nd volume (APFS makes this easy).
• Encrypt the 2nd volume.
• Create a new "secure" user - whose homedir is on the 2nd, encrypted, volume.

Why? That new user's homedir is now better protected - if for example, the storage were removed.

Notes:

• The "secure" user, can't log in til that 2nd volume is mounted.
• The encrypted volume won't auto-mount (which would kinda defeat the point).
• If you want to be a bit less secure, you could config a user whose homedir is on the unencrypted volume, to use the Keychain to mount the encrypted volume when they log in - in which case, you'd still have to take that manual step (of logging in to the "primary account"), though that would immediately allow the "secure" user to login.

Curious if anyone else is interested in doing anything like this, or if this prompts any thoughts.

Open app using Rosetta, via command-line, on an M1 Mac

Apple has done so many architecture transitions (amazingly well, it's worth noting) that there's an old utility to help with this:

arch -arch x86_64 /System/Applications/Utilities/Terminal.app/Contents/MacOS/Terminal

On an M1 Mac, this has the same effect as clicking the "Open using Rosetta" checkbox, in an app's "Get Info" window, except it's:

• for this run only; you likely want to generally run Terminal native
• via command-line - which is why you're in Terminal anyway 😏

Why would you want to do this? Let's say you're using brew and not ready to try the M1 version - this then requires doing basic things like `brew upgrade` using Rosetta.

(BTW: For anyone not familiar with this sort of thing, it will open a second instance of the app; it doesn't affect the currently-running instance.)

Unable to get IntelliJ to successfully use BBEdit as an External Editor?

Here's what I saw, after I set that up in IntelliJ:

You must allow `bbedit` to send events to the BBEdit application.

Use `tccutil reset AppleEvents` to reset the system's permissions, and try again.

bbedit: error: -1743

I don't want to "reset the system's permissions", even if only for AppleEvents.

So here's what I did instead:

1. Within IntelliJ, open a Terminal pane / tab.
2. At that terminal prompt, paste something like this:
• osascript -e 'tell application "BBEdit" to set position of every window to {0, 44}'
• (Yes that's ugly - it was a handy "innocuous" AppleEvent -- which did the job.)
• And execute it. (ex: Press Return.)
3. Click "OK" to allow IntelliJ to send AppleEvents to BBEdit.

To see the effect this has had:

1. Open System Preferences.
2. Select Security & Privacy.
3. Scroll down & select Automation.
4. IntelliJ is now listed, with the permission to control the BBEdit app.
• Which you also have likely also allowed, for the Terminal app.

Background:

• Config External Tools in IntelliJ
• More detail, on using BBEdit as an external tool in IntelliJ

Mac Bluetooth keyboard sluggish - and/or repeats?

Symptoms

• Press a key – no response.
• Or a several-second time lag, before any output.
• Press a key (even briefly / lightly) and several characters are output.

When observed

• After some time (hours to days).
• Usually, when the screen is locked or asleep
• Which makes entering the password, functionally impossible.

Equipment

• MacBook Air (M1, 2020)
• Apple Magic Keyboard (on Bluetooth)
• macOS Big Sur (V11.4 (20F71))

Workaround

1. Hold Shift and Option, then click the Bluetooth icon in the menubar.
• Yes; challenging when having KB trouble. 😕
• Though at least possible, since these are keys meant to be held down.
• If even this doesn't work, hopefully you have a wired KB handy…
2. Select "Reset the Bluetooth module".
• Hmm; maybe this is possible to trigger with no KB use…
3. There is no step three 😏

Shoutout to the good folks at OSXDaily.