GET /api/servers fails in container with Couldn't access platform storage: PermissionDenied #1931

Activity

1. cpuodzius

   added

   bugSomething isn't workingSomething isn't working

   on Aug 5, 2026
2. cliffhall

   added

   v2Issues and PRs for v2Issues and PRs for v2

   on Aug 5, 2026
3. cliffhall commented on Aug 5, 2026

   

   cliffhall

   on Aug 5, 2026

   Member

   More actions

   Triage: Priority High (total 10)

   • Severity 4 — a core workflow is unusable: GET /api/servers 500s, so the catalog is unreadable and the UI shows no servers even though POST persisted them (the 409 on re-add confirms it). Not 5 — it is scoped to containers with no usable platform keyring, not broken on arrival for everyone.
   • Urgency 5 — actively hurting users on a published version: the affected artifact is the official ghcr.io/modelcontextprotocol/inspector:2.1.0 image.
   • Bonuses: +1 — carries the bug label. No milestone (a pass-1 triage never earns that one, by rule), no engagement yet, unassigned, not a sub-issue, and no reporter-set Fields → Priority.

   Board: #28, Status Incoming — awaiting maintainer review, so no milestone yet. Labeled v2 per the reported version line.

   Thanks for the unusually complete report — the probable-root-cause note (failure while constructing the keyring entry, not just reading a password, so the catch around the read never sees it) and the confirmation that patching it restores a 200 are exactly what makes this actionable.

   Per CONTRIBUTING.md we take fixes as issues rather than PRs, so nothing further is needed from you — but if you still have the patch you applied to the image, pasting the diff or the prompt you used here would help whoever picks this up.
4. cliffhall

   added

   keyringRelated to system keychain accessRelated to system keychain access

   on Aug 5, 2026
5. cliffhall commented on Aug 5, 2026

   

   cliffhall

   on Aug 5, 2026

   Member

   More actions

   Closing as a duplicate of #1848, which is now the single tracking issue for this bug.

   Thanks for the report — it was not wasted. Three people hit this independently in different environments, which is a large part of the evidence that it affects essentially any containerized or keyring-less deployment rather than one unusual setup:

   • web-ui in firefox fails to get servers: 500 error: Failed to read server list: Couldn't access platform storage: PermissionDenied #1845 — web UI, PermissionDenied on GET /api/servers
   • Bug: GET api/servers Fails Within Headless Docker Container #1918 — headless Docker, no gnome-keyring / org.freedesktop.secrets
   • GET /api/servers fails in container with Couldn't access platform storage: PermissionDenied #1931 — Docker Swarm container behind Traefik, ghcr.io/…/inspector:2.1.0
   • KeyringSecretStore throws from the AsyncEntry constructor, defeating its own degradation contract (500 on GET /api/servers) #1848 — the diagnosed root cause, where the fix is tracked

   Root cause: @napi-rs/keyring's AsyncEntry constructor does the platform-store setup and throws when no secret service is reachable. It is constructed outside the try in get/set/delete in core/auth/node/secret-store.ts, so the graceful-degradation path that already exists never engages — the raw error escapes and 500s every GET /api/servers.

   Your confirmation that patching the 2.1.0 image to treat keyring init/read failures as unavailable storage restores a 200 is independent evidence that this diagnosis is complete.

   Subscribe to #1848 for the fix. No further action needed here.
6. cliffhall

   added

   duplicateThis issue or pull request already existsThis issue or pull request already exists

   on Aug 5, 2026
7. cliffhall

   closed this as not plannedon Aug 5, 2026
8. cliffhall

   closed this as duplicateon Aug 5, 2026
9. cliffhall

   added

   containerizationRelated to the docker image or containerized operation in generalRelated to the docker image or containerized operation in general

   on Aug 5, 2026
10. cliffhall commented on Aug 6, 2026

    

    cliffhall

    on Aug 6, 2026

    Member

    More actions

    For the record, since this was closed as a duplicate of #1848: the fix is now open as #1945, and it is the change you root-caused here — AsyncEntry construction moved inside the try in get/set/delete, so a construction-time keychain failure follows the documented degradation contract instead of escaping as a raw error.

    After it, GET /api/servers returns 200 with the server list in a container with no D-Bus session, and only an actual attempt to save a secret hard-fails — as a KeychainUnavailableError, which the routes translate to a 503 with an actionable message rather than a generic 500.

    A related follow-up you may want to watch: #1950 covers what secret persistence should actually mean in a container, since #1945 makes the non-secret flows work but leaves the affected platforms with no way to store an OAuth client secret or a stdio env: secret at all.