jupyter trust signed the notebook but outputs still blocked: signature db moved

TL;DR

Trust signatures live in a small database under the Jupyter data directory, and if that directory moved (new HOME, container rebuild, profile migration) the server reads an empty database while the CLI may have written to the old one. Find the database the running server actually uses via jupyter --paths, then run jupyter trust in the server's context so the signature lands in the right database. Outputs unblock as soon as the server's database holds a matching signature.

jupyter trust signed the notebook but outputs still blocked: signature db moved

Use this when

• jupyter trust notebook.ipynb says trusted, but the browser still shows Not Trusted and blocks outputs.
• Trust worked before a home-directory migration, container rebuild, or user change, and broke after.
• The CLI and the server seem to disagree about trust state.

Not for this skill when

• Trust is lost after every git checkout. That is byte churn invalidating signatures, a different fix.
• You suspect the notebook contains hostile outputs. Do not force trust; inspect first.

Steps

1. Find the server's data directory: run jupyter --paths in the exact context that runs the server (same user, same container). Expected: a data directory path; the signature database lives beneath it.
2. Compare with the CLI context: run jupyter --paths in your terminal and diff the data directories. Expected: you can see the two contexts point at different databases.
3. Run the trust command as the server user and context: jupyter trust notebook.ipynb there. Expected: the signature is written to the database the server reads.
4. Reload the notebook and check the trust indicator. Expected: Trusted, with JavaScript outputs rendering.
5. If the database file itself is corrupt or zero-length, back it up, remove it, and re-trust the notebooks you actually use. Expected: a fresh database with valid signatures; previously trusted notebooks need one re-trust each.
6. Document which context owns trust in your setup (dev container user, service account) so future jupyter trust calls run there. Expected: no repeat of the CLI/server split.

Tool compatibility

nbformat 5.x signing; jupyter_core 5.x paths; notebook 6.x/7.x, JupyterLab 3.x/4.x.

Variant phrasings

jupyter trust not working outputs still blocked

The symptom phrasing. Check that the CLI and server share one signature database.

notebook trust database location moved

The cause phrasing. Re-point by trusting in the server's context.

trusted notebook still shows not trusted jupyter

The indicator phrasing. Two databases are in play; find the server's one.

Why it happens

The trust database is just a file under the Jupyter data directory, and jupyter --paths resolves that directory from HOME, environment variables, and install prefix at call time. When any of those differ between your terminal and the server process, perhaps the server runs in a container with a different HOME, or as a service account, the CLI happily signs into a database the server never reads. Both sides report success in their own world. The fix is boring but essential: perform the trust operation in the server's world, not yours.

Edge cases / pitfalls

• Deleting the database to 'fix' trust wipes every signature, forcing a re-trust of all notebooks. Back it up first and prefer targeted repair.
• Some deployments mount the data directory read-only. Then trust can never persist, and the real fix is a writable mount or a policy decision.
• Running jupyter trust with elevated privileges writes root-owned database files that the server user cannot read later. Match the user, not just the path.
• Agents in ephemeral containers should treat trust as per-boot state and re-trust known-good notebooks at container start.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_NO16rVlOAFNFSsRECHZ6Qg