Error unlocking vault on Ubuntu 26.04 after upgrade

Help
1

Hello

sorry if this is a duplicate - and/or if this problem has been solved elsewhere.

Latest version of cryptomator installed via flatpak (appimages imho really tricky on latest versions of ubuntu, sometimes they work, they might work with a --no sandbox flag, somtimes don’t work at all)

I upgraded Ubuntu 24.04 to 26.04 today, trying to unlock an existing Cryptomator vault on 26.04 but getting error message - I believe others had the same or similar issue:

Error Code 6HCL:2GTN:615N
org.cryptomator.integrations.mount.MountFailedException: org.cryptomator.jfuse.api.FuseMountFailedException: fuse_mount failed
at org.cryptomator.frontend.fuse@6.0.1/org.cryptomator.frontend.fuse.mount.LinuxFuseMountProvider$LinuxFuseMountBuilder.mount(LinuxFuseMountProvider.java:142) …

I managed to solve the problem using ai (specifically duck.ai) - I am not a programmer so please do check everything yourself.

duck.ai established that the problem was connected to AppArmor profile, specifically to AppArmor blocking fusermount3 access.

it suggested the following steps: (sorry quite a few) - initially “diagnostic” to find the source of the error:

  1. Verify FUSE is available on the host

lsmod | grep -E ‘^fuse’ || true
test -e /dev/fuse && echo “/dev/fuse present” || echo “/dev/fuse missing”

  1. Check Flatpak permissions for device FUSE

    flatpak info org.cryptomator.Cryptomator
    Then add/allow FUSE by overriding the app (exact app id may differ; adjust if needed):

    sudo flatpak override --user org.cryptomator.Cryptomator --device=fuse

If the app id above errors, get the exact id with:

flatpak list | grep -i cryptomator
and use that id in the override command.

  1. Install the Flatpak “FUSE” runtime pieces (often required)
    On Ubuntu:

    sudo apt install -y flatpak
    flatpak install -y flathub org.freedesktop.Platform

Confirm /dev/fuse exists

test -e /dev/fuse && echo "/dev/fuse present" || echo "/dev/fuse missing"
  1. Allow FUSE for this Flatpak (host device access)
sudo flatpak override --user org.cryptomator.Cryptomator --device=fuse

I found that Flatpak on my system won’t accept --device=fuse (it only whitelists certain device types). That means i needed the correct Flatpak permission to override for FUSE on this platform.

a subsequent log points to AppArmor denying fusermount3 (the helper used for FUSE mounts) inside the sandbox (“peer=bwrap”, “profile=fusermount3”), which aligns with your fuse_mount failed.

following steps:

  1. Confirm AppArmor is enabled:
sudo aa-status | sed -n '1,5p'
  1. Check whether your Cryptomator Flatpak runs under AppArmor and whether it’s blocked:
sudo journalctl -k --since "30 min ago" | grep -i -E 'fusermount3|bwrap|apparmor="DENIED"|cryptomator' | head -n 50

further command showed that AppArmor is active and your logs show apparmor="DENIED" for fusermount3 (the FUSE mount helper), the Flatpak sandbox is being blocked from doing the mount.

Duck.ai then suggested: Do this: Quick workaround (most effective)
Use the non-Flatpak Cryptomator build (e.g., AppImage or deb) and unlock there.
This avoids the specific Flatpak/bwrap + AppArmor interaction that’s breaking the mount.

NB I tried this on ubuntu, neither solution worked, for example AppImage does not start, running Cryptomator after .deb installation leads to same error trying to unlock a vault )

Then suggestion for System-level fix (if you want Flatpak to work)
Find out which AppArmor policy is in effect for the fusermount3 helper launched by Flatpak on your system, then adjust/disable the conflicting rule/profile.
To guide this precisely, run:

sudo cat /sys/kernel/security/apparmor/profiles | head

Let’s fix the AppArmor side directly.

1) Confirm whether AppArmor is actually enforcing a fusermount3 profile

sudo aa-status | grep -i fusermount -n || truesudo aa-status --enforced | grep -i fusermount -n || true

2) Get the exact fusermount3 AppArmor profile contents/status

sudo apparmor_status 2>/dev/null || truesudo ls /etc/apparmor.d/ | grep -i fusermount || truesudo grep -R --line-number --ignore-case "fusermount3" /etc/apparmor.d 2>/dev/null | head

3) Test by putting only that profile into complain mode (non-destructive)

Once you find the profile name, run (replace PROFILE_NAME):

sudo aa-complain PROFILE_NAME

(Note I needed to install apparmor-utils first via sudo apt install -y apparmor-utils)

This showed there is a fusermount3 AppArmor profile in enforced mode.

Do this: Put only that profile into complain mode (logs denials but doesn’t block)

sudo aa-complain fusermount3

-> success, after this I was able to open a cryptomator vault!

Duck.ai: Great—if it unlocked after putting fusermount3 into complain mode, then AppArmor was the blocker.

Now make it permanent (so you don’t lose the change on reboot) and remove the root cause:

  1. Check current mode and confirm it’s still complain
sudo aa-status | grep -i fusermount3 -n
  1. Persist the fix by copying the effective profile to a local override. First, find where the fusermount3 profile file comes from:
sudo aa-status --profiled | grep -i fusermount3 || truesudo grep -R --line-number "profile fusermount3" /etc/apparmor.d 2>/dev/null | head

it then recommended

fusermount3 is defined in /etc/apparmor.d/fusermount3 and it’s currently in complain mode. To make it permanent across reboots, ensure the profile file itself sets complain.

Do this:

  1. Edit the profile file:
sudo nano /etc/apparmor.d/fusermount3
  1. Ensure the first line is like this (or change it to this):
profile fusermount3 /usr/bin/fusermount3 flags=(complain) {

(You currently already have flags=(complain) shown by your grep, so you may not need to change anything.)

  1. Reload AppArmor:
sudo systemctl reload apparmor

however this led to an error trying to reload apparmor via systemctl and I undid the changes to /etc/apparmor.d/fusermount3

however (lateron) looking at /etc/apparmor.d/fusermount3 this now contains the above line

profile fusermount3 /usr/bin/fusermount3 flags=(complain) {

fortunately even after reboot I was able to open an existing vault.

Sorry for loooong post.

Perhaps one of the experts on this forum could help if he/she agrees that the problem is as described above (AppArmor blocking fusermount3 access) and suggest a simpler workaround and/or edit for apparmor profile file

/etc/apparmor.d/fusermount3

2

try to report this as bug in ubunu bug system because they should have installed a apparmore profile for fusemount3 this ubuntu bug

3

Your diagnosis looks right, 26.04 tightened the AppArmor policy around user namespaces and fusermount3, and it’s biting a lot of FUSE apps, not just Cryptomator. Rather than putting the whole profile in complain mode, a cleaner route is usually the flatpak override to grant FUSE, plus reloading just that one profile with apparmor_parser -r instead of the full systemctl reload, which is what threw your error. Worth flagging your exact 26.04 build to the devs since the packaged profile may still get patched.

4

That’s a cleaner path than what I was doing, dropping the whole profile into complain mode is a blunt instrument when a targeted flatpak override to grant FUSE gets the access without loosening everything. And reloading just the one profile with apparmor_parser -r instead of the full systemctl reload should sidestep the error I hit. Makes sense that 26.04’s tighter AppArmor policy around user namespaces and fusermount3 is catching FUSE apps broadly, not just Cryptomator. I’ll flag my exact build to the devs too since the packaged profile may still get patched. Thanks, this untangles it.