Moving off Google

Please join me at my new blog.

(Why give any more to Google - home of "Do(n't) be evil".)

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.

I just dismissed the screensaver - why is every keypress ignored?

You just authenticated to your Mac, and the screensaver cleared, to put you right back to where you were - almost.

This is why every keypress is ignored - aside from beeping at you.

Look more closely… Why are the window controls grayed out, as if it's not the active window?

Yeah; it's not exactly right back where you left off - the keyboard focus has not returned to your window; apparently, a side effect of the screensaver. 

Solution: Click where you want the focus (your document, terminal window, whatever), and off you go.

Note: This also affects at least some global key equivalents (I recently whipped up something to really Skip a track in iTunes) - and in such cases the solution is the same: Click somewhere, and they'll work.

Weird.

Music (was iTunes) and Skipped vs Played - ish

Turns out, Apple's macOS Music app, uses some arcane rules to determine if and when a track is logged as a Skip, or Played.

Which doesn't much matter - unless you want to use that info in a Smart Playlist. 😕

I want to listen to something different, so I use that metadata, to filter out tracks either recently listened to, or recently skipped - which shakes things up nicely.

For awhile now, it's been nagging at me, that I seemed to be hearing tracks I should't - a bit of research led to the link above. I frequently hit the FF button within the first few seconds, so those don't count as Skips. 😕

I wrote a quick AppleScript to use, instead of the default FF button, and force a Skip (by first moving playback to the 6s mark); I use it on a Quicksilver Trigger (see p. 34 of the Quicksilver manual) - though you can use this code however you like:

tell application "Music"

if player state is playing then

set player position to 6

next track

end if

end tell

I'm no expert at Quicksilver Triggers, however here's how I set it up:

• Open Quicksilver and navigate to Triggers (icon in top menu).
• Press dot (period), in the top pane, to be able to paste text.
• Paste the code above (newlines and all).
• The 2nd pane may already be set to the proper kind of code execution: "Run as AppleScript".
• If not, set that.
• If it's not available, you may have to enable that Action.
• Click "Save".
• Click into the "Trigger" column (right), to assign a hotkey.

iCloud Drive: some files refuse to upload

I recently moved a large group of files (many directories) to iCloud Drive - so they'd be available on my other devices - and watched as they all uploaded...

Then did some testing to confirm - only to find that many files never did upload. (I tested over the course of _weeks_; this was not an issue of bandwidth.)

I compared (using diff) the state of the Mac on which the files were first moved into iCloud, versus the files on another Mac which was freshly set up with iCloud, so got them only via iCloud sync. (I also spot-checked, using the web interface for iCloud Drive.)

So I started trying to determine why. It's a somewhat lively source of discussion - among those who've actually noticed the problem -- which is almost entirely invisible, unless you go looking for it. :/

Much of the discussion was the expected (unfortunately) reflexive "have you tried turning it off and on again?" - about killing processes, deleting various files (ex: ~/Library/Application Support/CloudDocs) and rebooting - and, as expected, none of that helped.

However, the clue I needed was in this Ask Different post: iCloud Drive stuck on “Waiting to upload”

(BTW: The only way to see that "Waiting to upload" message, is to first already know that there's a file in that state; then hover over the tiny dotted line cloud icon next to it, in Finder. Nearly-invisible errors are a terrible thing. And, unfortunately, info about iCloud Drive status icons is hard to find, and somewhat limited. Note also: Contrary to the info in the above link, the icons are for iCloud Drive, regardless whether the sub-feature of Desktop and Documents is specifically enabled - in my case, that's disabled.)

With the info gained above, I see that in all the cases that I'm dealing with - of a file stuck in "Waiting to upload" - each of them has an extended attribute com.apple.metadata:kMDItemWhereFroms which is _very large_.

It does not contain, as expected, a URL of where the document came from - but it actually apparently contains another copy of the full document. :/

This metadata is also apparently unexpected / dysfunctional, since even though it shows via ls or xattr, the mdls command ignores it.

So now I'm even more sure, that this extended attribute is disposable. One last question: Does removing it, update the "modified" timestamp (which is useful info that I want to preserve)? Thankfully, some testing shows that the timestamp is unchanged.

So what I did (standard disclaimers apply - use at your own risk) to find and fix all such files in my iCloud Drive directory, was something like this:

find ~/Library/Mobile\ Documents/com\~apple\~CloudDocs \
    -type f \
    -xattrname com.apple.metadata:kMDItemWhereFroms \
    -print | while read -r thePath; do
        testVal=$(xattr -lp com.apple.metadata:kMDItemWhereFroms "$thePath" 2>/dev/null | \
            head -5 | tail -4 | sed 's/^.* |//;s/|$//' | tr -d '\n')
        if [ $(echo "$testVal" | grep -E -c 'data:(application|attachment)') -gt 0 ] ; then
            echo 'BEFORE:'
            ls -l@ "$thePath"
            xattr -d com.apple.metadata:kMDItemWhereFroms "$thePath"
            echo 'AFTER:'
            ls -l@ "$thePath"
        fi
        done

Quite soon after doing the above, bird noticed and sync'ed them all. Nice.

(BTW: Check out brctl - fun to watch that _really_ verbose log - though didn't seem help in my case.)

macos term file "could not be opened because it is corrupt"

A ".term" file is a useful way to wrap up some command-line stuff, in a neat little package which requires no command-line knowledge, no luck in typing it perfectly, etc. - for some discussion, see these old Hints articles: Run shell scripts from GUI and Use partial .term files for quick… (note that the ExecutionString attribute can be anything you want…).

I was working on a new .term file, having started by duplicating a perfectly usable one - but getting this unhelpful error:

The file “test.term” could not be opened because it is corrupt.

It may have been incompletely copied from another machine.

And then _finally_ remembered that the file is XML, and ampersands have literal meaning, so must be "escaped", as in HTML, like so:

&

Hopefully, noting that here, saves someone (like myself) a bit of hair-tearing next time.

FileVault Mac, in headless mode, notifies on boot

Oh; fun!

I'm lucky enough to be experimenting with a new M1 Mac mini, and followed through the prompts (on a kinda autopilot, from setting up my own MacBook) to set it up with FileVault 2 "full-disk encryption", even though this will be a server.

So I found out the hard way, that this then requires (purposely; for security) entering a password _very_ early in the boot process - before it even gets an IP address.

Which also means no remote connection; not via Screen Sharing, or ssh - no headless.

(Note: There is a way to avoid this - for a single boot.)

But; back to the cool part; I rebooted (to apply a software update) before I remembered the above, and a few moments later, while I was trying to debug why I couldn't reach it, the mini (which was indeed headless), started playing the "Find My..." sound effect - that is a nice touch!