"systemctl start" mount Dependency failed Crypttab LUKS

Ubuntu Version:
24.04 LTS

Desktop Environment (if applicable):
Cinnamon

Problem Description:
Trying to mount/open LUKS+BTRFS partition with systemctl start, which never asks for the LUKS password and always gives error:
Dependency failed for media-1tbmx500-BTRFS-id5_top_volume.mount - /media/1tbmx500/BTRFS/id5_top_volume

Crypttab line for this partition:
1TBMX500 UUID="DELETED" none luks,nofail

Both manual sudo cryptsetup luksOpen (via the same UUID as in crypttab) and sudo mount (using same fstab’s entry) work w/o any issue.

If I remove nofail from crypttab line above, systemctl start still never asks for the LUKS password and waits forever.

Relevant System Information:

systemctl --version
systemd 255 (255.4-1ubuntu8.8)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT default-hierarchy=unified

Screenshots or Error Messages:
In journalctl:

polkitd[1244]: Operator of unix-session:c6 successfully authenticated as unix-user:DELETED to gain TEMPORARY authorization for action org.freedesktop.systemd1.manage-units for system-bus-name::1.304285 [systemctl start /media/1tbmx500/BTRFS/id5_top_volume] (owned by unix-user:DELETED)
systemd[1]: Dependency failed for media-1tbmx500-BTRFS-id5_top_volume.mount - /media/1tbmx500/BTRFS/id5_top_volume.
systemd[1]: media-1tbmx500-BTRFS-id5_top_volume.mount: Job media-1tbmx500-BTRFS-id5_top_volume.mount/start failed with result 'dependency'.

In terminal:
A dependency job for media-1tbmx500-BTRFS-id5_top_volume.mount failed. See 'journalctl -xe' for details.

What I’ve Tried:
Checked journalctl and dmesg.
systemctl daemon-reload a number of times.
Removed and added nofail to relevant crypttab nofail.
Was going to create issue at the systemd upstream GIT, but in other issues the response is:
we only support the latest two major releases here, namely v256 and v257..

  • Verified UUID is correct.
  • Unsuccessfully tried to find relevant unit in /etc/systemd/system - there’s none.

How to determine what’s meant by dependency job?
Couldn’t find any details about dependency job yet.

Why doesn’t systemctl start ask for LUKS password?
Thank you.

systemctl start /media/1tbmx500/BTRFS/id5_top_volume.mount asks
systemd to mount the filesystem after the block-device it lives on is
already present.
Because that block device is really a LUKS mapping, the mount unit has an
implicit dependency on:

systemd-cryptsetup@1TBMX500.service  -  /dev/mapper/1TBMX500.device

When the machine boots systemd activates the
systemd-cryptsetup@1TBMX500 unit first (it finds the line in /etc/crypttab,
prompts for the pass-phrase, creates /dev/mapper/1TBMX500), and then
mounts the Btrfs volume, so everything works.

When you call the mount unit by hand that cryptsetup service is not
pulled in automatically, so the mount’s dependency fails and you get

Dependency failed for … .mount

No password prompt appears because the crypto unit never started.


How to mount it interactively

# unlock the LUKS container
sudo systemctl start systemd-cryptsetup@1TBMX500.service
# (or:  sudo cryptdisks_start 1TBMX500 )

# mount the filesystem
sudo systemctl start /media/1tbmx500/BTRFS/id5_top_volume.mount

If you want a single command you can also do

sudo systemctl start /dev/mapper/1TBMX500   # unlock + keep open
# or simply
sudo mount /media/1tbmx500/BTRFS/id5_top_volume

The kernel will ask systemd for the mapper device and you’ll get the usual
systemd-ask-password prompt on the terminal.


Why nofail isn’t involved

nofail in /etc/crypttab only tells the boot sequence not to drop into
emergency mode if the pass-phrase is wrong at boot time. It doesn’t
affect manual mounts.


Quick checklist

First field in /etc/crypttab is the mapper name:
1TBMX500 UUID=<…> none luks
/etc/fstab uses that mapper:
/dev/mapper/1TBMX500 /media/1tbmx500/BTRFS/id5_top_volume btrfs defaults 0 0
Unlock with systemctl start systemd-cryptsetup@1TBMX500 (or cryptsetup luksOpen),
then mount as usual.

Once you start the correct cryptsetup unit the mount succeeds and
systemctl status shows both units active with no dependency error.

2 Likes

Thank you. Your answer is very helpful (clicked “like” button), but here (in accepted answer) its claimed that it should do luks unlock with simple systemctl start /mnt/disk1 also

https://superuser.com/questions/1702871/how-to-do-cryptsetup-luksopen-and-mount-in-a-single-command

Do you believe this answer is incorrect?

If there’re multiple entries for the same mapper e.g. /dev/mapper/1TBMX500, how does it know which path to mount?
Or will it mount all the relevant entries from fstab?

The Super User answer is correct but only when the mount unit refers to
the decrypted device (the /dev/mapper/<name> node or its DM-crypt UUID).
In that situation systemd-cryptsetup@<name>.service is generated
automatically and becomes a dependency of the mount unit, so

systemctl start /mnt/disk1

unlocks LUKS and then mounts the filesystem in one go.


Why it doesn’t happen in your setup

In /etc/fstab you mounted the raw partition (the one that is still
encrypted) or a filesystem UUID that belongs to that raw partition.
When you ask systemd to mount it, the generated unit wants the block
device as-is and never looks at /etc/crypttab, so no cryptsetup unit is
pulled in - dependency fails.


Fix

  1. Unlock the container once:

    sudo cryptsetup luksOpen /dev/nvme0n1p3 1TBMX500
    
  2. Find the UUID of the decrypted device:

    blkid /dev/mapper/1TBMX500
    # or just use /dev/mapper/1TBMX500 directly
    
  3. Edit /etc/fstab so the source of that mount line is either

    /dev/mapper/1TBMX500
    or UUID=<the-uuid-of-dm-crypt-device>

    Example:

    UUID=45c7c9c2-…  /media/1tbmx500/BTRFS/id5_top_volume  btrfs  defaults  0  0
    
  4. Reload the units:

    sudo systemctl daemon-reload
    

Now the generator sees that the filesystem lives on 1TBMX500, adds the
dependency automatically, and

sudo systemctl start /media/1tbmx500/BTRFS/id5_top_volume.mount

will:

prompt for the pass-phrase (runs systemd-cryptsetup@1TBMX500),
create /dev/mapper/1TBMX500,
mount the Btrfs volume.

Exactly what the Super User post describes.


So: the post isn’t wrong; your fstab just pointed at the encrypted
device. Point it at the unlocked one (or its UUID) and the one-command
unlock-and-mount will work.

1 Like

This is the corresponding entry in my fstab (didn’t change it):

/dev/mapper/1TBMX500 /media/1tbmx500/BTRFS/id5_top_volume btrfs rw,subvolid=5,noauto,nofail,noatime,compress=zstd,discard=async,space_cache=v2,ssd_spread 0 0

Haven’t tried unlocked btrfs UUID yet.

/dev/mapper/1TBMX500 is the right thing to put in fstab;
the problem is the nofail option that follows it.

When you start the mount unit by hand systemd notices the file-system
has the nofail flag and says “mount only if the device is already
there – do not try to pull other units in to make it appear”.
Because the mapper device does not exist yet the mount immediately
fails with the dependency failed message you saw.

Drop nofail (or replace it with x-systemd.requires=systemd-cryptsetup@1TBMX500.service)
so the mount may ask systemd to create the device for it:

/dev/mapper/1TBMX500  /media/1tbmx500/BTRFS/id5_top_volume  btrfs \
  rw,subvolid=5,noauto,noatime,compress=zstd,discard=async,space_cache=v2,ssd_spread  0  0

then

sudo systemctl daemon-reload
sudo systemctl start /media/1tbmx500/BTRFS/id5_top_volume.mount

systemd now sees that the required block device is missing,
it adds a job for systemd-cryptsetup@1TBMX500.service,
prompts for the pass-phrase, creates /dev/mapper/1TBMX500,
finally mounts the Btrfs volume – one command, exactly like in the
Super User answer.

(nofail is still fine in /etc/crypttab; it only relaxes boot-time
ordering. It’s the copy in fstab that prevented the automatic unlock.)

1 Like

Thank you for your help.
This is a removable drive.
Wouldn’t x-systemd.requires=systemd-cryptsetup@1TBMX500.service cause hang/other issues at boot if drive not present?

I reboot very rarely, can’t just test it yet.

noauto (which you already have in the options) means “don’t touch this
entry at boot, mount it only when I ask.”
Because the unit is inactive at boot, it will not hang the boot process
even if the disk is unplugged, no matter whether it contains
Requires=systemd-cryptsetup@… or not.

So the safe-to-hot-plug recipe is:

/dev/mapper/1TBMX500  /media/1tbmx500/BTRFS/id5_top_volume  btrfs \
    rw,subvolid=5,noauto,x-systemd.requires=systemd-cryptsetup@1TBMX500.service,\
    noatime,compress=zstd,discard=async,space_cache=v2,ssd_spread  0  0

noauto → systemd ignores it during boot.
x-systemd.requires=… - when you do run
systemctl start /media/1tbmx500/BTRFS/id5_top_volume.mount
systemd first starts the cryptsetup unit, asks for the pass-phrase,
creates /dev/mapper/1TBMX500, then mounts the Btrfs volume.

If the drive isn’t plugged in you just get “failed to activate
dependency” and the mount exits—no boot delay, no hang.

1 Like

Thank you.
I noticed you use \ for line splitting.
I tried find smth about it in my search engine and there’s nothing relevant.
How common/standard support of \ in fstab?
Is there any documentation about the support of \ in fstab?

The backslashes were only there to break the line in the forum post so it
would fit on-screen.
/etc/fstab does not understand “\” as a continuation character – each
entry must be on one single line.

So in the real file write it like this (one long line, no “\”):

/dev/mapper/1TBMX500  /media/1tbmx500/BTRFS/id5_top_volume  btrfs  \
rw,subvolid=5,noauto,x-systemd.requires=systemd-cryptsetup@1TBMX500.service,noatime,compress=zstd,discard=async,space_cache=v2,ssd_spread  0  0

or without the visual “\” at all:

/dev/mapper/1TBMX500 /media/1tbmx500/BTRFS/id5_top_volume btrfs rw,subvolid=5,noauto,x-systemd.requires=systemd-cryptsetup@1TBMX500.service,noatime,compress=zstd,discard=async,space_cache=v2,ssd_spread 0 0

(Use whichever spacing you prefer; just keep it on a single line in
fstab.)

1 Like