Jump to content

Recommended Posts

Posted

Hi, all

The Problem

If you have an app (like Immich) configured to use a path on an encrypted dataset, and that dataset becomes locked after a server reboot, the app will fail to start with a generic error:

Failed 'up' action for 'immich' app. Please check /var/log/app_lifecycle.log for more details

When you dig into the log, all you see is:

bind source path does not exist: /mnt/HDDs-2/Photos/immich

This is misleading — the path "doesn't exist" not because it was deleted or never created, but because the encrypted dataset is locked and therefore unmounted. It sent me troubleshooting in the wrong direction (permissions, database migrations, corrupted installs) before I realized the real cause was simply a locked dataset after reboot.

What I'd Like to See

  1. Detect locked datasets during app startup failure — When a bind mount fails because the source path doesn't exist, check whether that path sits on a locked encrypted dataset.

  2. Surface a clear warning to the user — Instead of the generic [EFAULT] error, show something like:

    "App 'immich' failed to start — the dataset HDDs-2/Photos is currently locked. Unlock it and try again."

  3. A gentler nudge on the generic error — Even if full detection isn't feasible, adding a line to the default error message like "Check that any required datasets are unlocked" would help point users in the right direction much faster.

    (Btw yes AI help me write this as this would be so quite hard for me to write "by hand")

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...