Skip to content

Could not unlock local storage after reboot #1317

Description

@FireCulex
~/github/rlai master*
❯ npx supermemory local
npm notice run npx
npm notice run 'supermemory' local

   ██████  ██    ██ ██████  ███████ ██████  ███    ███ ███████ ███    ███  ██████  ██████  ██    ██
  ██       ██    ██ ██   ██ ██      ██   ██ ████  ████ ██      ████  ████ ██    ██ ██   ██  ██  ██
   █████   ██    ██ ██████  █████   ██████  ██ ████ ██ █████   ██ ████ ██ ██    ██ ██████    ████ 
        ██ ██    ██ ██      ██      ██   ██ ██  ██  ██ ██      ██  ██  ██ ██    ██ ██   ██    ██  
  ██████    ██████  ██      ███████ ██   ██ ██      ██ ███████ ██      ██  ██████  ██   ██    ██  

  local · self-hosted · running on this machine

  ◆ encrypted local storage  /home/culex/github/rlai/.supermemory

  ✗ startup failed
      Could not unlock local storage at /home/culex/github/rlai/.supermemory/data.

      The data is almost certainly intact — this is a key mismatch, not corruption.
      The key is derived from this machine's stable id, so the usual cause is a
      changed runtime environment rather than changed data:
        • the service runs without /usr/sbin on PATH, so macOS can't read the
          hardware id (common under launchd) and an older build keyed off the hostname
        • the machine's hostname changed, or the data was moved to another machine

      Try this first — it is non-destructive:
        • run on the original machine, as the original user
        • make sure /usr/sbin is on PATH (macOS reads the hardware id via ioreg there)

      Only if you accept losing this data, back it up before starting fresh:
        mv /home/culex/github/rlai/.supermemory /home/culex/github/rlai/.supermemory.bak
      details also written to /home/culex/github/rlai/.supermemory/error.log

0.0.5
CachyOS

supermemory derives the encryption key from /etc/machine-id. The flow is:
Read /etc/machine-id (33 bytes)
Pipe it through pw6() which XORs it with a hardcoded byte array, then PBKDF2-derives a key
The derived key is used for AES-256-GCM encryption of the data file
The issue is likely that your /etc/machine-id hasn't changed —  modified Feb 9, 2026.

The env.enc file IS the encrypted configuration (your API key, auth secret, etc.), and the data/ file is the encrypted PGLite database. The unlock error comes from trying to decrypt the data file when the server starts, using the key derived from reading env.enc which is encrypted with a different key.
So the real question is: what key was env.enc encrypted with, and why doesn't it match what the server derives today?****

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions