🚨 Linux Error: 'Dependency failed for /<mountpoint>' — Cause, Fix, and Troubleshooting Guide

Summary

Dependency failed for /<mountpoint> is systemd’s way of saying a mount unit could not be satisfied, so every job that depended on it was skipped. You will usually see it paired with a local-fs.target failure and a shell drop during boot. The exact phrase — Dependency failed for /data or Dependency failed for /var/lib/docker — points directly at the mount unit systemd auto-generated from /etc/fstab. The root cause is almost always a bad fstab entry, a missing device, or a filesystem that will not mount.

Common Symptoms

• Boot stalls or drops to an emergency/rescue shell asking for the root password.
• Console prints Dependency failed for /<mountpoint> followed by Dependency failed for Local File Systems.
• systemctl list-units --failed shows a .mount unit in failed state.
• Services that write to the missing mount (databases, containers) fail to start with their own dependency errors.
• The system boots fine only after commenting the line out of /etc/fstab.

Most Likely Causes of the ‘Dependency failed for /’ Error

The Dependency failed for /<mountpoint> error is emitted when the underlying *.mount unit enters a failed state, cascading to everything ordered after it. In production the usual culprits, most common first:

1. A bad /etc/fstab entry — wrong UUID, typo in the device path, or an option the filesystem does not accept.
2. The backing device is absent — an unattached EBS/SAN volume, a pulled disk, or a device that enumerates slowly (iSCSI, multipath) and is not ready at mount time.
3. Filesystem corruption — fsck fails and the mount is refused.
4. Wrong filesystem type — e.g. ext4 declared for an xfs volume.
5. A network filesystem (NFS/CIFS) mounted without _netdev/nofail, so systemd tries to mount it before the network is up.

Quick Triage

# Which mount unit failed and why
systemctl --failed
systemctl status data.mount            # for /data; name = escaped path

# Confirm the fstab entry and the device it references
findmnt --verify --verbose
lsblk -f
blkid

findmnt --verify parses /etc/fstab and flags missing devices, bad UUIDs, and unknown filesystem types before you reboot.

Diagnostic Commands

# systemd escapes the path: /var/lib/docker -> var-lib-docker.mount
systemctl status var-lib-docker.mount
journalctl -u var-lib-docker.mount -b       # this boot's mount attempt
journalctl -xb                              # full boot log with hints

systemctl status <path>.mount shows the exact mount(8) exit code and stderr. Use systemd-escape -p --suffix=mount /var/lib/docker if you are unsure of the unit name.

# See the auto-generated unit and the resolved dependency chain
systemctl cat var-lib-docker.mount
systemctl list-dependencies local-fs.target
findmnt --fstab                             # what fstab intends to mount

# Validate the device actually exists and its true filesystem type
blkid /dev/sdb1
lsblk -f /dev/sdb1
sudo fsck -n /dev/sdb1                       # read-only check

If blkid returns nothing for the UUID in fstab, the device is missing or renamed — that is your dependency failure.

Fix / Remediation

1. Correct the /etc/fstab entry. Match the UUID from blkid and the type from lsblk -f, then dry-run it:

   sudo findmnt --verify --verbose
   sudo mount -a                             # mount everything in fstab now

2. Reload systemd so it regenerates mount units from fstab:

   sudo systemctl daemon-reload
   sudo systemctl start var-lib-docker.mount

3. Add nofail (and _netdev for network mounts) so a non-critical mount cannot block boot:

   UUID=xxxx  /data  ext4  defaults,nofail,x-systemd.device-timeout=10  0 2
   nfs01:/exports/data  /mnt/data  nfs  defaults,_netdev,nofail  0 0

   nofail downgrades the failure to a warning; x-systemd.device-timeout stops systemd waiting forever for a device that will never appear.

4. Tie a service to its mount with RequiresMountsFor= in a drop-in instead of a manual After=:

   sudo systemctl edit docker.service

   [Unit]
   RequiresMountsFor=/var/lib/docker

5. If the volume simply is not attached, attach it (cloud console / iscsiadm), then mount -a.

Warning: Only run a repairing fsck (fsck -y /dev/sdb1) on an unmounted filesystem, and take a snapshot first — a bad repair can lose data.

Validation

systemctl start local-fs.target
systemctl --failed                          # should list no *.mount units
findmnt /var/lib/docker                      # confirm it is actually mounted
sudo systemctl daemon-reload && sudo mount -a

Reboot once in a maintenance window to prove the mount survives cold boot, then confirm dependent services came up:

systemctl is-active docker
journalctl -b | grep -i 'Dependency failed'   # expect no output

Prevention

• Always use UUID= (or LABEL=) in /etc/fstab, never unstable /dev/sdX names.
• Add nofail to any non-root, non-critical mount so a single bad volume never blocks boot.
• Use _netdev and x-systemd.device-timeout= for network and slow-enumerating storage.
• Bind services to storage with RequiresMountsFor= rather than hand-rolled ordering.
• Run findmnt --verify and systemd-analyze verify in CI or a pre-reboot check so a broken fstab is caught before it reaches the boot loader. See the wider Linux admins guides.

Related Errors

• Failed to start unit
• Job timed out
• Device or resource busy
• Alert: /dev/… does not exist, dropping to a shell
• A stop job is running for…

Final Notes

Dependency failed for /<mountpoint> is a symptom, not the root cause — the failed *.mount unit is. Read systemctl status <path>.mount and journalctl -u <path>.mount -b to get the real mount(8) error, fix the fstab UUID/type/options, and add nofail so a single storage problem degrades gracefully instead of dropping the whole host to an emergency shell.

Want faster Linux incident response? Use DevOps AI Toolkit to turn production errors into clear diagnostics, remediation steps, and reusable runbooks.