Hi all,
I wanted to bring this to the community’s attention because I believe others with long-term Flame installations on macOS—especially those working on portable setups or without centralized license servers—could run into a similar issue without warning.
Setup Background:
- MacBook Pro 15” 2018 Intel, T2 chip, 2TB SSD
- macOS version: 14.1.1 (Sonoma)
- Flame was installed with full framestore configuration
- Framestore media paths were spread across internal disk (primary user account and admin) and external 8TB SSD
- Services installed:
IFFFS,Wiretap,Backburner
- Admin account managed both volumes and all Flame setup/config files
- Secondary user (non-admin) was intentionally sandboxed from Flame volumes and framestore directories to separate user privileges and protect system integrity
Flame hasn’t been launched at all in over a year, and no update was knowingly applied recently. Flame wasn’t being used, and due to different focus areas, the Macbook didn’t receive maintenance or update-related attention on the root access permissions or any other potentially relevant area.
Problem (Post System Update):
I suspect that this is happening in a chain of reactionary events long after updating to macOS 14.1.1:
I was working as usual on Friday on different projects, and anything Flame related was off. Mid-session during my active session, I recognize that a user lock screen PW being rejected for an admin approval setting update. I tried changing it when the session was active, and I was still logged in. Once the screen lock activated a few minutes later, now, the screen lock wouldn’t accept my existing password. So I have tried many things, but I am in a remote location without access to a second Mac, so I will bring this issue to Apple services authorized upon formerly received advice. But I thought this could be linked to a chain of events because this Macbook was being used as a Flame workstation for a brief time in its history:
- Admin password is no longer accepted at the FileVault unlock screen
- Recovery key fails
- The admin account shows up in FileVault prefs (from secondary user), but returns:
“Authentication is disabled”
- Internal drive shows Disk Ownership: Disabled
- External 8TB framestore drive will not mount from the non-admin session—it asks for admin approval
- Target Disk Mode still boots, but FileVault-encrypted volume rejects password
To clarify:
This is not a forgotten password scenario—the password is known and verified.
This is also not a firmware failure or T2 crash—machine boots, non-admin account runs fine, no boot anomalies.
My Current Assessment:
This is a Secure Token authorization failure, caused by how Flame services had historically been embedded into the disk access layer. My suspicion is:
- The Flame framestore configuration applied deep system-level permissions (possibly nonstandard ACLs or root-level access flags) to internal and external volumes
- macOS 14.1.1, during a post-update Secure Token sweep, revoked authorization from the admin account due to incompatibility or outdated permission logic
- FileVault now sees the account as “present but untrusted” and won’t allow decryption, even with the right password
- The system disk and external disk are now both essentially “owned by a ghost,” with no Secure Token–authorized users left to manage them
Why This Is a Flame-Specific Issue (in my case):
- Framestore configurations on macOS, especially single-user workstations, tend to circumvent native macOS user sandboxing
- Flame installs
LaunchDaemonsand mounts volumes usingrootfor IFFFS and Flame cache - These permissions persist, even if Flame isn’t actively running
- System updates that revise
secureToken,authd, or disk ownership frameworks (which Apple silently improves every 1–2 minor versions now) don’t warn you—they just break trust links silently
What’s Next for Me:
I’m bringing the Mac + the 8TB external to an Apple Authorized Service Provider. My goal:
- Recover access to the FileVault-encrypted internal disk (1.5TB of media)
- Retrieve and remount the external framestore volume (7.7TB full)
- Have Apple reassign Secure Token to the locked admin account using internal AST or Configurator tools
Takeaways for Flame Users:
- If your Flame box uses legacy or locally managed framestore permissions, especially over USB-C drives, you may want to audit:
- Secure Token assignments
- Disk permissions under
diskutil - FileVault policy status via
fdesetup - System integrity settings (
csrutil status, SIP)
- Be cautious updating macOS if you haven’t launched or updated Flame in a while—especially if it was set up before Big Sur/Ventura security hardening
- Sandboxed users without Flame access may survive the update—but admins will lose token rights if their permissions don’t align with Apple’s latest security expectations
I’ll report back with what Apple Support does, but if anyone here has dealt with a Secure Token reassignment issue caused by framestore permissions—especially from Flame—I’d really appreciate any shared experience.
I’m posting this before bringing the machine into Apple service because I want to exhaust all possible insights from those who’ve worked with framestore-bound Flame environments or dealt with Secure Token disconnections before. This system is still intact—no erase has happened yet—and I believe there’s still a window for Terminal-based inspection or rescue via TDM. If anyone can help me walk through permission audits, token revalidation logic, or spot the signs of legacy Flame service interference, your input could make all the difference in preventing an irreversible data loss. I’ll consolidate findings here for others in case this becomes a broader compatibility concern across Flame installations.
Thank you all—deeply—if you’re able to chime in.
Thanks in advance,
Alaz
Flame Daemon Conflict Before FileVault Lockout — Warning Ignored?