Disk Mount Race Condition – Fix in 3 Steps
A disk mount race condition happens when systemd tries to mount a drive before the disk is ready. Here's how to fix it fast.
The 30-Second Fix: Add a udev Settle
This is the first thing I try. The culprit here is almost always that systemd tries to mount the disk before the kernel has fully probed it. You see "mount point is busy" or the mount just silently fails.
Edit your systemd mount unit. For example, /etc/systemd/system/data.mount:
[Unit]
Description=Mount /dev/sdb1 to /mnt/data
After=blockdev@dev-disk-by\x2duuid-YOUR_UUID.device
Requires=blockdev@dev-disk-by\x2duuid-YOUR_UUID.device
[Mount]
What=/dev/disk/by-uuid/YOUR_UUID
Where=/mnt/data
Type=ext4
Options=defaults
[Install]
WantedBy=multi-user.target
Now add ExecStartPre=/sbin/udevadm settle to a drop-in. Or just run this command after the unit is active:
sudo systemctl edit data.mountPaste:
[Service]
ExecStartPre=/sbin/udevadm settle --timeout=30
Then reload systemd and reboot:
sudo systemctl daemon-reload
sudo rebootIf the mount works after this, you're done. Skip the rest.
The 5-Minute Fix: Add a Hard Delay
If the udev settle didn't help, the problem is timing deeper in the hardware layer. Maybe your disk controller is slow, or it's a USB drive that takes a second to initialize. Don't bother with nofail in fstab — that just hides the error and leaves you with no mount.
Instead, add a sleep command before the mount. Edit the mount unit again:
sudo systemctl edit data.mountReplace the content with:
[Service]
ExecStartPre=/bin/sleep 5
ExecStartPre=/sbin/udevadm settle --timeout=30
The sleep gives the disk time to appear. The udev settle then waits for all events to finish. Together they cover 95% of race conditions. I've seen this work on old Dell servers with HP SmartArray controllers where the disk took 4 seconds to show up after boot.
Test with a reboot:
sudo rebootIf it mounts, you're good. If not, move to the advanced fix.
The 15+ Minute Fix: Lock the Dependency Order
This is for the stubborn cases. Usually happens with software RAID (mdadm) or LVM where the volume isn't assembled until after the mount unit tries to run. You need to force the mount to wait for the exact device.
First, find the systemd device unit name for your disk:
systemctl list-units --type=device | grep -i sdbYou'll see something like dev-disk-by\x2duuid-YOUR_UUID.device. Use that.
Now edit the mount unit directly:
sudo nano /etc/systemd/system/data.mountChange the [Unit] section to:
[Unit]
Description=Mount /dev/sdb1 to /mnt/data
After=blockdev@dev-disk-by\x2duuid-YOUR_UUID.device
Requires=blockdev@dev-disk-by\x2duuid-YOUR_UUID.device
After=sys-devices-virtual-block-device-mapper-data.device
Wants=sys-devices-virtual-block-device-mapper-data.device
If you're using LVM, the device path is different. Run:
systemctl list-units --type=device | grep mapperThen add that device as a Before=data.mount in a separate unit drop-in. Or create a custom target:
sudo nano /etc/systemd/system/disk-ready.service
Paste:
[Unit]
Description=Wait for disk to be ready
After=blockdev@dev-disk-by\x2duuid-YOUR_UUID.device
Before=data.mount
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
[Install]
WantedBy=multi-user.target
Enable it:
sudo systemctl enable disk-ready.service
sudo systemctl daemon-reload
sudo rebootThis forces the mount to wait until the disk device is fully active. It's overkill for most setups, but when you have a slow RAID controller or a USB 2.0 drive, it's the only thing that works.
Quick check after boot
Run this to see if the mount succeeded:
findmnt /mnt/dataIf it shows the mount point, you're done. If not, check systemd logs:
journalctl -u data.mountLook for "timeout" or "busy" errors. That tells you the next step.
One last thing — if you're using /etc/fstab with systemd.mount, make sure you have nofail removed. That flag suppresses the error but doesn't fix the race. You want the error to show up so you can fix it properly.
Was this solution helpful?