docs: a locked volume after a password reset (B210)

Issue #40: after a password reset the daemon failed every mount with
"failed to decrypt: missing key", and the app waited on "Connecting…"
because control.sock was never created. proton-drive-rs 0.9.1 now
creates a new My Files volume when no active regular volume is left,
as the web client does.

- BUGS.md: B210 with cause, fix and the SDK tests that cover it
- TROUBLESHOOTING.md: what the log line means and how to restore the
  files of the locked volume from the web

docs/BUGS.md

@@ -100,6 +100,7 @@ a live account since.
 
 | Entry | Title |
 |---|---|
+| [B210](#b210--after-a-password-reset-the-mount-retries-missing-key-forever) | After a password reset, the mount retries "missing key" forever |
 | [B209](#b209--a-blocked-sign-in-says-the-app-version-is-no-longer-supported) | A blocked sign-in says the app version is no longer supported |
 | [B208](#b208--a-file-landing-while-its-folder-is-pinned-is-kept-but-not-available-offline) | A file landing while its folder is pinned is kept but not available offline |
 | [B207](#b207--a-move-between-locations-goes-ahead-under-a-file-opened-just-after-its-create-landed) | A move between locations goes ahead under a file opened just after its create landed |
@@ -312,6 +313,35 @@ a live account since.
 
 Newest first.
 
+### B210 — After a password reset, the mount retries "missing key" forever
+
+**Status:** Fixed, not verified live
+**Found:** 2026-10-15, issue #40: on a fresh 3.4.0 install the sign-in worked, but the daemon
+logged `mount failed: fetch My Files root: cryptography error: failed to decrypt: missing key`
+every 5 seconds. The app stayed on "Connecting…" because the daemon never got far enough to
+create `control.sock`.
+**Where:** `ProtonDriveClient::ensure_my_files` in proton-drive-rs; `fetch_or_recall_root` in
+`crates/pdfs-fuse/src/mount.rs`
+
+**Repro:** Reset the account password through Proton's recovery flow, which replaces the account
+keys, then sign in on a client without a cache.
+
+**Cause.** A password reset gives the account new keys and locks the Drive volume whose share was
+encrypted to the old ones. `v2/shares/my-files` still returns that share, so none of the unlocked
+address keys can open its passphrase. The SDK only created a new volume when the share did not
+exist, so every mount attempt failed the same way. The web client checks for an active regular
+volume and creates a new one when there is none.
+
+**Fix.** proton-drive-rs 0.9.1 handles a share key that fails to decrypt the way the web client
+does. When `GET volumes` shows no active regular volume, it creates a new My Files volume and uses
+that. The locked volume is left alone and can still be restored from the web with the previous
+password.
+
+**Test:** `client::tests::a_locked_main_volume_is_not_an_active_regular_one`,
+`client::tests::an_active_regular_volume_is_found_with_or_without_a_type` (proton-drive-rs).
+
+---
+
 ### B209 — A blocked sign-in says the app version is no longer supported
 
 **Status:** Fixed, not verified live

docs/TROUBLESHOOTING.md

@@ -113,6 +113,12 @@ fusermount3 -uz ~/ProtonDrive
 systemctl --user restart proton-drive.service
 ```
 
+**`fetch My Files root: … failed to decrypt: missing key`** in the service log — the account
+keys cannot open your Drive volume, which happens after a password reset. Proton locks the volume
+that was encrypted to the old keys. From 3.4.1 the client starts a new, empty My Files volume
+in that case. Your old files stay in the locked volume: open [drive.proton.me](https://drive.proton.me)
+and restore them there with your previous password.
+
 **The folder is empty or missing** — check that the service runs and is signed in
 (`pdfs status`). The service waits for a stored session before it mounts.