The searches confirm the standard layout is /home/.ecryptfs/<user>/.Private, so the path in your transcript (…/.ecryptfs/.Private/) is unusual. Let me look at the actual ecryptfs-recover-private script source to understand exactly what it found and mounted, plus search for this specific symptom.

The script source is revealing, and the last search result — a Linux Mint forum thread about "some ecryptfs folders invisible" — looks highly relevant. Let me open it.

The Mint forum thread can't be opened directly. Let me get the definitive kernel behavior for how eCryptfs readdir handles filenames that can't be decrypted with the mounted FNEK — that's the crux of "invisible directories".

The dir.c fetch failed and the decode function wasn't in crypto.c — let me look in keystore.c and retry dir.c.

The kernel behavior is now confirmed: in ecryptfs_filldir, any lower entry whose name can't be decoded with the mount's FNEK returns -EINVAL and is silently skipped. Now let me check the exact on-disk layout that ecryptfs-setup-private creates, to understand the odd .ecryptfs/.Private path in your transcript.

Let me check ecryptfs-migrate-home too, since that's what actually converts an existing home to eCryptfs.

TL;DR

Nothing is wrong with your keys or with filename encryption — you recovered the wrong .Private directory. Your $ECRYPTFS_USER_FOLDER points one level too deep: at the .ecryptfs config directory (…/benjamin_loison/.ecryptfs) instead of its parent. So you mounted …/.ecryptfs/.Private/ — a second, nested .Private tree that lives inside the config dir — not the real encrypted home.

How your own transcript shows it

When you pass a directory to ecryptfs-recover-private, it does not search under it. From the  script source:

if [ -d "$1" ]; then
    dirs="$@"          # <- your argument is used as-is
else
    dirs=$(find / -type d -name ".Private")  # only with NO argument
...
info "Found [$d]."     # <- just echoes your argument back

Two details in your output confirm this:

• INFO: Found […/benjamin_loison/.ecryptfs/.Private/] — including the trailing slash — is a verbatim echo of your argument. The standard full-home layout created by ecryptfs-setup-private -b / ecryptfs-migrate-home (per the  setup script) is two siblings:
  text

  Copy

  /home/.ecryptfs/benjamin_loison/
  ├── .Private/     ← the real encrypted data
  └── .ecryptfs/    ← wrapped-passphrase, Private.sig, auto-mount…

  Your mount source is .ecryptfs/.Private — one level inside the config dir, which no standard tool ever creates there.
• The script "found your wrapped-passphrase" at $d/../.ecryptfs/wrapped-passphrase, i.e. …/.ecryptfs/.ecryptfs/wrapped-passphrase — a nested config dir. Your ecryptfs-unwrap-passphrase $ECRYPTFS_USER_FOLDER/.ecryptfs/wrapped-passphrase hit that same nested file, which is why it worked and why sigs X/Y unlocked this tree.

So the nested tree is a complete, self-consistent eCryptfs home of its own (same login passphrase, its own valid Private.sig, a plausible .bashrc) — recovery "succeeds", but it's simply not the tree holding your VMs.

What to do

# 1. Fix the variable — no trailing ".ecryptfs"
ECRYPTFS_USER_FOLDER=/mnt/linux_mint/home/.ecryptfs/benjamin_loison

# 2. Look at what's really there (real dirs vs symlinks)
ls -la $ECRYPTFS_USER_FOLDER/
ls -la /mnt/linux_mint/home/benjamin_loison/

# 3. Enumerate ALL .Private trees on the disk (recover-private won't do this for you)
sudo find /mnt/linux_mint -name '.Private' \( -type d -o -type l \) -exec ls -ld {} +

# 4. Recover the real one
sudo ecryptfs-recover-private --rw $ECRYPTFS_USER_FOLDER/.Private/

Mount each .Private the find step reveals (answer Y per tree) and check which one contains VirtualBox VMs.

If the VMs are still missing after mounting the right tree

• VirtualBox's machine folder may not have been ~/VirtualBox VMs. In the recovered mount, check .VirtualBox/VirtualBox.xml (or .config/VirtualBox/VirtualBox.xml) → <System properties defaultMachineFolder=…> — it tells you where VMs actually lived.
• Entries whose names can't be decrypted are silently hidden. In an FNEK-enabled mount, ecryptfs_filldir skips any lower entry whose name fails tag-70 decoding (-EINVAL is masked by design, e.g. plaintext names in .Private; any decode error also skips the entry) ( fs/ecryptfs/file.c). So compare counts: ls /path/to/.Private | wc -l vs ls /tmp/ecryptfs.* | wc -l — if the lower dir has more entries, some names were written through a mount without filename encryption (or a different FNEK), and dmesg will show Error attempting to decode and decrypt filename. Those blobs are still on disk and can be recovered manually.
• Check the raw, unencrypted home (/mnt/linux_mint/home/benjamin_loison/): if the eCryptfs mount ever failed at login on Mint, files created in that session (VMs are a classic case) sit in the raw home, not in .Private at all.

One last note: your ecryptfs-unwrap-passphrase + ecryptfs-add-passphrase --fnek preamble was redundant here — ecryptfs-recover-private unwraps and inserts both keys itself, taking the signatures from the Private.sig next to the wrapped-passphrase it found. That's also why it mounted happily with the "wrong" directory: everything about that nested tree was internally consistent.